Aleksandr Yurchenko, на практике вам это вряд ли когда-либо понадобится. Если это становится очень узким местом (не просто "не нравится", "не удобно", а именно узкое место, вызывающее проблемы), значит пора уходить с WP на что-то другое. Это не означает, что нельзя свои таблицы в БД создавать. Можно и нужно, там где это уместно. Но для базовой функциональности (custom post types включая страницы, записи и вложения, custom taxonomies, users и тд) как правило это стрелять себе в ногу. Лучше использовать метаданные (postmeta), а если нужен поиск - Elastic Search.
driverx18, сначала выполняется задача и перезаписывает существующие данные. Пока она выполняется, пользователи получают предыдущую закешированную версию. В обеих случаях вы упустили ключевой момент - пользователь НИКОГДА не выполняет ресурсоемкую задачу, он ВСЕГДА получает данные из кеша, пусть даже устаревшие.
Дмитрий Чижов, разумеется. Но сначала нужно написать самому в нескольких разных формах. Когда проходишь основы программирования / базу ЯП то подобные задачки обычно идут одна за другой, и люди достаточно быстро учатся с ними справляться. И часто сами задания предусматривают, что ученик напишет говнокод, чтобы потом увидеть элегантное алгоритмическое решение, которое переведет его на следующий уровень обучения. Быстро сдаться и пойти на Тостер - самый легкий путь, имхо. Но у каждого свой путь, объем терпения и усидчивости, поэтому я не осуждаю никого и поэтому дал человеку ответ.
Евгений Ромашкан, разумеется баланс должен быть. В данном конкретном случае у нас недостаточно информации, чтобы принимать решение за автора. Впрочем, по поводу json я бы наверное возразил - это дополнительные знания, которые ТСу надо получать. Не стоит усложнять, имхо. Тем более а вдруг придется кроме картинок добавить еще какой-нибудь док, а потом к ним метаданные хранить? Вот тут затея с json уже и боком начинает вылазить. Адекватная же нормализация практически гарантированно избавляет от данных проблем в дальнейшем. Когда говорят "нормализация не всегда хорошо", обычно имеется в виду "по книжке" - минимум 3я нормальная форма, а лучше 4я. Здесь мы настолько не упарываемся.
NikSIk31, А если вас беспокоит "лишний" (на самом деле нет) запрос, то в SQL есть такая штука как JOIN, которая позволит получить все одним запросом. К примеру, по таблицам выше грубо можно запросить так:
SELECT * FROM tasks
JOIN photos
ON tasks.id=photos.task_id
WHERE task_id=1;
и получить:
id title id task_id path
1 First task 1 1 photos/1.jpg
1 First task 2 1 photos/2.jpg
NikSIk31, Да, так рациональнее. Это называется нормализация, и реляционные базы данных как раз вот об этом - мухи отдельно, котлеты отдельно, а между ними связь.
Виталий Хоменко, для этого я снабдил код комментариями. А так то да, согласен. У меня вот жена Swift сейчас изучает (до этого с программированием не имела ничего общего), она такие задачки сама пилит, хотя иногда приходится посидеть и потупить пару часов. Но на выходе у нее всегда мощный прилив мотивации и реально усвоенный урок. Раз и на всю жизнь. А на Тостере спросить - это читерство самого себя :)
В задаче нету ограничения на то, что буквы/комбинации начнут повторяться по мере накопления итераций. Это простая задачка на базу ЯП, здесь нужно каждый раз получать уникальное значение, в котором эти буквы не повторяются, и здесь автор пошел в принципе правильным путем. Но 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, все верно. Какая зависимость скорости загрузки страницы с вот этим: