В задаче нету ограничения на то, что буквы/комбинации начнут повторяться по мере накопления итераций. Это простая задачка на базу ЯП, здесь нужно каждый раз получать уникальное значение, в котором эти буквы не повторяются, и здесь автор пошел в принципе правильным путем. Но explode и работа с массивом (даже по индексу) - это неправильный путь.
Александр Навальный, из ваших скриншотов достаточно сложно суть уловить, там too much information. Мой ответ о другом - есть хук template_include. В нем можно проверить нужное условие и принудительно заставить WP использовать именно тот шаблон, который вы хотите, минуя механизм автоматического определения шаблона по URL. Вопрос остается в нужном условии. Вы говорите, что это дочерняя страница таксономии. Вот это условие изолизуйте, и все будет пучком.
Twitt, да, все верно. Вот пример по одной из таблиц первой попавшейся БД:
Кардинальность колонки meta_id равна количеству записей в этой таблице. Но для характеризации степени уникальности данных в целом обычно используется темринология low / normal / high cardinality, этого достаточно чтобы понимать ситуацию. Конкретные цифры смотрите по конкретному столбцу конкретной таблицы и действуете исходя из этих данных (например, думаете как лучше нормализовать схему).
Сергей, честно говоря не уловил суть вопроса и недостаточно информации. " slug категории из url" - что вы здесь имеете в виду? Что это за URL? Слаг у вас в виде GET параметра или часть permalink? По сути вы хотите динамически брать запрошенную категорию и передавать ее в функцию ch_get_menu_of()?
m4son, данный код лишь добавляет селект со значениями для фильтра. Вам еще сам query нужно модифицировать - проверить передано ли значение из этого селекта и если да, то применить его как параметр WP_Query. Смотрите в сторону pre_get_posts
xxx44yyy, Я думаю что подсказать вам конкретный плагин который идеально подойдет под ваши требования и удовлетворит своим интерфейсом и концепцией работы с переводами будет весьма сложно. У всех свои ожидания и предыдущий опыт. К тому же, у многих плагинов совершенно разный подход на уровне концепции. WPML и Polylang хранят переводы как отдельные записи, которые в отдельной таблице БД связаны с оригиналом. Это удобно, если у вас полностью зеркальные версии - одинаковая структура URL, одинаковые страницы и тд. Есть плагины, которые позволяют создавать мультиязычку на базе WordPress Multisite - здесь каждый язык это отдельный сайт сети. Переводы связываются между собой по site_id.entry_id. Но в этом случае у вас уже есть возможность не поддерживать зеркальный режим - каждая версия вообще может иметь разную структуру и набор страниц (и других типов данных). Есть еще qTranslateX с его подходом не создавать отдельных записей, а хранить все переводы в одних и тех же полях, разделяя спецразметкой. Но если потом решите избавиться от этого плагина или перейти на другой, то весь контент в БД у вас по сути будет мусором из спецразметки и миграция превратится в головную боль.
Что касается платности решений... Тут мне тем более сложно вам что-то рекомендовать, так как сам я всегда выбираю в первую очередь качественное решение конкретных проблем, цена не является критическим фактором (если она не заоблачная). Много лет использую WPML и в целом доволен. Раньше использовал бесплатную версию Polylang и тоже был доволен, но она была более ограничена функционально и со временем нужные фичи стали платными, что в итоге выходило даже дороже чем WPML. Поэтому купил WPML и не парюсь, цена не кусается. Клиентские сайты покупают лицензию себе сами.
ThunderCat, Я не говорю про конкретную имплементацию в виде архитектуры БД, а про концепт в целом. Если речь об однопоточном диалоге как личка в мессенджерах, то ID диалога конечно не нужен. Если нужно возможность изолировать конкретный "диалог" (например, как отдельная переписка с представителем службы поддержки по одному отдельно взятому вопросу), то тогда добавляется ID этого диалога. Возможно, меня сбила с толку сама формулировка - "диалог". Одно сплошное полотно обычно называют просто "сообщения", а термин "диалог" как раз чаще употребляется в контексте отдельных "сессий сообщений" (или треда). По крайней мере мне доводилось работать с этим термином именно в таком контексте.
Сёмка Гавриленко, угу, как только мы данную фичу внедрили, у нас добавилось 2 запроса к БД - получить счетчик (чтение) и инкрементировать (запись). Эти запросы добавили определенный overhead, все верно. Какая зависимость скорости загрузки страницы с вот этим:
ну я нигде в тексте не видел, что он джун в в лодке из fortune 500 :)
человек спросил совета, я привел пример как разговаривать с не-разработчиками их языком. Масштабы разные, суть одна.
Иван Шумов, совершенно верно. И выживать / добиваться своих целей в этой среде можно только таким же путем - освоить бюрократические скилы и пользоваться.
Иван Шумов, И да, даже если ты младший разработчик в энтерпрайзе, то все остается актуальным, меняется только схема. Сначала мысль доносим до лида, потом до CTO, а потом совместными усилиями - до бизнеса. Сложность данного процесса конечно зашкаливает, вероятность положительного исхода стремится к нулю, но все же.
Иван Шумов, внимательнее читаем - я не их младший разработчик, а внешний вендор, senior и в то же время консультант, к которому обращаются с проблемами и получают решения.
Иван Шумов, Зависит от конкретной компании и ее размера, количества отделов вверх и ЛПРов, размера проекта и еще многих параметров. Поделился личным опытом из крупной международной компании где мы с командой выступаем разработчиками сайтов компании и поддерживаем их, по long term контракту. Разговоры о необходимости рефакторинга велись с нашей стороны в течении 2х лет - эффекта ноль. Одна качественная презентация, для которой были собраны нужные люди менее чем за час позволила принять все необходимые решения, вдогонку переписать и переоформить контракт поддержки, который был существенно расширен и добавлены часы на рефакторинг.