WP File Cache: долговременное кэширование в WordPress
Повышение производительности WordPress в один клик
Как известно, WordPress поддерживает два вида кэширования: Кэширование на уровне страниц; Кэширование на уровне запросов. Кэширование на уровне страниц WordPress поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (Hyper Cache, WP Super Cache и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно: невозможность использования динамических элементов (например, captcha, [...]
← Вернуться к полной версии записи «WP File Cache: долговременное кэширование в WordPress»…
Автор: Vladimir;
Комментарии к статье «WP File Cache: долговременное кэширование в WordPress» (289) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «WP File Cache: долговременное кэширование в WordPress»
गते गते पारगते पारसंगते बोधि स्वाहा
Плагин версии 1.2.8, WordPress 2.9.2
Плагин не сохраняет настройку «Не использовать плагин в админке».
В результате плагин не дает редактировать посты блога, конфликтуя с другим плагином (YAPB) и выдавая такое сообщение:
Catchable fatal error: Object of class YapbImage could not be converted to string in /var/www/waralbum.ru/htdocs/wp-includes/formatting.php on line 427
Обновитесь.
Обратите внимание, что ошибка обнаруживается в
wp-includes/formatting.php. Причем указывает на класс YapbImage из YAPB. Причем тут File Cache?Если интересно, сделайте backtrace, увидите, откуда растут ноги
А вообще WordPress 2.9.2, WP File Cache 1.2.8, YABB 1.9.24 — всё отлично работает (только Suhosin ругается)
Если FileCache активен, то ошибка появляется. Если не активен – ошибки нет. Это значит, что именно FileCache вызывает ошибку. Хотя сообщение об ошибке не говорит об этом буквально.
Обновил и Вордпресс, и YapBB. Всё то же самое – настройка «Не кэшировать в админке» не запоминается, указанная выше ошибка – на месте.
WordPress-то зачем обновлять? WP File Cache обновите.
К слову, совсем не значит
Будет не лень, посмотрите на
YapbBaseOption::update_html_option(). Реализация метода не до конца совместима с WordPress Options API.Не поленитесь, сделайте backtrace в
wp_check_invalid_utf8().Вам в любом случае отключение кэша в админке не поможет — плагин изменяет объект с постом перед тем, как тот попадает в кэш (случается не всегда). В объект добавляется еще один объект (типа YapbImage), на котором функция
sanitize_post()и обламывается (так как ожидает строку). Лечить нужно именно плагин.Если вообще конкретно — то ошибка в фильтре
Yapb::_filter_the_posts(). Он вызывается по событиюthe_posts— после того, как список постов был получен из базы, но перед тем, как он попадёт в кэш. Плагин делает так:if (!is_null($image = YapbImage::getInstanceFromDb($post->ID))) {
$post->image = $image;
}
$post->image = $image;— так делать нельзя, так как WordPress не ожидает объектов внутри данных поста.Это значит, что автор YAPB плохо знает внутренности WordPress.
Станислав, рецепт исправления плагина здесь.
[...] WP File Cache: долговременное кэширование в WordPress [...]
СКажите пожалуйста а сколько он хранит кеш для пользовательских груп или же он его постоянно создаёт?
Заметил одну особенность этого полезного плагина. Он не кэширует запросы которые сделаны «своими руками». То есть если я, например, в файле functions.php (тот который лежит в файлах темы) использую SQL запрос к базе через стандартный $wpdb->query. Запросы самого движка WP кэшируются.
Так и должно быть или это бага?
Запросы наблюдаю через $wpdb->queries.
WP 2.7 + FC 1.2.1 – не пинать, пока обновить не могу.
Так и должно быть. Если Вы хотите закэшировать запрос, нужно использовать WordPress Cache API.
Как-то так:
if (!$data) {
$data = $wpdb->get_results("...");
wp_cache_set('key', $data, 'group', $ttl); //$ttl - время жизни объекта в кэше
}
// Можно использовать $data
Зависит от WordPress и конкретных плагинов. Максимальное время жизни составляет один час.
Здравствуйте Владимир!
Спасибо за блог и плагины!
Не могли бы Вы коротко объяснить, как работает стандартный кеш WP? Меня интересует, то куда он сохраняется, отдельно в файлы или куда-то в буфер? Т.е. ваш плагин создает поддержку межсессионного кеширования и кеш сохраняется в определенную папку в файлы, а стандартный кеш WP, где хранится?
Не сохраняется. Кэш WordPress работает в пределах одного запроса, все данные кэшируются в память и уничтожаются сразу после завершения работы скрипта.
На WordPress 3.0 не работает, не пускает на страницу настройки плагина(говорит что у вас нет полномочий), а после входа в свой профиль, плагин отключается совсем
Всё прекрасно работает! Перед обновлением желательно отключать все плагины, тем более кэширующие.
В вашем случае, если уже произвели обновление и вас не пускает в админку – просто удалите папку wp-file-cache из /wp-content/plugins/ и файл object-cache.php из /wp-content/, после чего установите WP File Cache заново.
File Cache принципиально не будет работать с WP 3.0 — слишком много что изменилось в коде. В качестве альтернативы можно использовать Object Cache (в нем есть движок, эмулирующий File Cache).
В самом деле?
Первые 2 скрина с включённым WP File Cache: 01 и 02.
Вторые два с выключенным: 03 и 04.
Версия WP: 3.0.1
Версия WP File Cache: 1.2.8.2
К тому же стоило внимательно почитать новости по этому плагину:
$__sjfc_optionsстала глобальной, так какobject_cache.phpможет вызываться из функции, а не из глобального контекста. А поддержкиwp_cache_reset(), возможности повторного вызоваwp_cache_init()и прочих вещей, нужных для работы с WPMU/WordPress MultiSite в плагине не было и уже не будет.Да, в частном случае может работать, но в конфигурации MultiSite это закончится потерей данных. Поэтому если нужна полноценная поддержка WP 3.0, используйте SJ Object Cache.
В режиме MultiSite действительно не пробовал.
А SJ Object Cache даёт меньший эффект производительности, поэтому и остался на WP File Cache.
Алексей, а если не секрет, как производительность измеряли? Я считал, что движок File Cache один и тот же и там, и там.
[...] Спасибо разработчику, Владимиру Колесникову! На его блоге можете найти подробнейшее описание плагина, как его [...]
[...] везде, хотя регистрация недоступна… может быть этот ping [...]