Best practices есть тут https://github.com/Automattic/_s/issues, вперемешку в ответах. Первый шаги, конечно же, будут медленными, это нормально. Со временем накапливается свой собственный код, который базируется на WP и его стандартах и который можно повторно использовать в новых проектах. Тогда становится легче и быстрее. Но это не появляется в один день и сразу. Но очень важно с самого начала начать делать все "канонически", тогда потом меньше надо будет ломать и переделывать, а сам рост будет быстрее. Coding standards, полезный урок. Материалов в сети полно, но одной волшебной пилюли или волшебной стартовой темы, где есть все что нужно и именно так как нужно - не существует. Есть основа, базис. Все остальное - опыт и наработки. WordPress же штука очень гибкая)
@nezzard да, parse_request и parse_query это такие же хуки, как pre_get_posts. Только они выполняются раньше. Первый парсит запрос и транслирует его в переменные, зарегистрированные и понятные WordPress. Второй собственно на основе этого готовит все для запроса. Pre_get_posts позволяет еще до выполнения этого запроса внести какие-то изменения. Дальше идет сам запрос, получение результатов. В процессе есть еще один важный хук - template_redirect. Он на основе данных из parse_query определяет какой шаблон загружать. Эти хуки - это основные моменты для работы с кастомными данными. Понять что пользователь запросил. Подготовить это в понятном виде. Сформировать запрос в бд. Получить результаты и загрузить нужный шаблон. Но в промежутках до, между и после есть еще множество экшнов и фильтров, которые позволяют делать точечные включения и выполнять таргетированные действия. Эта система хуков - одна из очень сильных сторон WP, но вкурить ее целиком - задача непростая. Тем более документации мало. Но! Есть секрет :) На самом деле документация существует. Она находится в коде файлов ядра. Можно лазить по самому коду в проекте (XDebug кстати направит куда надо), либо открыть Trac или Git-зеркало и смотреть там. Весь код WordPress очень подробно задокументирован.
@nezzard есть такое понятие как WordPress Page Lifecycle. Цикл жизни, сценарий, по которому работае система. Один из разработчиков ядра как-то составил схемку - https://tommcfarlin.com/wordpress-page-lifecycle/. Но эта схемка - весьма абстрактна и показывает только основное. По ссылкам которые я дал выше - немного полезной инфы в Кодексе, но она далеко не полная, знаю. Некоторые моменты приходится искать в сети по крупицам, в основном на StackOverflow и в постах разработчиков, так или иначе связанных с WordPress (упомянутый Tom McFarlin - хороший источник, как и Samuel Wood он же Otto, Mark Jaquith и многие другие). Найти их блоги - не проблема. Еще хорошие источники - Paul Underwood, Pippin Williamson. Ну а уже от них можно и остальных найти. Что касается понимания процесса работы WordPress - есть очень хороший способ. Запускаешь XDebug построчно, и смотришь все, что за чем и как происходит. Один такой прогон даст массу полезной информации.
@nezzard работает - и хорошо) Подебажь объекты, посмотри что приходит. Проверка REQUEST_URI - это конечно лоботомия, не скажу что правильный способ, но тоже вариант. Я бы все же шел по каноническому пути (см. коммент выше), так и порядок в системе, и логика в коде. Но, как я уже где-то ранее писал, вордпрес штука гибкая, можно делать по-разному.
@nezzard в принципе, я до сих пор не могу понять, зачем вам сдалось это делать именно на странице, если для этих целей разумнее использовать отдельный шаблон, и, собственно, определять его на уровне parse_query, загружать в template_redirect и формировать запрос с помощью pre_get_posts. Это как раз и есть правильный способ построения кастомных страниц. Ну а с помощью add_query_var и add_rewrite_rule это все окончательно оформляется в нужный нам результат. Но если уж дело так уперлось в страницу - тогда вероятно будет разумнее и проще использовать new WP_Query и смириться с тем, что перед ним будет выполнен основной запрос на пустую страницу (ведь у нее собственного контента нет), и все остальное окружение (виджеты и т.д.) вполне возможно придется допиливать вручную. Тут не уверен, надо тестировать.
@nezzard да, оказывается таки нельзя. Но варианты есть. Кодекс рекоммендует в данном случае все же использовать new WP_Query в самом шаблоне страницы, но я бы посмотрел в сторону более ранних хуков - parse_request, parse_query. Также можно присмотреться к хукам, работающим с SQL-запросом - posts_clauses, posts_join и другие. См. тут и тут.
именно об этом я писал :) но вообще использование данных функций не совсем корректное. Правильно делать так (для всех функций - _e, __, pll_e, pll__ и так далее):
_e( 'String in english', 'text-domain' );
где первый аргумент - собственно строка, на английском, а второй - уникальный домен шаблона/плагина. Именно из-за отсутствия второго аргумента при первой попытке возникали проблемы.
@Aklaim можно придумывать разные варианты, я остановился на том, если сам процесс происходит без резких движений, заметных глазу, то никто попросту не обращает внимания, и вообще думают что так надо, так задумано.
@nezzard кеш имеет смысл чтобы снизить нагрузку на БД. Это главное. Так как дергать постоянно базу для одного и того же - глупо. Насколько часто данные обновляются? Если ежеминутно, тогда кеш не нужен (хотя все равно пригодится, если чеовеку вдруг заманется жать "обновить" несколько раз подряд). Если же обновления реже чем раз в пару минут - кеш точно не помешает. Хуже он не сделает, однозначно.
@nezzard с кастомными полями отдельный геморрой, тут факт. У меня сейчас тоже с ними заморочки. В принципе, да - лучше всего сохранять как мета конкретные айдишки, вытягивать их одним запросом (у вас это получается будет get_user_meta($user_id, 'название_поля')), и уже эти айдишки реальных категорий подставлять в запрос, это будет tax_query в рамках основного запроса. Тогда это не скажется на производительности.
@nezzard нет, кешируется уникальный запрос. По сути, если один и тот же пользователь выполнит один и тот же запрос - тогда он будет взят из кеша. Если это разные пользователи с разными запросами - у каждого свой запрос, свой результат, и соответственно, свой кеш.
@nezzard Если ничего не предпринимать - новый посты появятся только тогда, когда срок жизни кеша закончится. При небольшом сроке - 5 минут, 15 минут, - это вообще не проблема, пост появится как только истечет этот максимальный период. Но можно также дописать одну маленькую функцию, которая будет сбрасывать кеш после добавления поста. Тогда при очередном запросе кеш будет пуст и запрос будет выполнен заново, соответственно, выберет уже с новым постом.
@nezzard вот по custom field (в запросе это уже будет meta_key) как раз начнутся тормоза. Поначалу не особо заметные, а потом все медленнее... Дело в том, что все custom fields хранятся в таблице wp_postmeta в виде значений meta_key, meta_value. И поле meta_value - это тип LONGTEXT, которое индексом не может быть по определению. Поэтому, чтобы выбрать посты по meta_key, придется перебрать построчно всю таблицу, а это уже совсем не быстро. Но это отдельный разговор :)
@nezzard именно! по сути, все вот эти функции is_archive, is_home, is_search - это все методы объекта WP_Query, поэтому в pre_get_posts мы можем этими методами спокойно пользоваться (только синтаксис $query->is_home, так как мы обращаемся непосредственно к методу объекта, пребывая в данный момент в нем самом) и модифицировать запрос исходя из того, на какой странице он выполняется.
