Advanced-cache.php и вкрапления на сайте WordPress
Вкрапления и advanced-cache.php
Итак, приступим. Ведёте вы свой блог, устанавливаете различные плагины. И в один прекрасный день вдруг замечаете в разделе Плагины вкладку Вкрапления. А зайдя в неё, наблюдаете такую картину:
Хорошо. Немного понятно. Но не совсем. Кто же и что поместил в папку wp-content? Ниже отображается какой-то расширенный плагин кэширования advanced-cache.php.
Так вот, это и есть тот самый файл, помещённый в папку. А поместил его туда установленный нами плагин WP Fastest Cache. Либо какой-то подобный. Например, WP Super Cache.
Advanced-cache.php требует define(‘WP_CACHE’, true);
А именно, чтобы мы разместили код define(‘WP_CACHE’, true); в файле wp-config.php. Так давайте это и сделаем. Копируем код:
Далее проходим на хостинг в Файловый менеджер. Открываем корневую папку сайта. И находим в ней файл wp-config.php. У меня он имеет такой адрес:
Затем вставляем туда скопированный код. И будет это выглядеть примерно таким образом:
Можете вставить и в другое место. Сохраняем. Готово. Теперь давайте вернёмся к вкладке Вкрапления.
Чудно! Картина изменилась. Раз исчезло сообщение о неактивности, значит проблема решена. И WordPress нам сообщает, что на сайте работает наш файл для страничного кэширования advanced-cache.php.
Кстати, можете зайти в корневой каталог и открыть файл wp-settings.php. Он находится там же. И нажав Ctrl+F, ввести в строку поиска advanced-cache. Перед вами появятся строки кода, отвечающие за вызов этой функции. А в wp-config мы как раз её и включили.
На этом всё. Думаю, сложностей у вас не возникло. До новых встреч! 😉
Как полностью удалить плагин W3 Total Cache
Главное меню » Блог-платформа wordpress » Как полностью удалить плагин W3 Total Cache
Вы можете столкнуться с различными вопросами, такие как:
В любом случае, независимо от причины, вы хотите избавиться от W3 Total Cache, не так ли? Я начал делать то же самое, но во время удаления, выяснил, что это не так, как любой другой плагин, который может быть полностью удален путем деактивации и удаления из WP. Это такой сильный плагин, даже после деинсталляции с WordPress, он оставляет много следов на сервере. Вам необходимо удалить их вручную, чтобы полностью удалить W3 Total Cache.
На этом уроке я покажу вам как полностью удалить плагин W3 Total Cache из вашего блога WordPress.
Шаги для удаления W3 Total Cache:
Шаг № 1 :
Шаг № 2 :
Теперь перейдите к плагину, и отключите W3 Total Cache, а затем удалите его.
Шаг № 3:
Если был бы любой другой плагин, вам не нужно было бы делать что-нибудь еще. Плагин должен исчезнуть полностью, без каких-либо отметок. Но для W3 Total Cache вам нужно сделать немного больше очистки.
Теперь пришло время, чтобы перейти в корневую директорию вашего сайта с помощью логина на вашей хостинг панели. Переход к файлу управления> выберите домен> ‘wp-content‘ и удалите следующие файлы:
Существует возможность того, что вы не сможете увидеть их все. Так что если вы найдете только один или два, просто удалите их. Я бы рекомендовал сделать резервную копию вашего каталога ‘wp-content‘. Так что если вы ошибочно удалите любой файл и ваш сайт станет недоступным, вы всегда можете восстановить рабочую версию.
Там может быть еще три директории в той же папке;
Шаг # 4
Шаг # 5 – Дополнительный
Я бы не рекомендовал вам сделать этот шаг, если вы решите не использовать любой другой плагин кэша как Comet Cache. Кэш плагинов очень полезен. Хотя у вас может быть плохой опыт с W3 Total Cache но до вы должны использовать один из плагинов кэширования, как WP Super Cache или Comet Cache.
Но если вы думаете, что этого было достаточно, перейдите в корневую директорию вашего сайта снова и отредактируйте файл wp-config.php. Это один из ключевых WordPress файлов, так что сделайте резервную копию на локальном диске, прежде чем сделать что-нибудь с ним.
Теперь попытайтесь найти эту строку ‘define (WP_CACHE’, true);’. Это должно быть в пределах первых 4-5 строк. После того, как вы это обнаружите, вы можете либо удалить всю строку либо изменить ее на ‘define (WP_CACHE’, false);’.
Слова предостережения : Опять, вы не хотите сделать этот шаг, если вы собираетесь переключиться на другой плагин кэширования. Поскольку эта команда будет конфликтовать и не позволит какому либо другому плагину кэширования работать, если вы не измените его снова с файле wp-config.php.
Подводя итоги:
Ну, плагин W3 Total Cache, несомненно, является одним из самых полезных и надежных плагин. Есть много людей, использующих этот плагин, не сталкиваясь с какой-либо проблемой. Я хотел бы предложить вам, дать ему второй шанс перед удалением. Вместо удаления, независимо от проблемы W3 Total Cache просто попытаться найти решение этой проблемы. Если проблема не на сервере, то вы можете, конечно, работать с ним.
Тем не менее вопрос, как вы удаляли W3 Total Cache? Не стесняйтесь высказать мнение в комментарии.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Страничное кеширование в WordPress
В последнее время на Хабре появилось довольно много постов по данной теме, но по своей сути их можно назвать: «Смотрите, я поставил Varnish / W3 Total Cache и держу миллион запросов на «Hello world» страничке». Данная же статья рассчитана больше на гиков, желающих познать, как же это все работает и написать собственный плагин для страничного кеширования.
Зачем?
Приступим
Какие инструменты предоставляет нам WordPress?
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:», так как их удобно использовать в регулярных выражениях. Например получить все ключи по определенному хосту:
Выдача из кеша
Тут все просто, если кеш уже создан, то выдаем его пользователю и завершаем выполнение.
Совершенствуем
Усложняем задачу
Допустим, наш сайт отдает разный контент для пользователей из разных регионов или стран. В данном случае ключем кеша должен быть не только URL страницы, но и регион:
По данному принципу мы можем формировать разный кеш разным группам пользователей по любым параметрам.
wp_cache_postload()
Данная функция вызывается после загрузки ядра и ее тоже удобно использовать в некоторых случаях.
По опыту скажу, что такой вариант работает гораздо стабильней:
На момент вызова wp_cache_postload(), функция add_action уже существует и ей можно пользоваться.
Бывают ситуации, когда для формирования ключа кеша нужны данные, которые невозможно получить из cookie, IP и прочих доступных на этапе инициализации ресурсов. Например нужно генерировать индивидуальный кеш для каждого пользователя (иногда это имеет смысл).
Как видно в примере, вся логика помещена в тело wp_cache_postload и тут уже доступны все функции платформы, включая get_current_user_id(). Данный вариант немного медленней предыдущего, но мы получаем безграничные возможности для тонкой настройки страничного кеша.
Ускорение WordPress. Тотальный разбор плагинов для кэширования. Личный опыт (часть 2)
Комментарии 32
спасибо, интересно + узнал пару новых фич
Спасибо за комментарий 🙂
Какой принцип работы автокеширования?
cron?
Кроме W3 Total Cache
но на других страницах, куда могут быть подгружены эти записи, например, на главную, кеш обновлен не будет, а соответственно, добавленная или измененная запись там не появятся ровно до тех пор, пока не истечет время жизни предыдущего кеша
Это решается другими плагинами? Если да, то как
Также укажем значения «Максимальное время жизни кэшированых объектов» и «Период удаления устаревшего кэша»
Как это реализовано?
Тем не менее вторую проблему (долгая загрузка страниц в период обновления кеша) решить невозможно
Он что, сначала удаляет кеш, а потом заполняет?
чтобы кеш обновлялся не по таймеру, а только при внесении изменений
Какой принцип работы автокеширования?
Любой из представленных плагинов позволит организовать автокеширование как на хитах (WP CRON), так и через планировщик (CRONJOB). При настройке, каждый может выбрать для себя наиболее удобный вариант. При тестировании я пробовал как WP CRON, так и CRONJOB. Если на сайте есть хоть какой-то более-менее адекватный трафик, разница заметна не будет
Это решается другими плагинами? Если да, то как
Он что, сначала удаляет кеш, а потом заполняет?
Судя по всему, он в фоне пытается выполнить еще и другие операции, от чего конечный пользователь видит крайне долгую загрузку страницы
Когда администратор сайта вносит какие-либо изменения, Swift perfomance запускает переобход страниц с целью обновления кеш-файлов автоматически, а не дожидается истечения срока жизни кеша.
Пробовали, замеры как раз проводились на сервере с nginx + apache. Только вот, к сожалению, наличие nginx не позволяет сократить число запросов к БД при загрузке страницы сайта на базе WordPress, на котором отсутствует плагин кеширования.
Nginx, действительно, позволит значительно сократить общую скорость загрузки веб-сайта, но на TTFB (основная метрика, о которой идет речь в статье) он практически не повлияет.
Позволяет, советую разобраться в кешировании в целом, а не в плагинах вордпресса
Спасибо. Классно разобрано. Про get запросы не задумывался даже.
Я когда смотрю американские обзоры, там WP rocket прям обожают и в бенчмарках он чемпион.
Вы его просто обошли стороной.
Почему такая разница получается?
Мне тоже по первости понравился WP Rocket. Удобный интерфейс, простая настройка. Но по крайней мере в моём случае, на нескольких сайтах с совершенно разным окружением (VDS слабый, VDS мощный, шаред-хостинг) он повёл себя нестабильно.
Есть у меня один клиент, которому крайне важен аптайм, при этом сайт небольшой (страниц 100-150), трафик тоже не особо (
Далее, если повезет и всё-таки WP Rocket сможет построить кеш (хотя бы части страниц), по неизвестной для меня причине он периодически «отваливается» как будто бы никакого кеша и не было построено.
WP Rocket не кеширует страницы с GET-параметрами, которые заранее не указаны. Не знаю, можно ли это назвать какой-то критичной проблемой, но хотелось бы иметь подобную настройку, чтобы разрешить или запретить кеширование подобных страниц, как это реализовано у WP Super Cache.
Также, стоит отметить, что CRON-задача «rocket_purge_time_event» очищает сразу все кеш-файлы с истекшим сроком жизни, а не формирует их последовательно. rocket_purge_time_event привязывается к моменту начала предзагрузки кеша и запускается через промежуток времени, указанный в настройках, а вот «rocket_preload_cron_interval» выполняется каждые 5 минут. Соответственно, даже на небольшом сайте мы можем получить следующую ситуацию: срок жизни кеша истек, кеш-файлы были удалены, rocket_preload_cron_interval еще не запустился и в течении 5 минут на сайте пользователи видят долгую загрузку, как будто бы никакого кеширования и нет, через 5 минут запускается формирование новых кеш-файлов и работает довольно продолжительное время (в моем случае 6 минут на 160 страниц) и в этот период пользователи видят еще более долгую загрузку страниц, значительно превышающую скорость загрузки страниц без каких-либо плагинов кеширования.
ИТОГО:
В момент предзагрузки кеша, WP Rocket создает огромную нагрузку на сервер (пусть и кратковременную). Подобная нагрузка вполне может «положить» сервер, особенно если страниц на сайте довольно много.
Процессы предзагрузки и очистки кеша ведут себя нестабильно.
Автоматическое кеширование очищает сразу все просроченные кеш-файлы, а не заменяет их последовательно (как, например, это делает WP Fastest Cache), соответственно, существует промежуток времени, когда сайт у конечных пользователей работает критически медленно.
Нельзя разрешить кеширование страниц с GET-параметрами, которые не указаны в настройках
Невозможно исполнять PHP-логику на закешированных страницах
WordPress. Кеширование
Кеширование данных позволяет ускорить работу сайта и существенно снизить нагрузку на сервер. В ядре WordPress существует три основных вида кеширования — кеширование страниц (page cache), кеширование объектов (object cache) и транзитное кеширование (transient cache).
Кеширование страниц
Для выдачи одной страницы архива приходится проделывать много работы. Это множество запросов в базу данных — чтобы получить последние записи, настройки виджетов, настройки темы, активные плагины, название и описание сайта и так далее. Кеширование страниц (page cache) позволяет сохранить результат выдачи страницы целиком в кеш и при последующем запросе этого URL выдать страницу уже из кеша.
При изменении содержания записи или странцы, кеш страницы сбрасывается, и при последующем запросе кешируется уже новая страница с обновлёнными данными. В самом ядре WordPress кеширование страниц не реализовано, но есть все необходимое для реализации этого на уровне плагинов.
Кеширование объектов
Объектное кеширование (object cache) реализовано в самом ядре WordPress. Механизм позволяет хранить объекты произвольного типа в памяти и используется практически для всего: опции, записи, страницы, метки, категории, пользователи и многое другое.
Время жизни кеша объектов
В WordPress есть возможность использовать внешнее хранилище для кеша объектов, например Memcached или Redis, при этом кеш объектов становится постоянным. Это значит, что при следующем обращении к странице сайта, ранее закешированные значения по прежнему доступны. Для этого нужно создать файл object-cache.php в директории wp-content и реализовать в нем класс WP_Object_Cache и все перечисленные выше функции.
Транзитное кеширование
Транзитное кеширование чаще всего используется для хранения данных, когда речь идёт о запросах на внешние ресурсы, например для вывода сообщения из сети Twitter или для вывода прогноза погоды со стороннего сервиса. Подобное кеширование так же используется в ядре — при запросах на обновление тем, плагинов и ядра.