WordPress кэширование


Wordpress кэшированиеСегодня я предлагаю вам обсудить такую интересную тему как кэширование в wordpress. Первым делом нужно уточнить что такое кэширование и зачем оно нужно? Каждому блоггеру и вебмастеру справедливо хочется чтобы его блог или сайт работал быстро. Как известно WP не обладает рекордно высокой производительность, поэтому зачастую даже хороший хостинг не способен этого компенсировать. А уж если у вас «тяжелый» контент, да еще и высокая посещаемость, дело может быть вообще беда. В любом случае есть возможность ускорить блог почему бы этого не сделать?

Движок WordPress, как уже было сказано выше тяжеловат по своей природе. Все дело в его «динамичности». В отличие от «статичных» платформ WP работает на PHP, который и совершает многочисленные запросы к базам данный, за счет чего собственно и формируется содержимое. К счастью, существует технология способная существенно ускорить процесс, называется она кэширование.


Принцип кэширования в своей основе достаточно прост. Обычно все сводится к тому что тот или иной плагин генерирует из динамических страниц статические, выдавая их в последствие посетителю. При этом серверу не приходится обрабатывать большую часть запросов, что существенно снижает нагрузку на сервер и увеличивает скорость. Теперь давайте переходить к делу. Какие существуют плагины для кэширования и какой из них выбрать? В этом нам поможет отличное исследование проведенное на Tutorial9, выдержку из результатов которого я хочу вам привести.

Как проводилось данное исследование? Для оценки производительности того или иного плагина использовался Apache Benchmark. Данный тест генерирует большое количество запросов, на основании чего формируется отчет о количестве обработанных сервером запросов в секунду и среднем времени передачи данных. Исходные данные: WordPress 2.9.1 на котором установлено несколько популярных плагинов — Akismet, All in SEO Pack и Google XML Sitemap. Количество трафика на тестовом блоге не велико, представлен смешанный контент — текстовый, изображения, электронные таблицы, java-скрипты. Для объективности каждое измерение повторялось несколько раз в сутки.

Я не буду приводить результаты тестирования всех плагинов, которые тестировались авторами Tutorial9, потому что смысл заострять внимание есть только на самых распространенных, ходовых и популярных плагинах. Итак, приступим:

Блог с выключенным кэшированием
Блог без активированных плагинов, показал следующие результаты:


Wordpress кэширование

Запросов в секунду — 13,96;
Время на каждый запрос — 716,58 мс;
Скорость передачи данных — 673,98 Кбит/сек

Как видите исходные данные не впечатляют. Давайте посмотрим что и как можно улучшить.

Если вы привлекаете аудиторию из соц.сетей, которые могут генерировать очень большой объем трафика, без кэширования не справиться. Кстати, есть такой недорогой сервис https://avi1.ru/ для развития и продвижения аккаунтов, групп, сообществ и встреч в самых узнаваемых и проходимых социальных сетях. С его помощью можно накрутить большое количество лайков, просмотров, подписчиков и комментариев.

Плагин WP-Cache

Популярный плагин WP-Cache продемонстрировал следующий результат:

Wordpress кэширование

Запросов в секунду — 109,59;
Время на каждый запрос — 91,25 мс;
Скорость передачи данных — 5307,00 Кбит/сек

Заметно лучше чем без кэширования. Результат превосходит блог без активированных плагинов в среднем на 685%. Замечу что WP-Cache — давно известный плагин, который исторически пользуется популярностью.

Плагин WP Super Cache


WP Super Cache в настоящее время пожалуй более популярен чем WP-Cache. Это легко объяснимо — WP Super Cache является доработанной версией WP-Cache. Помимо того что он быстрее, он и «умнее», то есть умеет больше чем предшественник. В частности его легче устанавливать и удалять, он умеет чистить за собой «мусор» после деактивации и так далее.

Что же касается скорости, результат получился следующий:

Wordpress кэширование

Запросов в секунду — 118,23;
Время на каждый запрос — 84,58 мс;
Скорость передачи данных — 5743,07 Кбит/сек

Результаты тестирования превосходят результаты WP-Cache. WP Super Cache в среднем быстрее блога без активированного кэширования в среднем на 747%. Отмечу еще одну особенность — если в WP Super Cache включена компрессия, он может быть даже медленнее блога без плагинов!

Плагин Hyper Cache

Hyper Cache — достаточно новый плагин, который еще не успел завоевать большой популярности. Тем не менее, показал в ходе тестирования отличный результат. Кроме того плагин отличается достаточно простой установкой и настройкой.

Результаты:


Wordpress кэширование

Запросов в секунду — 130,75;
Время на каждый запрос — 76,48 мс;
Скорость передачи данных — 6325,36 Кбит/сек

В среднем это лучше на 837% чем блог без плагинов.

Итоги работы плагинов кэширования для wordpress

Я не стал приводить в этой статье всех плагинов, потому что оптимальным выбором является один из рассмотренных выше. Если у вас есть время, желание и знания английского вы с легкостью можете изучить полные результаты исследвания сравнения плагинов wordpress для кэширования.

Лучший результат показал Hyper Cache, к тому же он обеспечивает хороший контроль над процессом. Вполне можно использовать WP-Cache или WP Super Cache. И тот и другой заметно повышают производительность. Кроме того они из когорты «старых добрых», проверенных поколениями, а значит неплохо поддерживаются. Надеюсь, эта статья помогла вам определиться с выбором плагина для кэширования. Дело за установкой! Что касается меня, то для одного из блогов блогов я использую плагин кэширования WP Super Cache, вроде помогает:)

А какой плагин для кэширования wordpress используете вы и почему?

wordpressinside.ru

Небольшая ремарка о кэшировании


Wordpress кэширование
Google недавно объявил, что все mobile-friendly сайты (а скорость — это путь к тому, чтобы быть «friendly») получают существенное преимущество в поисковой выдаче, начиная с 21 апреля. Возможно, вы уже видели тег «mobile friendly» в поисковой выдаче. И в Google Page Insights первая же панель адаптирована под мобильные устройства, а не под десктопы. Намерения Google ясны, и звучат громко для любого SEO-специалиста или вебмастера. Сейчас важно работать над производительностью как десктопной, так и мобильной версии сайта, что мы и попробовали отобразить в бенчмаркинге.

Есть несколько способов улучшить производительность сайта и сократить время загрузки, но для большинства вебмастеров использование кэширующего плагина — не только один из самых простых, но и единственный способ, позволяющий достичь максимального результата.

WordPress (и большинство сайтов на CMS) динамически формируют страницы на лету, что требует многократных обращений к базе данных для получения различных частей контента. Кэширование этих динамически формируемых страниц позволяет пользователю видеть обычные HTML-страницы. Это значительно снижает время загрузки и разгружает сервер.

Подробности теста


Wordpress кэшированиеИзначальная идея базировалась на использовании как простейшей темы типа 2014, так и более сложной темы, что позволит смоделировать более «реальный» сайт. Но во время проведения тестов выяснилось, что влияние плагинов на скорость загрузки сайта с темой «2014» было минимальным, и писать почти не о чем. Но есть много приёмов, позволяющих улучшить производительность «2014», так что здесь более важна настройка сервера, а не кэширование.

Для того, чтобы сделать тестируемый пустой сайт максимально приближенным к реальности, использовалась тема Novelty от Tesla Themes. Тестируемую страницу сайта оформили с использованием графики и текста, был добавлен сайдбар и некоторые плагины (вывод новостей, фид из Twitter/Instagram). Теперь у нас страница, загрузка которой занимает относительно много времени. Да, в качестве хостинга использовался вот этот WordPress хостинг.

Плагины, которые тестировались:

  • AIO Cache
  • Alpha Cache
  • Bodi0’s Easy Cache
  • Cachify
  • Flexicache
  • Gator Cache
  • Hyper Cache
  • Hyper Cache Extended
  • Lite Cache
  • Next Level Cache
  • Really Static
  • Super Static Cache
  • W3 Total Cache
  • Wordfence Falcon
  • WP Fast Cache
  • WP Fastest Cache
  • WP Rocket
  • WP Super Cache
  • WP-Cache.Com
  • Zen Cache (formerly Quick Cache)

Остались ещё:

Brutal Cache — просто не работал;Batcache — плагин с зависимостью от Memcache, что не использовалось в текущем тесте.Autoptimize и Widget Cache также остались за бортом, поскольку они являются поддержкой для других плагинов, это не совсем самостоятельные плагины.

Хостинг и инструменты бенчмаркинга

Wordpress кэширование
Во время проведения тестов мы работали с аккаунтом на шаред-хостинге, схожим с большинством других вариантов. Таким образом, мы получаем скорость загрузки, достижимую для «бюджетных» пользователей. У тестируемого сайта не было посещаемости, на него не заходили поисковые боты во время тестирования. Сервер работал с Ngnix в качестве прокси, а не с чистым Apache.

В качестве инструментов использовались сервисы, предлагаемые Google, GTMetrix и Yahoo. Благодаря этому стало возможным тестировать не только скорость загрузки страниц, но и другие факторы, среди которых:

  • оптимизация изображений;
  • временная задержка сервера;
  • минификация и оптимизация js- и css-кода;
  • использование кэширования в браузере;
  • размещение скриптов;
  • использование CDN, распараллеливания/доменного шардинга;
  • использование Gzip-сжатия;
  • количество HTTP-запросов.

Google PageSpeed Insights

Сервис PageSpeed Insight проверяет сайт как с точки зрения десктопного ПК, так и со стороны мобильного устройства, выдавая оценку по 100-балльной шкале. Page Speed Insights прост в использовании, но предоставляет относительно сырой результат, который не даёт полного понимания того, что может быть улучшено. Даже несмотря на то, что инструмент даёт представление о некоторых вещах, которые Google может находить важными, информация, предоставляемая GTMetrix и Yahoo, намного полнее.

При этом Google во время оценки не принимает во внимание CDN, поэтому в некоторых случаях оценка занижена.

GTMetrix и YSlow

GTMetrix и YSlow основаны на руководстве по повышению производительности ресурса от Yahoo, оценка также выводится по 100-балльной шкале. Эти инструменты гораздо более изощрены в плане проведения измерений. PageSpeed Insight даёт всего несколько подсказок о том, что может быть улучшено, в то время как GTMetrix YSlow работают с не менее чем 50 различными метриками. GTMetrix также предлагает диаграмму-водопад, препарируя процесс загрузки, а также весьма продвинутую историю загрузки. Если вы хотите понять, как повысить производительность вашего ресурса, это один из лучших инструментов.

Тайминг


В бенчмаркинге использовались следующие инструменты для определения скорости загрузки страниц и тестирования работы сервера под нагрузкой.

ApacheBench

ApacheBench — отличный инструмент, который помогает определить, сколько запросов в секунду способен выдержать сайт с использованием различных плагинов. Выполнение теста проводилось с отправкой 1000 запросов по 10 различным потокам. Тест выполнялся 10 раз с фиксированием лучшего результата по каждому из плагинов.

Стоит отметить, что использование Nginx несколько снижает различие между работой сайта с плагинами/без плагинов. По этому поводу можно спорить, но в случае использования Nginx зафиксирована двукратная разница по сравнению с Apache.

Pingdom

Pingdom — хорошо известный сервис для мониторинга и тестирования. С каждым плагином проводилось 20 тестов, с фиксацией лучшего результата. Отметим, что сервер был расположен в Швеции (Стокгольм), а сервер Pingdom — в Нидерландах (Амстердам).

Webwait

Webwait — простой, но очень полезный инструмент. Основная задача сервиса — показать, за какое время полностью загрузится страница именно в вашем браузере. Таким образом, это не серверный инструмент, сервис запускается локально. Webwait загружает страницу снова и снова, а затем показывает средний результат. В нашем случае был выбран способ загрузки через Ethernet, браузер Opera. Каждая страница загружалась 101 раз с получением среднего и медианного времени загрузки.

Итак, с описанием всё, теперь приступим непосредственно к тестам.

Google, GTMetrix и Yslow


Страницы сайта тестировались с использованием указанных сервисов, вот результат:

Как видим, некоторые плагины здесь просто никак не проявились — оценка такая же или очень близка к оценке, когда кэширование вообще не используется. Google дал лучшую оценку Supercache как для десктопа, так и для мобильного устройства. В GTmetrix и Yslow мы видим, что Fastest Cache Rocket впереди планеты всей. Мы склонны оценивать последние значения как более важные, поскольку Google Page Insight для оценки использует меньше факторов.

Итак, лучшими плагинами оказались WP Fastest Cache, WP Super Cache и WP Rocket Cache. Победитель — WP Super Cache с работой через мобильный девайс. Кэширование для мобильных было также включено, о нём не забыли.

Тайминг

Как уже говорилось выше, оценочные баллы являются в большей мере показателем качества кода сайта. Они дают понимание того, что можно сделать для ускорения сайта, хотя более высокая оценка у сайта вовсе не значит, что он загружается быстрее, чем другие ресурсы. И в этом ошибка — оценочные инструменты дают идеи по улучшению сайта для снижения времени загрузки, но время загрузки не принимается во внимание в достаточной степени. Вы поймете это, взглянув на скриншот из Pingdom.

