@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, так как мы обращаемся непосредственно к методу объекта, пребывая в данный момент в нем самом) и модифицировать запрос исходя из того, на какой странице он выполняется.
@nezzard cache_results = true (по умолчанию именно true) кеширует РЕЗУЛЬТАТЫ запроса в память (Memcached, APC - смотря что используется), то есть, в следующий раз при ЭТОМ ЖЕ запросе, выборка из БД производиться не будет, готовые результаты будут взяты из кеша. В 99,9% случаев именно такое поведение вам и надо, так что не заморачивайтесь этим параметром, оставьте по умолчанию.
@nezzard нет, не будет. Но для больших проектов разумно немного изменить формат запросов (это уже "продвинутая практика"), чтобы не использовать SQL_CALC_FOUND_ROWS, так как на таблицах без индексов он работает медленно. Быстрее будет одним запросом сделать SELECT COUNT а вторым собственно SELECT. Но пока Вам это не надо, поверьте :) Когда надо будет - почувствуете ;)
@nezzard по поводу pre_get_posts еще раз внимательно читаем мой коммент :) В самом php-коде есть комментарий, который объясняет как использовать модификации для разных страниц. И это все в одном месте, гибко и удобно.
@nezzard 1. Через хук будет самый быстрый вариант. Типы записей на скорость никак не повлияют. Кеширование тут будет родное, через WP Object Cache, при использовании бекенда для кеширования (memcached, apc и тд) все будет корректно кешироваться. Не путайте с кешированием страниц - это разные вещи. Запросы в БД можно и нужно кешировать в памяти. 2. Использовать эти аргументы в functions.php или в своем отдельном маленьком плагине - без разницы, на скорость не влияет. Лучше, конечно, свой плагинчик маленький - тогдп при смене темы все останется и будет работать как надо.
@nezzard количество постов в базе не имеет значения, пока это запрос по стандартным параметрам. Если начнете сортировать и выбирать посты по meta_key - вот тогда начнется МЕДЛЕННО :) Почитайте мой коммент ниже. Я сейчас делаю огромный проект на WordPress Multisite, там у меня одних только custom post types уже 14 штук, custom taxonomies - 24 штуки. В таблице wp_posts на данный момент больше 200 000 записей, и это только начало, мы еще официально не запускались. Все это летает на VPS сервере с 1Gb оперативки и 1 виртуальным ядром, сейчас трафик небольшой - 1-2 тысячи в день. Эмулировали нагрузку до 100 000 в день - сервер выдерживал. Один скромный сервер.
@nezzard смотрите мой коммент ниже. Если все делать правильно, то будет только быстрее. Если делать неправильно - будут проблемы не только со скоростью, но и с непредсказуемым поведением других функций. А вообще по скорости вывода 10 последних постов можете не заморачиваться. В вашем случае это всегда будет быстро.
папка (часть пути) на домене (пример an.ua/fastov) не может вообще рассматриваться как "проект внутри, с которым пересекаются", это ПАПКА, всего лишь одна из частей проекта, и поисковиком никогда не рассматривается как нечто отдельное или самостоятельное. Поддомены - это как раз то, что нужно автору. Поисковик по поддоменам смотрим, если основной сайт и поддомены между собой залинкованы, используют один движок и код, то он его воспринимает именно так, как надо автору - как автономные части ОДНОГО целого проекта.
