Ressive: ну примера короткого и понятного не получится, надо разбираться с тем что вы уже написали и как сделали архитектуру (если это можно так назвать).
Готового плагина "все в одном" я не встречал. Тут много кастомного функционала писать надо, либо все свое, либо собирать из нескольких плагинов и допиливать недостающее.
Ressive: Нельзя)) Для начала ваш код смотреть надо, определяться с оптимальным решением и потом код пилить. Если намека "писать в мета и проверять его при загрузке страницы" вам недостаточно, боюсь что сами вы код не осилите, даже с примером. Без обид. Просто надо архитектуру понимать. Так что вам сначала в доку наверное.
Izy: вам нужно указывать локальный домен. это может быть localhost, lol.dev, какой угодно - зависит от того какой сервер используете. Но открывать эту папочку надо не по файловому протоколу (D:/projects/lol/ например), а по протоколу http, который будет обслуживаться локальным веб-сервером - Apache/Nginx, с поддержкой PHP.
Опять я к вам в комментарии вклиниваюсь :) Не нужно редактировать шаблоны в папке плагина, изменения слетят при обнове. Копируете папку templates в папку своей темы, называете ее woocommerce и редактируете там. Можно там оставить только нужные измененные шаблоны, остальное грохнуть. WC при загрузке своих шаблонов сначала ищет его в папке темы, если так нет - тогда у себя в папке.
Ressive: А вот тут вариантов много. Даже не знаю с чего начать. Можно постам добавить мета-поле для указания урл перевода и вставлять его с помощью get_post_meta. Можно точно так же в мета-поле указывать пост-перевод, хранить его ID и по нему получать корректный урл с помощью get_permalink( $id ). Это сразу навскидку. Подумать еще 5 минут - и придумается еще парочка способов. Вся беда в том, что у вас переводы между собой не связаны архитектурно. Отсюда и геморрой.
Иван Козлов: К сожалению, документация Кодекса местами устарела. Всегда надо код смотреть. MD5, и то как один из составляющих шагов, сохранился исключительно как legacy (думаю не стоит объяснять почему в WP столько legacy поддержки). По умолчанию он уже некоторое время не используется.
Иван Козлов: Ошибаетесь по поводу легче поддерживать код. Как раз наоборот. Функции ACF учитывают адекватное кеширование, нормализацию данных на вывод и тд, к тому же консистентность. А использовать get_field то тут то там, get_post_meta вперемешку - это усложняет код. К тому же, в большинстве случаев настройки полей ACF учитывают конкретный формат возврата данных, часто с дополнительным получением данных (например, возврат объекта поста из поля relationship - в мета хранится только ID поста). и их кешированием тоже. Это как раз удобнее и корректнее. Я понимаю ваш аргумент по поводу родных функций, но в случае с ACF этот аргумент нерелевентен. Если уж совсем низкий уровень хотите - используйте get_metadata. Ну или SQL, чего уж мелочиться :)
Ressive: нет, get_permalink выдает полную ссылку. Не подойдет. Придется ставить урл руками. Но вообще странно вы это реализовали, почему не использовали какой-нибудь Polylang?
Дмитрий: вы бы хоть ссылку на этот ваш Essential Grid поставили в вопросе :) Вы же не думаете, что люди будут сами гуглить и смотреть че там и как? А вероятность встретить здесь кого-то, кто уже знаком с этой штукой не очень-то и высока.
Ressive: А переводы у вас каким-то плагином реализованы? У всех плагинов есть соответствующие функции. Динамически урл можно подставлять через get_permalink(), но в вашем случае от будет выдавать текущую языковую версию, что не подходит. Строить все УРЛ руками из частей не вариант.