Как видите, тестируемая страница получила 96 из 100 баллов, что, вероятно, лучше, чем у 99% страниц любых сайтов. Тем не менее эта страница загружается почти 35 секунд. Корректен ли результат? Сделайте вывод сами 🙂

Тайминг — важный тест, поскольку здесь проводится реальное измерение скорости загрузки страниц сайтов.

ApacheBench

Итак, тестируем наш сервер на его способность поддерживать выполнение большого количества запросов. Чем больше показатель числа запросов за секунду, тем лучше.

Без кэширования сервер показывает результат в 18 запросов за секунду. Это довольно неплохой результат, который стал возможным благодаря использованию Nginx. На каждый запрос уходит примерно 1/500 с.

Здесь мы видим, что Hyper Cache Ext, WP Fastest Cache, WP-Cache.com и WP Rocket улучшают результат на 300% по сравнению с работой без кэширования. WP Rocket — самый быстрый и WP-Cache.com занимает второе место.

Здесь очевидно проявляется преимущество использование плагинов кэширования — вы можете держать в три раза больше запросов. Используя Nginx, хороший плагин кэширования, и, может быть, что-то вроде Varnish, вы получаете сервер, который летает.

Pingdom

Без кэширования результат — около 2,8 секунды. Использование практически любого плагина улучшает результат по крайней мере вдвое.

Webwait

Здесь показан как средний, так и медианный результат при тестировании в Webwait. Время загрузки чуть меньше, поскольку был выбран шведский сервер Webwait (помните, это браузерный, а не серверный инструмент).

Медианное время загрузки

Как видим, практически неизвестный WP-Cache.com работает весьма неплохо.

Не кэшированием единым

Конечно же, далеко не всё зависит от кэширования. Важную роль играют и такие факторы, как выбор Apache, Nginx и т. п., корректность настройки, тип сервера (выделенный, VPS, шаред), количество изображений и их оптимизация, HTTP-запросы. Собственно, об этих факторах на «Хабре» знают практически все, поэтому останавливаться на них мы не будем.

Вывод

У всех плагинов, которые здесь представлены, разная функциональность. Некоторые очень просты, в то время как другие можно сравнить со швейцарским ножом. Super Cache, W3 и прочие плагины зачастую используют профи, которые знакомы с CDN и прочими премудростями. Другие пользователи предпочитают работать с более простыми плагинами вроде Lite Cache и WP-Cache.com. Кстати, WP-Cache.com, как говорилось выше, малоизвестный плагин, который показал отличные результаты.

habr.com

Зачем использовать кэш браузера?

Кэширование важно для оптимизации веб-сайта, созданного на WordPress, поскольку оно увеличивает скорость загрузки страниц. Посетителям сайта не понравится его долгая загрузка, в результате чего они могут просто покинуть ваш сайт, не дождавшись информации, тем самым увеличивая количество отказов. Такие поведенческие параметры плохо отражаются на ранжировании сайта поисковыми системами, которые понижают его позиции в поисковой выдаче. Чтобы этого не произошло, подключите плагин WordPress Super Cache, который автоматически выполнит работу по кэшированию страниц.

wp super cache

Описание и возможности плагина

Кэш представляет собой временное хранилище для содержимого веб-страницы. Вместо того чтобы загружать данные страниц (например, изображения) с сервера при повторном посещении сайта, они будут подгружаться в браузер из кэша, что существенно ускорит загрузку сайта. Эффективным инструментом для кэширования под WordPress является специальный плагин WordPress Super Cache.

Плагин генерирует статические страницы сайта и сохраняет их кэшированные версии на сервере. После этого сервер вашего хостинг-провайдера будет «отдавать» посетителям статические файлы вместо того, чтобы каждый раз обращаться к базе данных для получения элементов страниц.

Что еще умеет делать WordPress Super Cache плагин:

  • Позволяет вместе с кэшированием использовать сеть доставки контента (CDN), перераспределяя наиболее часто запрашиваемые материалы с сервера, ближайшего к посетителю.
  • Поддерживает кэширование версий страниц для планшетов и смартфонов.
  • Использует сжатие страниц, чтобы уменьшить время загрузки сайта.
  • Поддерживает несколько типов кэширования.
  • Предоставляет возможность восстановления кэша, при этом вы можете просматривать кэшированные страницы, даже когда создается новый кэш.

Установка плагина WP Super Cache

Плагин можно найти в репозитории WordPress. Для этого войдите в админ-панель под своим логином и паролем.

  • Выберите меню «Плагины» (1) и нажмите «Добавить новый» (2).
  • В строке поиска напечатайте название плагина WP Super Cache (3).
  • Найдите в появившемся списке нужный вариант и нажмите кнопку «Установить» (4).
  • После установки активируйте плагин, нажав соответствующую кнопку.

поиск плагина

Даже после активации плагин WP Super Cache по умолчанию отключен, поэтому вверху экрана вы увидите соответствующее предупреждение.

На странице с настройками вы можете увидеть еще одно уведомление об изменении файла wp-config.php, после обновления страницы оно исчезнет.

предупреждение

Чтобы заставить плагин работать:

  1. Выберите опцию «Кэширование включено»
  2. Нажмите кнопку «Обновить».
  3. Затем выполните проверку правильности подключения плагина, используя кнопку «Проверить».

базовые настройки

Если плагин подключен верно, вы увидите оповещение, выделенное зеленым цветом. Плагин дважды обращается к сайту и сравнивает временные метки обеих копий. Если они совпадают, значит для сайта активировано кэширование.

базовые настройки

Настройки плагина WordPress Super Cache — как включить и настроить кеширование

WP Super Cache представляет собой мощный плагин с большим количеством опций, многие из которых дополнительно могут улучшить производительность сайта. В панели расширенных настроек плагина предоставляется возможность гибкого управления параметрами кэширования веб-страниц.

Убедитесь, что кэширование включено, и выберите один из трех режимов обслуживания кэша:

  1. mod_rewrite – это самый быстрый вариант, который позволяет WordPress обслуживать статические страницы из кэша без обращения к PHP интерпретатору на сервере;
  2. режим PHP используется по умолчанию и потребляет больше ресурсов, что может оказаться невыгодным в случае большой загруженности сервера;
  3. упрощенное кэширование менее производительное, чем предыдущие варианты, но и ресурсов затребует минимум.

настройки

