Иван Козлов: Ошибаетесь по поводу легче поддерживать код. Как раз наоборот. Функции ACF учитывают адекватное кеширование, нормализацию данных на вывод и тд, к тому же консистентность. А использовать get_field то тут то там, get_post_meta вперемешку - это усложняет код. К тому же, в большинстве случаев настройки полей ACF учитывают конкретный формат возврата данных, часто с дополнительным получением данных (например, возврат объекта поста из поля relationship - в мета хранится только ID поста). и их кешированием тоже. Это как раз удобнее и корректнее. Я понимаю ваш аргумент по поводу родных функций, но в случае с ACF этот аргумент нерелевентен. Если уж совсем низкий уровень хотите - используйте get_metadata. Ну или SQL, чего уж мелочиться :)
Ressive: нет, get_permalink выдает полную ссылку. Не подойдет. Придется ставить урл руками. Но вообще странно вы это реализовали, почему не использовали какой-нибудь Polylang?
Дмитрий: вы бы хоть ссылку на этот ваш Essential Grid поставили в вопросе :) Вы же не думаете, что люди будут сами гуглить и смотреть че там и как? А вероятность встретить здесь кого-то, кто уже знаком с этой штукой не очень-то и высока.
Ressive: А переводы у вас каким-то плагином реализованы? У всех плагинов есть соответствующие функции. Динамически урл можно подставлять через get_permalink(), но в вашем случае от будет выдавать текущую языковую версию, что не подходит. Строить все УРЛ руками из частей не вариант.
Gabe Jonson: ну зависит от компа конечно. У меня раньше был PC с 16Гб оперативы и Core i5, достаточно старенький (2009-2010 год где-то), но на нем все прекрасно работало. Единственное что раздражало - долгий запуск (после ST - вообще все остальное ощущается как "долго"). Недавно пересел на топовый MacBook Pro 2015 года, стало еще шустрее, особенно холодный запуск. Если скорость - приоритет, тогда ST. Если же приоритет в удобстве работы, нормальной отладке и тд - тогда шторм, без вариантов. Все остальное и рядом не стояло.
500 - это не "страница не найдена". Не найдена - это 404. А 500я - это Internal server error (ошибка в коде). Собственно, включение режима отладки позволило вам увидеть PHP-ошибку.
webdeveloper48: Точными цифрами не владею, из "приближенных к банкам источников" когда-то получил совет в стиле "все что меньше 5к за раз и 10к за месяц никому не интересно", при больших суммах - как повезет. В общем, если вы физлицо и налоги не платите вообще - могу посоветовать переводить на приватовскую карту только часть денег (не более 5к в месяц), а если есть больше - завести себе депозит где-нибудь на Кипре и перекидывать туда. На 5ку в месяц жить в Украине можно припеваючи. Если же вы ПП - переводите все и платите налоги. И можно спать спокойно.
webdeveloper48: Все верно. Банк у вас ничего не спрашивает, им плевать. Если суммы будут относительно большими, они могут сообщить в валютных контроль об этом. Налоги их не касаются. У меня Skrill в евро и приватовская карта Visa Gold (неименная, дополнительная к универсальной гривневой MasterCard Gold которая именная с фото).
razvedkeslava: В сети есть куча уроков на эту тему, ничего супер-сложного в этом нет. Главное понять как это реализовать в рамках архитектуры WordPress. Дальше, если есть знание PHP все весьма просто. Самое объемное - это валидация данных из форм, но и тут WordPress практически большую часть работы сделает за вас, если использовать его функции. Открываете уроки, продумывайте архитектуру, а дальше документацию по функциям WP в зубы и пилить.
razvedkeslava: Если кратко, вариант 1 - страницы, управление доступом к ним + динамические данные. Вариант 2 - вирутальные страницы, создаете rewite_rules для нужных эндпоинтов и выводите в них динамические данные. Саму основу / механику личного кабинета сделать можно быстро.
razvedkeslava: Как раз сам кабинет делается очень просто, а вот его функционал - редактирование данных, объявлений и тд - это все как раз и есть ФОРМЫ :)
Alex: Очень хорошо заглядывал. Как и сам WordPress, как и многие другие плагины, код не самый лучший, да. Но он работает и нормально выполняет свои задачи. Я на разных проектах перепробовал практически все плагины для форм, включая разработку самостоятельно с нуля. Упомянутые 2 являются оптимальным соотношением возможностей, гибкости, надежности и стабильности per dollar. Кратко - да, это не фонтан, но оно работает. Можно использовать на начальном этапе для сокращения сроков разработки и стоимости, в дальнейшем можно запилить свое кастовое решение.
Alex: Вы меня не совсем правильно поняли. Если речь идет о сайте для конкретного бизнеса, с конкретными задачами и особенностями, то такой сайт никогда не делается один раз и навсегда, он делается, а потом постепенно доделывается / переделывается / развивается на ходу. Так вот в средней и длительной перспективе ДЕШЕВЛЕ получается делать изначально свой код под конкретные задачи и его же в дальнейшем поддерживать и развивать. Использование готовой темы (в реальности использование 10-30% функционала комбайна в стиле 1000 в 1м) + ее доработка напильником к моменту запуска может обойтись дешевле, но в средней перспективе выйдет заметно дороже. Кроме того, со временем есть риск того, что упираетесь в потолок возможностей / несоответствие конкретным задачам, и в итоге данная тема сильно переделывается и уже мало что общего имеет с оригиналом, нет возможности ее обновлять из оригинала, и в итоге вам приходится самому поддерживать весь этот legacy code, который содержит кучу ненужного вам кода и который вы не писали.
Покупка готовой темы, тем более без учета конкретного рынка - самый плохой и ошибочный способ. Потому что вы заплатите 70 долларов за тему, а потом еще НАМНОГО больше за доводку под свои нужды.
