WordPress. Порядок загрузки страницы
Итак, пользователь набрал в адресной строке браузера URL WordPress-сайта и нажал Enter. Произошел резолвинг доменного имени, и браузер обратился по конкретному IP-адресу к хостинг-серверу с запросом на загрузку сайта. Что происходит дальше в последующие доли секунды, пока сайт не отобразится в окне браузера?
1. Загрузка файла wp-load.php
Все начинается с загрузки файла wp-load.php в корневом каталоге сайта.
2. Загрузка файла wp-config.php
Это главный конфигурационный файл, содержит информацию для подключения к базе данных и устанавливает некторые константы.
3. Загрузка файла wp-settings.php
Установка значений констант WP_MEMORY_LIMIT , WP_MAX_MEMORY_LIMIT , WP_DEBUG , SCRIPT_DEBUG , WP_CONTENT_DIR , WP_CACHE и других.
4. Загрузка файла advanced-cache.php
Загрузка advanced-cache.php , если этот файл существует. В терминологии плагинов WordPress этот файл является так называемым «вкраплением». Он создается автоматически, если на сайте установлен один из кеш-плагинов. Этот файл содержит конфигурационную информацию для работы кеширования.
5. Загрузка файла wp-content/db.php
WordPress позволяет разработчикам создавать свои абстрактные слои БД и загружать их через файл db.php . Как правило, этот файл используется кеш-плагинами для оптимизации работы БД. Поэтому, если такой файл существует, он загружается на этом этапе.
6. Подключение к базе данных
Соединение с сервером MySQL и подключение к указанной в wp-config.php или db.php базе данных. Если по какой-то причине WordPress не удается подключиться к БД — будет выдано сообщение «Error establishing database connection».
7. Загрузка файла object-cache.php или wp-includes/cache.php
Загрузка файла object-cache.php , если такой есть. Если нет, попытка загрузить файл cache.php в директории wp-includes . Если и этого файла нет, то следующий шаг.
8. Загрузка файла wp-content/sunrise.php
Если сайт является частью сети (режим Multisite), то будет загружен файл wp-content/sunrise.php .
9. Загрузка библиотеки локализации
Загрузка файла wp-includes/l10n.php для включения системы локализации. На данном этапе будет учтен выбранный язык, региональные параметры и файлы для перевода.
10. Загрузка must use плагинов
Загрузка обязательных к использованию плагинов. Это плагины, которые устанавливаются в специальную папку mu-plugins и которые всегда активны для сайта и сайтов сети.
11. Запуск события muplugins_loaded
Т.е. будет вызвана функция do_action() с параметром muplugins_loaded . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .
12. Загрузка всех активированных плагинов
Список активированных плагинов хранится в таблице wp_options базы данных, имя опции — active_plugins . Таким образом на этапе загрузки игнорируются все установленные, но неактивные плагины.
13. Загрузка файла pluggable.php
Файл pluggable.php хранит функции, которые могут быть переопределены WordPress-плагинами. WordPress проверит, определены ли функции из файла pluggable.php какими-то другими активными плагинами. Если нет, будут определены функции из pluggable.php .
14. Запуск события plugins_loaded
Т.е. будет вызвана функция do_action() с параметром plugins_loaded . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .
15. Загрузка Rewrite Rules
Будут загружены правила преобразования ссылок. Другими словами, на сайте все ссылки будут search engine friendly, вместо ссылок вида www.server.com/?p=12345
16. Инициализация $wp_query, $wp_rewrite, $wp
Инициализация глобальных переменных:
- $wp_query — содержит экземпляр класса WP_Query
- $wp_rewrite — содержит экземпляр класса WP_Rewrite
- $wp — содержит экземпляр класса WP
17. Запуск события setup_theme
Т.е. будет вызвана функция do_action() с параметром setup_theme . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .
18. Загрузка файла functions.php дочерней темы
Файл functions.php содержит набор функций, применимых для каждой темы оформления индивидуально. При использовании дочерней темы, на на данном этапе будет загружен functions.php именно дочерней темы.
19. Загрузка файла functions.php родительской темы
Если используется дочерняя тема, то после загрузки functions.php из дочерней темы будет загружен functions.php родительской темы.
20. Запуск события after_setup_theme
Событие запускается после того, как WordPress определился с тем, какая тема оформления активна на данный момент, и загрузил ее файл functions.php .
21. Настройка текущего пользователя
Теперь WordPress загружает объект текущего пользователя. Это позволяет понять, какие запросы могут быть выполнены в дальнейшем в соответствии с текущей ролью пользователя и его привилегиями.
22. Запуск события init
На данном этапе WordPress загрузил уже все необходимое для работы. Это самое популярное событие у разработчиков — ядро загружено, плагины и тема активированны, пользователь авторизован, но на экран еще ничего не выведено.
23. Запуск события widget_init
Событие позволяет регистрировать виджеты и выполнять код, необходимый для их работы.
24. Выполнение функции wp()
Теперь WordPress вызывает функцию wp() из файла wp-includes/functions.php . Эта функция устанавливает основной запрос, т.е. среду WordPress.
Посмотрим на код, как устанавливается среда WordPress:
Фильтр request срабатывает в конце метода WP::parse_request() , позволяя изменить свойство WP::query_vars , которое содержит переменные запроса, используемые в методе WP::query_posts() .
Фильтр parse_request срабытывает в конце метода WP::parse_request() , сразу после фильтра request . В фильтр передается экземпляр класса WP по ссылке, так что можно изменить не только переменную класса $query_vars , но и другие переменные.
Фильтр pre_get_posts срабатывает абсолютно для всех запросов, не только для основного. Для основного запроса (из кода выше) он срабатывает во время вызова метода WP::query_posts() , т.е. после request и parse_request .
Фильтр wp срабытывает в конце метода WP::main() , в этот момент записи уже получены. В фильтр передается экземпляр класса WP по ссылке. Это самое раннее событие, когда работают условные теги.
25. Запуск события template_redirect
Событие происходит прямо перед тем, как WordPress определяет, какой шаблон должен быть использован.
26. Загрузка feed-шаблона для RSS
Если запрашиваемый контент относится к RSS-feed, WordPress загружает соответствующий feed-шаблон.
27. Загрузка основного шаблона (темы)
WordPress начинает загружать файлы текущей активной темы в соответствии с ее иерархией. Как правило, все начинается с файла, который содержит главный цикл.
28. Запуск события shutdown
В самом конце, перед завершением исполнения всего PHP-кода WordPress запускает последнее событие shutdown . На этом этапе работа WordPress закончена.
Страничное кеширование в WordPress
В последнее время на Хабре появилось довольно много постов по данной теме, но по своей сути их можно назвать: «Смотрите, я поставил Varnish / W3 Total Cache и держу миллион запросов на «Hello world» страничке». Данная же статья рассчитана больше на гиков, желающих познать, как же это все работает и написать собственный плагин для страничного кеширования.
Зачем?
Приступим
Какие инструменты предоставляет нам WordPress?
- обычные плагины
находятся в wp-content/plugins
администратор может их свободно устанавливать, активировать и деактивировать; - обязательные плагины
находятся в wp-content/mu-plugins
данные плагины включаются автоматически и не могут быть деактивированы; - системные плагины
находятся в wp-content
позволяют переопределять классы ядра или внедрять в них собственный функционал;
к ним относятся:- sunrise.php
Подгружается в самом начале инициализации ядра. Чаще всего используется для domain mapping; - db.php
Позволяет переопределять стандартный класс для работы с базой данных; - object-cache.php
Позволяет переопределись стандартный класс объектного кеширования, например если захотите использовать Memcached или Redis; - advanced-cache.php
Позволяет реализовать страничное кеширование, то что нам и нужно!
advanced-cache.php
Для того, чтобы данный плагин начал функционировать, его нужно поместить в директорию wp-content, а в wp-config.php добавить строку:
Если заглянуть в код WordPress, то можно увидеть, что данный скрипт подгружается на раннем этапе загрузки платформы.Также, после загрузки ядра, CMS попытается вызвать функцию wp_cache_postload(), но о ней позже.
Хранилище
Для хранения кеша лучше всего использовать быстрые хранилища, так как от их скорости напрямую зависит скорость отдачи контента из кеша. Я бы не советовал использовать MySql или файловую систему, гораздо лучше с этим справятся Memcached, Redis или другие хранилища, использующие оперативную память.
Мне лично нравится Redis, так как им довольно просто пользоваться, имеет хорошие показатели скорости чтения\записи и как приятный бонус — сохраняет копию данных на жесткий диск, что позволят не терять информацию при перезагрузке сервера.
Разумеется это не полный перечень методов, весь список API можно изучить на официальном сайте, но для большинства задач этого достаточно.
Если на сайте используется прокаченный объектный кеш (object-cache.php), то имеет смысл использовать его API:
Простейшое страничное кеширование
Код нарочно упрощен, многие проверки убраны, дабы не путать читателя лишними конструкциями и сфокусироватся на логике самого кеширования. В файл advanced-cache.php прописываем:
Все, вы получили простейший рабочий страничный кеш, теперь рассмотрим каждый участок детальнее.
Создание ключаВ данном случае ключем является URL страницы. Использование глобальной переменной $_SERVER и хеширования нельзя назвать лучшей практикой, но для простого примера подойдет. Советую добавлять разделяющие участки строки как «host:» и «uri:», так как их удобно использовать в регулярных выражениях. Например получить все ключи по определенному хосту:
Выдача из кеша
Тут все просто, если кеш уже создан, то выдаем его пользователю и завершаем выполнение.Сохранение в кеш
PHP функция ob_start перехватывает весь последующий вывод в буфер и позволяет обработать его в конце работы скрипта. Простыми словами мы получаем весь контент сайта в переменной $html.
Далее сохраняем данные в кеш:
Есть смысл сохранять не только HTML, но и прочую полезную информацию: время создания кеша и тд. Очень рекомендую сохранять HTTP заголовки, хотя бы Content-Type и посылать их при выдаче из кеша.Совершенствуем
- запросы на admin-ajax.php не попадают в кеш;
- если администратор первым посетит страницу, то в кеш попадет его «admin bar» и прочие вредные для пользователей вещи;
Усложняем задачу
Допустим, наш сайт отдает разный контент для пользователей из разных регионов или стран. В данном случае ключем кеша должен быть не только URL страницы, но и регион:
По данному принципу мы можем формировать разный кеш разным группам пользователей по любым параметрам.wp_cache_postload()
Данная функция вызывается после загрузки ядра и ее тоже удобно использовать в некоторых случаях.
По опыту скажу, что такой вариант работает гораздо стабильней:
На момент вызова wp_cache_postload(), функция add_action уже существует и ей можно пользоваться.Бывают ситуации, когда для формирования ключа кеша нужны данные, которые невозможно получить из cookie, IP и прочих доступных на этапе инициализации ресурсов. Например нужно генерировать индивидуальный кеш для каждого пользователя (иногда это имеет смысл).
Как видно в примере, вся логика помещена в тело wp_cache_postload и тут уже доступны все функции платформы, включая get_current_user_id(). Данный вариант немного медленней предыдущего, но мы получаем безграничные возможности для тонкой настройки страничного кеша.Advanced-cache.php и вкрапления на сайте WordPress
Всем привет! Недавно мы установили плагин WP Fastest Cache и сделали его настройки. И сегодняшняя тема будет с этим связана. Мы поговорим о вкладке Вкрапления на сайте WordPress. А также разберёмся, что там от нас требует расширенный плагин кэширования advanced-cache.php .
Вкрапления и advanced-cache.php
Итак, приступим. Ведёте вы свой блог, устанавливаете различные плагины. И в один прекрасный день вдруг замечаете в разделе Плагины вкладку Вкрапления. А зайдя в неё, наблюдаете такую картину:
Отсюда мы видим, что вкрапления — это одиночные файлы, которые при помещении в папку wp-content, заменяют или расширяют возможности WordPress способами, не доступными для обычных плагинов.
Хорошо. Немного понятно. Но не совсем. Кто же и что поместил в папку wp-content? Ниже отображается какой-то расширенный плагин кэширования advanced-cache.php.
Так вот, это и есть тот самый файл, помещённый в папку. А поместил его туда установленный нами плагин WP Fastest Cache. Либо какой-то подобный. Например, WP Super Cache.
Advanced-cache.php требует define(‘WP_CACHE’, true);
Advanced-cache.php — это файл, используемый плагинами для кэширования страниц на сайте. Но в данный момент он неактивен и что-то там у нас требует.
А именно, чтобы мы разместили код define(‘WP_CACHE’, true); в файле wp-config.php. Так давайте это и сделаем. Копируем код:
Далее проходим на хостинг в Файловый менеджер. Открываем корневую папку сайта. И находим в ней файл wp-config.php. У меня он имеет такой адрес:
Затем вставляем туда скопированный код. И будет это выглядеть примерно таким образом:
Можете вставить и в другое место. Сохраняем. Готово. Теперь давайте вернёмся к вкладке Вкрапления.
Advanced Cache PHP вкрапление — что это?
Установил сайт на WordPress. Ну и как подобает – загрузил плагины, настроил тему. В чем собственно вопрос. Заметил в разделе Плагины консоли Вордпресса такое кино – Вкрапления – одиночные файлы, а под ним Advanced Cache PHP расширенный плагин кэширования. Кто подскажет, что это и как исправить?
Вложения:
21 августа, 2021 в 11:21 дп
Так это заезжанная тема. Вы плагин кэширования загрузили какой-то — такой, к примеру, WP Super Cache. Он и поместил этот файл в папку wp-content для замены или расширения возможности CMS. У вас этот файл не активен, поэтому система требует разместить код определения define. Что от вас требуется:
- перейти на хостинг – Бегет там у вас или какой, не знаю;
- открыть Файловый менеджер/корневую папку;
- отыскать файл wp-config.php;
- вставить туда такой код — define(‘WP_CACHE’, true);
- сохранить файл.
Если опыта мало, то сохраните резервную копию данных, чтобы могли восстановить прежнюю версию. Хотя на beget вроде по умолчанию система запоминает, и можно откатать назад.
После внесения кода сообщение о неактивности исчезнет. На сайте начнет работать файл для страничного кэширования.
- sunrise.php