Следующие параметры требуют настройки в разделе «Разное».

  1. Опция «Сжимать файлы кэша» может конфликтовать с другими алгоритмами сжатия. Если к сайту подключены еще плагины, обеспечивающие сжатие, не устанавливайте этот флажок.
  2. Кэширование страниц не требуется для авторизованных пользователей или тех, кто оставляет комментарии на сайте. Включите эту опцию, чтобы разрешить таким посетителям просмотр страницы в ее текущем виде.
  3. Автоматическая перестройка кэша не нужна, если на сайте имеется часто обновляемая информация. В противном случае посетители увидят устаревшие страницы.
  4. Ошибка 304 возникает, когда сервер сообщает браузеру, что со времени последнего визита содержимое страницы не изменилось. В этом случае загрузка происходит из кэша браузера, что дополнительно ускоряет работу сайта.
  5. На странице с параметром GET присутствует поиск по определенным критериям (даты, цена), специфичным при каждом посещении. Такие страницы кэшировать не нужно.
  6. Если зарегистрированные пользователи считаются анонимными, кэшированые страницы будут выдаваться всем без исключения.
  7. Последняя опция в этом разделе – это реклама плагина со встроенной в футере ссылкой на автора.

разные настройки

В разделе «Расширенные» приведены настройки для продвинутых пользователей. Как правило, для обычных сайтов можно оставить их выключенными.

  1. Если на сайте присутствуют динамические элементы, при кэшировании некоторые из них могут работать неправильно. В этом случае потребуется режим упрощенного или PHP-кэширования и включенная опция динамического кэширования.
  2. Для сайтов, разработанных специально для мобильных устройств, потребуется включить поддержку, если шаблон не является адаптивным.
  3. Опция «Убрать поддержку UTF-8» не требуется, если все символы на сайте отображаются нормально.
  4. Очистку файлов кэша при новых публикациях можно включить, если сайт часто обновляется.
  5. Дополнительная сверка понадобится, если возникают проблемы с кэшированием какой-либо страницы.
  6. Если посетитель оставил комментарий на странице, после его модерации кэш обновится.
  7. Посмотреть кэшированные страницы можно на владке «Состояние кэша», поэтому опция необязательна.
  8. Опция замедляет работу файлов, предупреждая возможную проблему на сервере при кэшировании страниц.
  9. Опция для разработчиков загружает кэш только после загрузки WordPress.

Ниже опций приводится адрес расположения кэша и персональный ключ на случай, если требуется посмотреть страницу, не кэшируя и без предварительной очистки кэша.

разные настройки

Если вы выбрали способ кэширования страниц методом mod-rewrite, плагин запросит обновление прав на запись. Для этого прокрутите страницу вниз до кнопки «Обновить правила Mod-Rewrite» и нажмите ее.

обновить настройки

Затем установите время и период, в течение которого кэшированные данные на сервере будут действительны. Начните со значения 3600 секунд (1 час). Если на вашем сайте большое количество статей, возможно, понадобится задать большее время вплоть до нескольких суток, после чего кэш будет считаться устаревшим. Там же можно запланировать очистку кэша по расписанию, настраивая таймер и интервал обновления. Для неменяющихся сайтов сборку мусора можно отменить совсем, устанавливая значение таймаута, равное нулю.

мусор

Вы можете запретить кэширование определенной информации на сайте (например, раздел с постоянно обновляющейся информацией), установив флажок в нужном разделе «Допустимые имена и Запрещенные адреса» или вручную дописать адреса страниц.

имена

Очистите список поисковых ботов, если хотите, чтобы они получали информацию из кэша и не нагружали сервер при сканировании сайта. Для высоконагруженных сайтов с посещаемостью более тысячи уникальных визитов в сутки рекомендуется включить закрытый режим. В этом случае обновление кэша будет отменено.

боты

На вкладке «Настройка CDN» подключается платный сервис для эффективного распределения информации при выдаче из кэша. Вкладка «Состояние кэша» покажет, какие страницы кэшируются, их можно вручную удалять из списка.

Перейдите на вкладку «Общий кэш», чтобы настроить параметры режима предварительной загрузки. Для чего может понадобиться использовать полностью статический контент?

  • Для экономии ресурсов сервера.
  • Чтобы повысить скорость загрузки сайта.
  • Чтобы обслуживать старый сайт, контент которого больше не обновляется.

При выборе функции «Создать общий кэш сейчас» дайте время плагину сформировать кэш в автоматическом режиме. За процессом можно наблюдать, переключившись на вкладку «Состояние кэша».

настройки кеша

Вкладка «Плагины» понадобится, только если вы собираетесь подключить другие плагины, не влияющие на кэширование файлов.

Использование кеша браузера, как почистить кеш ВордПресс

Через некоторое время работы плагина WP Super Cache вы заметите формирование кэша для сайта. Правильная настройка плагина значительно улучшит время загрузки сайта. Кэшированные страницы хранятся в виде HTML или PHP файлов на сервере вашего хостинга. Обычно сервер знает, какие страницы были обновлены, и выдает пользователю свежую версию. Однако, если возникают проблемы с отображением обновленной информации, можно вручную очистить кэш. Удалите кэшированные страницы с сервера, используя команду на панели управления «Удалить весь кэш» или нажав на такую же кнопку в настройках плагина.

как удалить кеш

Когда пользователь в первый раз заходит на сайт, его браузер обращается к удаленному серверу, на котором этот сайт размещен. Запрос браузера и ответ сервера занимают время, учитывая, что подзагрузка элементов сайта (картинок, стилей, скриптов) происходит последовательно один за другим. Если страница содержит большое число элементов или они велики по размеру, их загрузка может оказаться продолжительной.

Если вы не видите изменений на сайте, который должен обновляться, очистите кэш, используя панель управления настройками браузера, или просмотрите страницу в приватном режиме просмотра (при этом режиме не используются сохраненные элементы, напр. пароли, и кеш).

www.ipipe.ru

Кэш браузера

Обращали ли вы внимание, что когда вы впервые заходите на новую сайт, загрузка страницы занимает определенное количество времени, но уже при переходе к другой странице того же сайта все происходит намного быстрее? Первая загрузка происходила полностью с сервера, а при последующих переходах браузер подгружает только изменившуюся информацию, все остальное он взял из кэша.

Обычно, для того, чтобы увидеть внесенные нами правки, достаточно нажать насколько раз клавишу F5 или кнопку «Обновить» на панели обозревателя. Но иногда это не помогает, и тогда ничего не остается, кроме как полностью очистить хранилище кэша. Дополнительно к очистке кеша так же можно отключить или ограничить кеширование. Это конечно повлияет на комфорт просмотра, но здесь приходится выбирать.

