- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Жили-были пара сайтов и все у них было хорошо.
Потом насатала пара переезжать на новый сервер.
Заодно обычный PHP 5.6 был заменен на 7-ю версию FastCGI (Nginx + PHP-FPM), добавлено кэширование fastcgi, пересобран nginx с модулем fastcgi_cache_purge и в вордпрессы добавлен плагин Nginx Helper.
Сайты стали работать быстрее и все было замечательно, пока не вышло обновление для одного из плагинов.
После успешного обновления сайты перестали открываться, выдавая различные странные ошибки. Логи ошибок внизу.
Все ошибки я для себя условно разделил на три типа:
1. когда прописан инклюд file.php, а в браузере идет попытка инклюдить file.pgp
2. ошибки в плагинах (даже тех, которые не обновлялись), один раз ошибка была в теме
3. ошибки в движке вордпресса
Каждый раз для устранения ошибок помогало либо накатывание бекапа файлов, либо перезаливка файлов движка вордпресса, либо удаление проблемных плагинов, либо полное восстановление из резервной копии.
Если только удалить плагины, в которых вдруг появлялась ошибка, то следующим шагом ошибки обязательно появлялись в движке worpdress.
В момент возникновения ошибки внутри файлов на указанных строках корректный код. Права доступа на файлы и папки верные.
Я сначала думал, что проблема в обновляемом плагине, но после успешного восстановления работы сайтов почти всегда удавалось успешно обновить плагин до новой версии, на которой был сбой и потом все работало замечательно до очередного обновления.
Также эти "странные" ошибки возникают, если попытаться добавить новый плагин.
Если не пытаться ничего обновлять и добавлять из новых плагинов - сайты работают замечательно и без проблем.
Но оставаться без обновлений вообще или каждый раз по несколько часов тратить на восстановление работоспособности тоже не дело...
Примеры ошибок:
телепатически такие вопросы не решаются. надо иметь доступ к файлам.
в логах все же написано.
открываете /wp-includes/pomo и смотрите действительно ли там есть файл entry.pgp
подозреваю что это опечатка чья-то и должно быть на самом деле entry.php
тогда открываете wp-includes/pomo/translations.php on line 11 и правите
также wp-includes/functions.php.php вызывает сомнения. может просто functions.php есть файл?
тоже правите на правильный.
остальные ошибки (Call to undefined function...) скорей всего вытекают из предыдущей.
потом до и после обновления обращаете внимание на дату модификации этих проблемных файлов. чтоб понимать точно когда и после какого действия они изменялись.
ну и конечно никогда нельзя исключать что сайт на wp уже давненько не ваш сайт :)
и на нем полно "левых" файлов, левых зашифрованных php-вставок в случайных файлах.
надо только на месте смотреть...
Выше об этом писал, что в скриптах все ок, повторюсь.
открываете /wp-includes/pomo и смотрите действительно ли там есть файл entry.pgp
В файле прописан entry.php, но когда возникает ошибка при вызове через браузер он становится *.pgp
также wp-includes/functions.php.php вызывает сомнения. может просто functions.php есть файл?
Также в скрипте прописан верный вызов файла, который существует.
Т.е. ни entry.pgp, ни functions.php.php в момент возникновения ошибки в коде нет. В коде прописаны верные вызовы entry.php и functions.php
ну тогда чем еще помочь? :)
никто кроме вас не видит что там происходит. может быть что угодно.
Помочь тем, что подсказать в какую сторону копать.
С кодом все ок, получается проблема в nginx в части обработки кода? Такое вообще может быть, чтобы, например, в скрипте прописано куча инклюдов, он первые файлы инклюдит нормально, а у двадцатого файла вдруг меняет расширение?
Все что менял на сервере до возникновения проблемы описано в первом посте.
По моему решение очевидно - убрать разные прослойки (плагины). Зачем они? Nginx прекрасно из коробки кеширует все что нужно. Грамотно настрокить кеширование и все.
Понаустанавливаете 100500 ненужных плагинов, а потом ищите что с чем не дружит.
У меня Nginx + PHP-FPM, но CSM Джумла (стандатрное кеширование джумлы все выключено - кеширует только Nginx) (php 7,2). Все работает идеально.
По моему решение очевидно - убрать разные прослойки (плагины). Зачем они? Nginx прекрасно из коробки кеширует все что нужно. Грамотно настрокить кеширование и все.
Само кеширование настроено из коробки и работает идеально, согласен.
Вот только из вордпресса, на сколько мне известно, при обновлении записи нельзя делать сброс кеша из коробки.
Для этого я и поставил модуль fastcgi_cache_purge https://github.com/FRiCKLE/ngx_cache_purge в nginx, а в сам вордпресс плагин Nginx Helper.
Вы fastcgi_cache_purge предлагаете убрать?
У меня Nginx + PHP-FPM, но CSM Джумла (стандатрное кеширование джумлы все выключено - кеширует только Nginx) (php 7,2). Все работает идеально.
Если не обновлять плагины и не добавлять новые плагины, то все тоже работает идеально.
Чтение, редактирование и добавление новых постов идет без проблем.
Понятно, да вспомнил - мне мой кодер писал специальное решение, куда вводишь нужный урл и оно очищает его кеш. Но уже потом где-то в сети я видел и спец команду - как по ssh можно очистить не весь кеш а только нужную страницу, погуглите.
---------- Добавлено 02.06.2018 в 17:28 ----------
Вот нашел этот кусок кода у себя, все работает.
* Функция очистки кеша Nginx
*
* CommentsHelperQuery::clearCache('http(s)://*');
*
* @param string $value
* @return
*/
function clearCache($value)
{
jimport('joomla.filesystem.file');
if(!empty($value))
{
$data = parse_url($value);
$filename = md5('GET|site.ru|'.$data['path']);
JFile::delete('/var/cache/nginx/papka-kesha-saita/'.substr($filename, -1).'/'.substr($filename, -3, 2).'/'.$filename);
return true;
}
return false;
}
}
Все-таки дело не в кеширование nginx похоже.
Когда отключаю для домена fastcgi_cache, перезапускаю nginx, опять пытаюсь установить\обновить плагины - получаю ошибки с подменой букв в путях:
Причем, что странно, в одной и той же ошибке пишет и не верную папку wp-contelt и верную wp-content при указании на место возникновения ошибки.
У вас походу где-то вирус прошился. Не бывает с воздуха замены php на pgp. Это не магия, это строгий код.
Не пробовали залить WP файлы все заново под ноль? т.е. версия точно держит PHP7? У вас последняя версия PHP7?
Вряд ли вирус будет активничать только когда я решу плагины обновлять, а когда в админке добавляю\правлю - ничего не делать...
Пробовал заливать файлы вордпресса поверх из чистого дистибутива - раза два из десяти попыток помогло.
В основном использую восстановление из резервной копии - это хоть и дольше намного, зато восстанавливает работоспособность в половине случаев.