WP File Cache: долговременное кэширование в WordPress
Повышение производительности WordPress в один клик
Как известно, WordPress поддерживает два вида кэширования: Кэширование на уровне страниц; Кэширование на уровне запросов. Кэширование на уровне страниц WordPress поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (Hyper Cache, WP Super Cache и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно: невозможность использования динамических элементов (например, captcha, [...]
← Вернуться к полной версии записи «WP File Cache: долговременное кэширование в WordPress»…
Автор: Vladimir;
Комментарии к статье «WP File Cache: долговременное кэширование в WordPress» (299) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «WP File Cache: долговременное кэширование в WordPress»
गते गते पारगते पारसंगते बोधि स्वाहा
Почините ваш плагин пожалуйста!!!
Установила, выкинуло ошибку:
Warning: require_once(/home/bc/sites/olyapka.ru/www/wp-content/plugins/file-cache/lib/class.FileCache.php) [function.require-once]: failed to open stream: No such file or directory in /home/bc/sites/olyapka.ru/www/wp-content/object-cache.php on line 4
Переименовала вашу папку wp-file-cache в /file-cache – заработал. Но не открываются опции, выдает “нет такого файла”. Вам об этом кстати выше говорили – http://blog.sjinks.pro/wordpress-plugins/wp-file-cache/comment-page-5/#comment-2917
Ольга, скачайте плагин с WordPress.org. Там это уже три дня как исправлено
http://downloads.wordpress.org/plugin/wp-file-cache.1.2.4.2.zip
А откуда я его еще по вашему качала? Попробую еще раз.
Да, заработало. Но вчера при закачке и с вашего сайта, и с вордпресса происходило описанное мной. Даже не знаю, как это получалось.
Спасибо.
[...] Скачать плагин WP File Cache для WordPress вы можете здесь. [...]
А этот плагин будет корректно работать, если установлено 2 сайта на один движок?
Т.е. двиг один и БД тоже одна, но там разные префиксы у таблиц, т.е. как бы получается 2 разные базы данных в одной и управляются они одним движком (папкой). Оба сайта на одном шаблоне работают, в зависимости от используемой БД в шаблоне меняются некоторые элементы. Ну и админка соответственно разные данные выводит и настройки ВП тоже разные (они ж в бд хранятся.)
Вряд ли. Так как если используется одна установка WordPress, то и кэш будет один — глобальный.
Единственное решение — изменить в файле
object-cache.phpв функцииwp_cache_init()механизм определения пути к кэшу в строкеПуть для каждого сайта должен быть своим.
Но скажу честно, я такую конфигурацию не тестировал.
Работает, при условии, что для каждой базы со своим префиксом используется своя папка, т.е. если база с префиксом, например, wp1_ и сам WP находится в имя_папки_1 и в той же базе есть база с префиксом wp2_ и сам WP находится в имя_папки_2.
Забыл сказать, что вышеописанное мной работает без хирургического вмешательства в сам плагин.
Папку удалить не могу с вашим плагином wp-content/wp-file-cache/cache папка сама появляется. через фтп и через админ панель хостера удалял нифига wp-content/wp-file-cache/en-cache папка с кешом внутри появляется сама по себе сразу после удаления. Что может быть? Где настройки Вашего плагина хранятся?
Настройки хранятся непосредственно в
wp-content/object-cache.php. Строка видаТак как все таки удалить эту папку? Я этот файл снес вообще…а папка не удаляется? Что делать?
Перед тем, как сносить, нужно было очистить кэш. Плагин бы сам всё почистил.
В Вашем случае у файлов кэша, вероятно, другой владелец.
Залейте по FTP этот PHP-файл и выполните его:
function remove_dir($dir, $self)
{
$dh = @opendir($dir);
if (false === $dh) {
return;
}
while (false !== ($obj = readdir($dh))) {
if ('.' == $obj || '..' == $obj) {
continue;
}
if (false == @unlink($dir . '/' . $obj)) {
remove_dir($dir . '/' . $obj, true);
}
}
closedir($dh);
if ($self) {
@rmdir($dir);
}
}
remove_dir('путь к кэшу', true);
?>
[...] У создателя моего любимого файлового кеша под WP, вышел плагин быстрого объектного кеша, рекомендуется [...]
На нескольких блогах замечен глюк- не могу войти в админку, пишет неверный пароль. При очистке папки кеша через FTP – все в порядке.
если быть точным- папки
userlogins
Sergio, если будет возможность — сравните, пожалуйста, значения паролей в файлах в
userloginsсо значениями из БД.Я сам с такой проблемой не сталкивался, а воспроизвести пока не получается.
стабильно ловился этот баг на вп, работающем на SQLite. Таки вылечил обновлением версии PDO.
При активации плагина появляется фатальная ошибка:
Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in /www/h123box/www/htdocs/wp-content/plugins/wp-file-cache/file-cache.php on line 13
На wp-content перед активацией установлены права на запись (777). В wp-config.php присутствует строчка define(‘WP_CACHE’, true);. Wordpress последний, русский официальный. PHP 5. В чем может быть проблема?
Очень похоже, что у Вас всё же PHP 4. Проверьте.
Плагин действительно работает лучше себе подобного – ровно в 2 раза снизилось количество запросов к базе
Владимир Вы можете посоветовать что нибудь если возник вот такой перекос (это из ежедневной истории загрузки процессора\памяти)
Процессор Память
1.96% 13.86%
Бывает что хостер штрафует за перерасход памяти – и поэтому буду благодарен за любой совет по снижению ее расхода (может быть раз идет повышенный расход ram то может лучше совсем выключить hyper cache ?)
Установлена связка – Hyper Cache + WP File Cache, локализация убрана совсем, WP – 2.7.1, плагины оставлены только самые нужные для функционала, ковыряние в hyper с кешированием того или иного, enable/disable разные функции мало что дало.
Вообще снизить потребление памяти проблемно. Дело в том, что если Вы и используете страничный кэш (WP Super Cache, Hyper Cache, MaxSite Cache), всё равно в какой-то момент времени кэш будет перестраиваться, и WordPress будет есть память по полной программе.
Если на сервере есть gettext, можете попробовать использование серверного gettext — мне это помогло сэкономить еще 8 мегабайт памяти.
Уберите фиды из админки, отключите gzip-сжатие, откажитесь от использования меток.
PS — а сколько памяти хостер даёт? У меня WordPress редко больше 15-20 мегабайт потребляет.
Есть еще кардинальный вариант: удалите все комментарии из файлов WordPress. PHP хранит PHPDoc-комментарии в байт-коде (их можно вытащить с помощью Reflection API).
Владимир – хостер дает памяти сколько надо , только за каждый дополнительный % нагрузки нужно доплачивать по баксу в месяц, а если превышен лимит то 10 баксов штрафа или можно штраф не платить но на следующий раз (если за неделю будет еще превышение загрузки) то заблочат. На одном хостинг аккаунте у меня расположено 4 сайта. каждый в среднем ест 9,5-10 мб. Посетителей на одном 4-5 тысяч на трех других по 900-1200 в день, комментарии на всех отключены.Попробую на самом посещаемом совсем отключить Hyper, а Ваш оставлю и посмотрю что будет(я так понимаю вырастет загрузка на процессор но умеьшится на память) Спасибо также за gettext попробую поговорить с хостером.
[...] Version 1.2.7 | By Vladimir Kolesnikov | Visit plugin site [...]
http://windham.wordpress.com/2010/03/25/thanks-to-these-folks/Я конечно извиняюсь за тупость…
Cкажите а “каталог должен быть доступен на запись” – это 755 или 775?
или 777?
Зависит от ситуации. 777 — все будут иметь права на запись, 755 — только владелец, 775 — владелец и группа.