У разных браузеров очистка хранилища и отключение делается по разному, поэтому как это сделать я в этой статье описывать не буду, это вам лучше спросить у Googl-а.

Кэширование на стороне хостинга

Статические страницы (те на которых весь контент заполнен сразу) подгружаются быстрее динамических (тех у которых контент подгружаются из базы данных). Это происходит из-за того, что статические не требуют дополнительной обработки, а динамические необходимо предварительно подготовить, сделать запросы к базе данных и т. д.

Смысл кэширования сервером заключается в том, что все действия по генерированию страницы записываются в файл, который сохраняется и при повторном обращении того же пользователя, либо нового, выдается уже не динамическая, а статическая копия страницы.

Как правило, настройки кэширования доступны из панели управления хостингом, где вы можете его очистить, либо отключить. Если у вас возникнут какие-то проблемы с настройкой, то вам лучше обратиться к тех. поддержке.

Плагины кэширования для WordPress

Для WP есть большое количество дополнений позволяющих использовать кеширование для повышения скорости сайта. Намного проще сделать загрузку из кэша, чем генерировать ее каждый раз заново. Однако, это тоже может быть причиной не правильного отображения, или не отображения вовсе, внесенных нами изменений.

Одним из самых популярных дополнений является WP Super Cache. Этот плагин генерирует статические HTML-файлы с вашего динамического WP-блога. После того, как HTML-файл создан, ваш веб-сервер будет подгружать этот файл вместо обработки более ресурсоемких скриптов PHP.
Давайте на его примере рассмотрим, как в WordPress очистить кэш.

Итак, для этого нам нужно:

  1. 1.В административной панели WP выбрать пункт «Натройки» => WP Super Cache.
  2. 2.Выбрать вкладку «Состояние кэша». На этой вкладке мы можем увидеть всю информацию о нём.
  3. 3.Для начала,попробуем нажать кнопку «Удалить просроченный кэш», если это не помогло, жмем «Удалить весь кэш».

После того как вы сделали очистку вы должны увидеть все последние правки, которые вы проделали со своим сайтом.

Кэширование, хоть и может вызвать некоторые неудобства при разработке, но всё же я не призываю полностью отказываться от него, особенно если у вас сайт с большой посещаемостью. Поэтому, гораздо полезнее будет не полностью отключать кеширование страниц, а научиться управлять им.

Надеюсь данная информация поможет вам решить проблему с кешированием. Желаю вам успешного устранения проблем с кешированием, какими бы они не были! Пишите комментарии, задавайте вопросы и подписывайтесь на мою рассылку.

До встречи в моих следующих статьях.

С уважением Юлия Гусарь

impuls-web.ru

Кеширование в WordPress без использования плагинов
Сегодня я хочу рассказать Вам об одном очень не плохом способе кеширования в WordPress без использования плагинов. При его использовании страница загружается за доли секунд (0.000216 сек — среднее время загрузке на локальном компьютере моего блога), что во много раз быстрее чем при использовании любых плагинов кеширования (для примера среднее время загрузки моего блога на локальном компьютере при использовании WP Super Cache — 0.388 сек). Кроме этого в разы падает нагрузка на процессор и память.

К сожалению у данного способа есть один минус — он полностью исключает работу любых динамических функций (счетчики, голосование), а также возможность оставлять комментарии ? Этот способ идеально подойдет для сателлитов и корпоративных сайтов, а также любых других сайтов где отключены комментарии и не используются счетчики и голосование.

Итак, что же нужно сделать:
1. Создаем папку в корне сайта, называем её cache и ставим на неё права — 777
2. В файле index.php в корне сайта заменяем то, что там есть на этот код:

<?php  $start = microtime();  $filename = 'cache/'.md5($_SERVER['REQUEST_URI']).'.html';  $cached = false;  $time = 4 * 60 * 60; // Время кеша в секундах (4*60*60 = 4 часа)  $stat = 0; // Установите 1 для вывода времени загрузки страницы (по умолчанию 0)    if (file_exists($filename)) {  if ((time()-filemtime($filename))<$time) {  $cached = true;  } else {  unlink($filename);  $cached = false;  }  }    if ($cached) {  readfile($filename);  } else {  ob_start();    // WP  define('WP_USE_THEMES', true);  require('./wp-blog-header.php');  //    $text = ob_get_clean();    $fh = fopen($filename, 'w+');  fwrite($fh, $text);  fclose($fh);    echo $text;  }  $finish = microtime();    if ($stat==1) echo $finish-$start;  ?>

Вот собственно и все. С помощью 4 строки Вы можете самостоятельно изменять время жизни кеша, для вывода времени загрузки страницы в 5 строке установите 1. Если будут какие либо вопросы, спрашивайте в комментариях ?

www.wp-info.ru

Журнал изменений

1.6.4

  • Changes between 1.6.3 and 1.6.4
  • Fixes for WP-CLI (#587) (#592)
  • Bumped the minimum WordPress version to 3.1 to use functions introduced then. (#591)
  • Fixes to wpsc_post_transition to avoid a fatal error using get_sample_permalink. (#595)
  • Fixed the admin bar «Delete Cache» link. (#589)
  • Fixed the headings used in the settings page. (#597)

1.6.3

  • Changes between 1.6.2 and 1.6.3
  • Added cookie helper functions (#580)
  • Added plugin helper functions (#574)
  • Added actions to modify cookie and plugin lists. (#582)
  • Really disable garbage collection when timeout = 0 (#571)
  • Added warnings about DISABLE_WP_CRON (#575)
  • Don’t clean expired cache files after preload if garbage collection is disabled (#572)
  • On preload, if deleting a post don’t delete the sub directories if it’s the homepage. (#573)
  • Fix generation of semaphores when using WP CLI (#576)
  • Fix deleting from the admin bar (#578)
  • Avoid a strpos() warning. (#579)
  • Improve deleting of cache in edit/delete/publish actions (#577)
  • Fixes to headers code (#496)

1.6.2

  • Fixed serving expired supercache files (#562)
  • Write directly to the config file to avoid permission problems with wp-content. (#563)
  • Correctly set the .htaccess rules on the main site of a multisite. (#557)
  • Check if set_transient() exists before using it. (#565)
  • Removed searchengine.php example plugin as it sets a cookie to track users. Still available here. (#567)
  • For advanced users only. Change the vary and cache control headers. See https://github.com/Automattic/wp-super-cache/pull/555 (#555)

1.6.1

  • Fix the name of the WP Crontrol plugin. (#549)
  • Handle errors during deactivation/uninstall by email rather than exiting. (#551)
  • Add a notice when settings can’t be updated. (#552 and #553)

1.6.0

  • Fix issues in multisite plugin (#501)
  • Fixes wp-cli plugin deactivate/activate (#499)
  • Cleanup — change quotes. (#495)
  • $htaccess_path defines the path to the global .htacess file. (#507)
  • Fix ‘cannot redeclare gzip_accepted()’ (#511)
  • Correct the renaming of tmp_wpcache_filename (removed unnecessary slash in path) which caused renaming to fail. (#516)
  • Add check for Jetpack mobile theme cookie (#515)
  • Optimize wp_cache_phase2 and create wpsc_register_post_hooks (#508)
  • WPCACHEHOME has a trailing slash (#513)
  • Cleanup cache enable/disable and update_mod_rewrite_rules (#500)
  • Post Update now clears category cache (#519)
  • Various fixes for saving the debug page form (#542)
  • Expert-caching and empty parameters, like ?amp, should not serve cached page (#533)
  • Tiny Yslow description fix (#527)
  • Add ipad to mobile list (#525)
  • Hide opcache_invalidate() warnings since it’s disabled some places. (#543)
  • Check that HTTP_REFERER exists before checking it. (#544)
  • Replace Cron View» with WP Crontrol because it’s still updated. (#546)
  • adding hook (wp_cache_cleared) for full cache purges (#537)

1.5.9

  • Fixed fatal error if the debug log was deleted while debugging was enabled and a visitor came to the site.
  • Fixed the dynamic caching test plugin because of PHP7 changes. Dynamic cache mode must be enabled now.
  • Lots of WordPress coding style formatting fixes to the code.
  • Все изменения: https://github.com/Automattic/wp-super-cache/compare/1.5.8…1.5.9

1.5.8

  • PHP 7 fixes. (#429)
  • Fix debug comments checkbox. (#433)
  • Only register uninstall function in admin pages to save queries. (#430)
  • Check that wp-cache-phase1.php is loaded before saving settings page. (#428)
  • If a url has a «?» in it then don’t delete the associated cache. It’ll delete the whole cache after stripping out ?… part. (#427 & #420)
  • Allow static functions in classes to be used in cacheactions. (#425)
  • Don’t make AJAX requests anonymous. (#423)
  • Исправлена связь с описанием chmod. (#421)
  • Add more escaping to the CDN settings page. (#416)
  • Use SERVER_PROTOCOL to determine http protocol. (#412 & #413)
  • Если preload stalls отправляет только один адрес электронной почты в день, но отображает уведомление администратору. (# 432)
  • Исправлено больше PHP-предупреждений в #438 и #437
  • Скрыть предупреждения mod_rewrite для пользователей Nginx. #434

1.5.7.1

  • If the HTTP HOST is empty then don’t use it in strpos to avoid a PHP warning. (#408)
  • Don’t preload posts with permalinks that contain rejected strings. (#407)
  • Generate a list of archive feeds that can be deleted when the site is updated. Also fixes corrupted config file issue and fatal error with older versions of WordPress. (#403)

1.5.7

  • Fix fatal error in plugins/searchengine.php (#398)

1.5.6

  • REST API: Added /plugins endpoint to handle the plugins settings page. (#382)
  • Minor changes to indentaion and spaces to tabs conversion (#371) (#395)
  • Don’t set $wp_super_cache_comments here as it’s not saved. (#379)
  • realpath() only works on directories. The cache_file wasn’t set correctly. (#377)
  • Fix problem deleting cache from admin bar because of realpath() (#381)
  • Use trigger_error() instead of echoing to the screen if a config file isn’t writeable. (#394)
  • Added the «wpsc_enable_wp_config_edit» filter to disable editing the wp-config.php (#392)
  • Fix some PHP notices when comments are edited/published/maintained. (#386)
  • Minor changes to description on plugins page. (#393)

1.5.5

  • Catch fatal errors so they’re not cached, improve code that catches unknown page types. (#367)
  • Fix caching on older WP installs, and if the plugin is inactive on a blog, but still caching, give feeds a short TTL to ensure they’re fresh. (#366)
  • When preloading don’t delete sub-directories, or child pages, when caching pages. (#363)
  • Avoid PHP warnings from the REST API for settings that are not yet defined. (#361)
  • Added missing settings to the config file. (#360)

1.5.4

  • Fix messages related to creating advanced-cache.php (#355, #354)
  • Deleting the plugin doesn’t need to delete the cache directory as it’s already done on deactivation. (#323)
  • Disable Jetpack mobile detection if Jetpack Beta is detected. (#298)
  • Add more checks on directories to make sure they exist before deleting them. (#324)
  • Add siteurl setting to CDN page for users who have WordPress in it’s own directory. (#332)
  • Don’t enable and then not save debug comments when toggling logging. (#334)
  • Show plugin activity html comments to users who disable caching for logged in users. (#335)
  • Better notifications on Preload page, and redo sql to fetch posts. Added «wpsc_preload_post_types_args» filter on post visibility, and wpsc_preload_post_types filter on post types used. (#336)
  • Use a cached feed if it is newer than the last time a post was updated. (#337)
  • Better define a sitemap (#340) but when the content type is unknown add more checks to find out what it is. (#346)
  • Save cache location correctly on the advanced settings page. (#345)
  • Make sure the debug log exists before toggling it on/off to ensure the http auth code is added to it.
  • Return the correct cache type to the REST API. Ignore supercache enabled status. (#352)
  • Fix cache contents in REST API showing double count of supercache files. (#353)
  • Move the nonce in the CDN page back into a function. (#346)
  • Use realpath to compare directories when loading the sample config file to account for symlinked directories. (#342)
  • Other minor changes to html or typos
    (Numbers are pull requests on Github.)

1.5.3

  • Fix a critical bug that caused unlink to be run on null while deleting the plugin.

1.5.2

  • Add a trailing slash to home path. Fixes problems with finding the .htaccess file.
  • Delete WPCACHEHOME and WP_CACHE from wp-config.php when plugin deactivated.
  • Check that WPCACHEHOME is the right path on each load of the settings page.
  • Load the REST API code without using WPCACHEHOME.
  • Fixed mobile browser caching when using WP-Cache caching.
  • Fixed directory checks on Windows machines.
  • Reverted CDN changes in 1.5.0 as they caused problems in older «WordPress in a separate directory» installs.
  • Added note to CDN page when site url != home url. Site owners can use a filter to adjust the URL used.
  • Stop preload quicker when requested while preloading taxonomies.
  • Added more information for when updating the .htaccess file fails.
  • «Served by» header is now optional. Enable it by setting $wpsc_served_header to true in the config file.

1.5.1

  • Don’t use anonymous functions in REST API
  • Check that REST API Controller is available before loading the REST API.
  • Don’t use multibyte string functions because some sites don’t have it enabled.

1.5.0

  • REST API settings endpoints.
  • Simplified settings page.
  • WP-Cache files reorganised.
  • Caching of more http headers.
  • Lots of bug fixes.

1.4.9

  • Fixed bug when not running sem_remove after sem_release. See https://github.com/Automattic/wp-super-cache/issues/85
  • Fixed a PHP error impacting PHP 7.1.
  • Fixed a bug where we cached PUT and DELETE requests. We’re treating them like POST requests now.
  • Delete supercache cache files, even when supercache is disabled, because mod_rewrite rules might still be active.
  • Updated the settings page, moving things around. #173
  • Make file locking less attractive on the settings page and fixed the WPSC_DISABLE_LOCKING constant so it really disables file locking even if the user has enabled it already.
  • Added a WPSC_REMOVE_SEMAPHORE constant that must be defined if sem_remove() is to be used as it may cause problems. #174
  • Added a «wpsc_delete_related_pages_on_edit» filter that on returning 0 will disable deletion of pages outside of page being edited. #175
  • Fixed plugin deleting all cached pages when a site had a static homepage. #175
  • Make sure $cache_path has a trailing slash #177
  • Remove flush() #127 but also check if headers are empty and flush and get headers again. #179
  • Add fix for customizer #161 and don’t cache PUT AND DELETE requests #178
  • Check for superglobals before using them. #131

1.4.8

  • Removed malware URL in a code comment. (harmless to operation of plugin but gets flagged by A/V software)
  • Updated translation file.

1.4.7

  • Update the settings page for WordPress 4.4. layout changes.

1.4.6

  • Generate the file cache/.htaccess even when one exists so gzip rules are created and gzipped pages are served correctly. Props Tigertech. https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update?replies=36#post-7494087

1.4.5

  • Enhancement: Only preload public post types. Props webaware.
  • Added an uninstall function that deletes the config file. Deactivate function doesn’t delete it any more.
  • Possible to deactivate the plugin without visiting the settings page now.
  • Fixed the cache rebuild system. Rebuild files now survive longer than the request that generate them.
  • Minor optimisations: prune_super_cache() exits immediately if the file doesn’t exist. The output of wp_cache_get_cookies_values() is now cached.
  • Added PHP pid to the debug log to aid debugging.
  • Various small bug fixes.
  • Fixed reset of expiry time and GC settings when updating advanced settings.
  • Removed CacheMeta class to avoid APC errors. It’s not used any more.
  • Fixed reset of advanced settings when using «easy» settings page.
  • Fixed XSS in settings page.
  • Hide cache files when servers display directory indexes.
  • Prevent PHP object injection through use of serialize().

1.4.4

  • Fixed fatal error in output handler if GET parameters present in query. Props webaware.
  • Fixed debug log. It wasn’t logging the right message.

1.4.3

  • Security release fixing an XSS bug in the settings page. Props Marc Montpas from Sucuri.
  • Added wp_debug_log(). Props Jen Heilemann.
  • Minor fixes.

1.4.2

  • Fixed «acceptable file list».
  • Fixed «Don’t cache GET requests» feature.
  • Maybe fixed «304 not modified» problem for some users.
  • Fixed some PHP warnings.

1.4.1

  • Fixed XSS in settings page. Props Simon Waters, Surevine Limited.
  • Fix to object cache so entries may now be deleted when posts updated. (object cache still experimental)
  • Documentation updates and cleanup of settings page.

1.4

  • Replace legacy mfunc/mnclude/dynamic-cached-content functionality with a «wpsc_cachedata» cacheaction filter.
  • Added dynamic-cache-test.php plugin example wpsc_cachedata filter plugin.
  • Delete post, tag and category cache when a post changes from draft to publish or vice versa. Props @Biranit.
  • Update advanced-cache.php and wp-config.php if wp-cache-phase1.php doesn’t load, usually happening after migrating to a new hosting service.
  • Misc bugfixes.

1.3.2

  • Any mfunc/mclude/dynamic-cached-content tags in comments are now removed.
  • Dynamic cached content feature disabled by default and must be enabled on the Advanced Settings page.
  • Support for the mobile theme in Jetpack via helper plugin on script’s Plugins tab.

1.3.1

  • Minor updates to documentation
  • Fixed XSS in settings page.

1.3

  • mfunc tags could be executed in comments. Fixed.
  • More support for sites that use the LOGGED_IN_COOKIE constant and custom cookies.

1.2

  • Garbage collection of old cache files is significantly improved. I added a scheduled job that keeps an eye on things and restarts the job if necessary. Also, if you enable caching from the Easy page garbage collection will be enabled too.
  • Editors can delete single cached files from the admin bar now.
  • Fixed the cached page counter on the settings page.
  • Some sites that updated to 1.0 experienced too much garbage collection. There are still stragglers out there who haven’t upgraded but that’s fixed now!
  • Supercached mobile files are now used as there was a tiny little typo that needed fixing.
  • If your site is in a directory and you saw problems updating a page then that should be fixed now.
  • The deactivate hook has been changed so your configuration isn.t hosed when you upgrade. Unfortunately this will only happen after you do this upgrade.
  • Some sites use custom cookies with the LOGGED_IN_COOKIE constant. Added support for that.
  • Added support for WPTouch Pro, but it appears to be flaky still. Anyone have time to work on that? I don.t.
  • Some sites had problems with scheduled posts. For some reason the plugin thought the post was in draft mode and then because it only checked the same post once, when the post magically became published the cache wasn.t cleared. That.s fixed, thanks to the debug logging of several patient users.
  • And more bug fixes and translation updates.

1.1

  • Use $_SERVER[ ‘SERVER_NAME’ ] to create cache directories.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on «page on front» sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a «Cached» column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.
  • Removed debug level from logging as it wasn’t helpful.
  • Removed mention of wp-minify.

1.0

  • Removed AddDefaultCharset .htaccess rule
  • Fixed problem with blogs in a folder and don’t have a trailing slash
  • New scheduling of garbage collection
  • Added a «Delete cache» link to admin bar to delete cache of current page.
  • Updated documentation
  • Sorry Digg, Stephen Fry power now!
  • Updated translations
  • Preload taxonomies and all post types except revisionsand nav menu items
  • Fixed previews by logged in users.
  • Added option to make logged in users anonymous
  • Use WP 3.0 variables to detect multisite installs
  • Hash filenames so files are served from the same CDNs

0.9.9.9

  • Fixed typo, is_front_page.
  • Serve repeated static files from the same CDN hostname.
  • Updated translations.
  • Make supercache dir lowercase to avoid problems with unicode URLs.
  • Add option to skip https loaded static content.
  • Remove 5 second check on age of existing cache files. Should help with posts that get lots of comments and traffic.
  • Lots of bugs fixed.

0.9.9.8

  • CDN updates: can be switched off, multiple CNAMEs.
  • Uninstall process improved. It removes generated files and fixes edited files.
  • Cached dynamic pages can now be stored in Supercache files and compressed.
  • 1and1 Webhosting fix (/kunden/)
  • Remove log by email functionality as it caused problems for users who were inundated by email
  • Many more minor fixes and changes.

0.9.9.6

  • Fixed problem serving cached files with PHP
  • Added support for 304 «file not modified» header to help browser caching. (PHP caching only)
  • Added French & German translations, updated Italian translation and fixed translation strings.
  • Sleep 4 seconds between preload urls to reduce load on the server
  • Updated docs and FAQs.

0.9.9.5

  • Disable compression on on easy setup page. Still causes problems on some hosts.
  • Remove footerlink on easy setup page.
  • Don’t delete mod_rewrite rules when caching is disabled.
  • Don’t stop users using settings page when in safe mode.

0.9.9.4

  • Settings page split into tabbed pages.
  • Added new «Easy» settings page for new users.
  • New PHP caching mode to serve supercached files.
  • Mobile support fixes.
  • Added Domain mapping support plugin.
  • Added «awaiting moderation» plugin that removes that text from posts.
  • Terminology change. Changed «half on» to «legacy caching».
  • Fixed cache tester on some installs of WordPress.
  • Updated documentation
  • Added $wp_super_cache_lock_down config variable to hide lockdown and directly cached pages admin items.
  • Preloaded checks if it has stalled and reschedules the job to continue.
  • Serve the gzipped page when first cached if the client supports compression.
  • Lots more bug fixes..

0.9.9.3

  • Fixed division by zero error in half on mode.
  • Always show «delete cache» button.
  • Fixed «Update mod_rewrite rules» button.
  • Minor text changes to admin page.

0.9.9.2

  • Forgot to change version number in wp-cache.php

0.9.9.1

  • Added preloading of static cache.
  • Better mobile plugin support
  • .htaccess rules can be updated now. Added wpsc_update_htaccess().
  • Fixed «page on front» cache clearing bug.
  • Check for wordpress_logged_in cookie so test cookie isn’t detected.
  • Added clear_post_supercache() to clear supercache for a single post.
  • Put quotes around rewrite rules in case paths have spaces.

0.9.9

  • Added experimental object cache support.
  • Added Chinese(Traditional) translation by Pseric.
  • Added FAQ on WP-Cache vs Supercache files.
  • Use Supercache file if WP-Cache file not found. Useful if mod_rewrite rules are broken or not working.
  • Get mobile browser list from WP Mobile Edition if found. Warn user if .htaccess out of date.
  • Make sure writer lock is unlocked after writing cache files.
  • Added link to developer docs in readme.
  • Added Ukranian translation by Vitaly Mylo.
  • Added Upgrade Notice section to readme.
  • Warn if zlib compression in PHP is enabled.
  • Added compression troubleshooting answer. Props Vladimir (http://blog.sjinks.pro/)
  • Added Japanese translation by Tai (http://tekapo.com/)
  • Updated Italian translation.
  • Link to WP Mobile Edition from admin page for mobile support.

0.9.8

  • Added Spanish translation by Omi.
  • Added Italian translation by Gianni Diurno.
  • Addded advanced debug code to check front page for category problem. Enable by setting $wp_super_cache_advanced_debug to 1 in the config file.
  • Fixed wordpress vs wordpress_logged_in cookie mismatch in cookie checking function.
  • Correctly check if WP_CACHE is set or not. PHP is weird.
  • Added wp_cache_clear_cache() to clear out cache directory.
  • Only show logged in message when debugging enabled.
  • Added troubleshooting point 20. PHP vs Apache user.
  • Fixed problem deleting cache file.
  • Don’t delete cache files when moderated comments are deleted.

0.9.7

  • Fixed problem with blogs in folders.
  • Added cache file listing and delete links to admin page.
  • Added «Newest Cached Pages» listing in sidebox.
  • Made admin page translatable.
  • Added «How do I make certain parts of the page stay dynamic?» to FAQ.
  • Advanced: added «late init» feature so that plugin activates on «init». Set $wp_super_cache_late_init to true in config file to use.
  • Disable supercaching when GET parameters present instead of disabling all caching. Disable on POST (as normal) and preview.
  • Fixed problem with cron job and mutex filename.
  • Warn users they must enable mobile device support if rewrite rules detected. Better detection of when to warn that .htaccess rules must be updated (no need when rewrite rules not present)
  • Advanced: Added «wpsupercache_404» filter. Return true to cache 404 error pages.
  • Use the wordpress_test_cookie in the cache key.
  • Show correct number of cache files when compression off.
  • Fixed problem with PHP safe_mode detection.
  • Various bugfixes and documentation updates. See Changelog.txt

0.9.6.1

  • Move «not logged in» message init below check for POST.
  • Add is_admin() check so plugin definitely can’t cache the backend.
  • Add «do not cache» page type to admin page.

0.9.6

  • Add uninstall.php uninstall script.
  • Updated cache/.htaccess rules (option to upgrade that)
  • Added FAQ about category and static homepage problem.
  • Add wp_cache_user_agent_is_rejected() back to wp-cache-phase2.php
  • Show message for logged in users when caching disable for them.
  • Check filemtime on correct supercache file

0.9.5

  • Show next and last GC times in minutes, not local time.
  • Don’t serve wp_cache cache files to rejected user agents. Supercache files are still served to them.
  • If enabled, mobile support now serves php cached files to mobile clients and static cached files to everyone else.
  • Added checks for «WPSC_DISABLE_COMPRESSION» and «WPSC_DISABLE_LOCKING» constants to disable compression and file locking. For hosting companies primarily.
  • Added check for DONOTCACHEPAGE constant to avoid caching a page.
  • Use PHP_DOCUMENT_ROOT when creating .htaccess if necessary.

0.9.4.3

  1. Added «Don’t cache for logged in users» option.
  2. Display file size stats on admin page.
  3. Clear the cache when profile page is updated.
  4. Don’t cache post previews.
  5. Added backslashes to rejected URI regex list.
  6. Fixed problems with posts and comments not refreshing.

ru.wordpress.org


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.