it-swarm-ru.tech

Как устранить странные ошибки 404 в wp-admin?

Я управляю сайтом WordPress с около 70 активными плагинами.

Время от времени я получаю страницу со случайной ошибкой ("Не найдено"), хотя я не проверял заголовки, чтобы увидеть, 404 ли это, на странице /wp-admin/, которая появляется из ниоткуда.

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

Учитывая список плагинов, которые я установил , кто-нибудь знает о проблемах с ними или между ними, которые могут вызвать эту проблему?

Правка:

Информация о хостинге: DreamHost; Я думаю, что на сервере работает пользовательская сборка Debian с Apache httpd

8
dgw

у меня были проблемы в течение всего дня с 404 пропусками.

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

по-видимому, робот, убивающий процесс, который использует Dreamhost, убьет веб-процесс в середине, а затем, по какой-то причине, (теперь зомби) Apache фактически пытается завершить свою работу (изо всех сил, чтобы чисто выйти из безоблачного конца в подзапрос моя лучшая догадка). он выдает ошибку 500 в основной журнал http, но после этого он фактически запускает условие и правило перезаписи, которые никогда не должны запускаться (используя стандартный файл -f и каталог -d htaccess выше), - и не не пишите новую запись в журнале! новый (невидимый человек) запрос затем запускает индексный файл в последней строке файла htaccess

остерегайтесь ограничений ресурсов в основных учетных записях Dreamhost! если вы выйдете за их пределы, и у вас есть htacess с линиями mod_rewrite, вы увидите странные вещи, которые подходят только для ночи Хэллоуина - невидимые люди, преследуемые 404! нежить! зомби-апач! htaccess движется сам по себе! Хлоп!

надеюсь, это поможет вам избежать нескольких часов боли.

6
sophistry

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

Проверьте страницу "Не найдено", которая вам лучше обслуживается (перейдите в Opera и откройте панель "Информация", которая покажет вам заголовки, альтернативно просмотрите Firefox и включите Firebug с включенной панелью "Сеть") и выполните поиск по всем ваши плагины, чтобы увидеть, могут ли они обслуживать его напрямую. Если нет, взгляните на журнал веб-сервера, чтобы узнать, какой именно ресурс он не может обслуживать; плагин может выполнять какую-то причудливую переадресацию или переписывание, поэтому не обязательно URL, который вы видите в своем браузере, вызывает 404.

4
Asbjørn Ulsberg

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

Основная проблема с настройкой DreamHost заключается в том, что в вечной борьбе за поддержание минимального потребления памяти это означает избавление от как можно большего числа функций, а именно всего, что уменьшит пропускную способность (хорошо для посетителей!) Или ЦП (хорошо). для сервера, но DreamHost не контролирует потребление ресурсов процессора так агрессивно, как они контролируют оперативную память). Например, это означает избавление от gzip'а HTML + CSS (который будет использовать CPU + RAM) или любого из нескольких плагинов Minify (которые также будут использовать RAM). Чем сложнее кеш (мне нравится использовать W3 Total Cache или, по крайней мере, WP Super Cache), тем больше будет потребляться RAM.

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

Пока что мои лучшие результаты на загруженных сайтах - это снять флажок Page Speed ​​Optimization и Extra Web Security, которые, очевидно, потребляют много оперативной памяти, и вместо этого полагаться на комбинацию с W3 Total Cache и Cloudflare (бесплатный сервис обратного прокси-сервера). Cloudflare будет выполнять те же действия, что и модуль "Extra Web Security", но, поскольку он работает за пределами DreamHost, все в порядке. W3 Total Cache занимает много памяти, но как только страницы статически хранятся локально, Cloudflare очень эффективно их кеширует - так что вы можете получить 404/500 при редактировании сообщений, по крайней мере ваши посетители их не увидят (Cloudflare также может обслуживать статические страницы даже если DreamHost дает 404 или 500).

Кроме того, благодаря этой статье , я обнаружил, что FastCGI использует больше RAM, чем "обычный" CGI. А поскольку PHP 5.3 лучше справляется с управлением RAM (более агрессивная сборка мусора, меньше утечек памяти), я экспериментально переключился на PHP 5.3 CGI (не FastCGI) без оптимизации скорости страницы и Extra Web Security, полагаясь на W3 Total Cache + Cloudflare для ускорения работы сайта. Теперь бэк-офис работает медленнее (больше потребляет процессор!), Но, по крайней мере, я не вижу 404/500 (пока!).

Я все еще недоволен этой комбинацией, поэтому я непременно продолжу настраивать настройки DreamHost, надеясь еще больше уменьшить потребление RAM и все же получить адекватную производительность. Как сказал @dgw, я также использую много плагинов - потому что мне требуется их функциональность. Не у всех, кто размещает WP с DreamHost, есть простые потребности в блогах; Чем сложнее сайт, тем больше функциональности он потребует ... и в этом прелесть WordPress, вам просто нужно использовать действительно нужные плагины и поддерживать простую установку ядра WP, если вы довольны мало потребностей. Однако плагины не обязательно являются "плохими" или слишком тяжелыми на сайте; но это правда, что некоторые могут потреблять много оперативной памяти ...

3
Gwyneth Llewelyn

Это просто грубая идея: если вы получаете "настоящую" ошибку 404 (с установленными заголовками), то вы можете искать в своих плагинах и искать функцию PHP header() и число 404 , Это может уменьшить количество плагинов с 70 до нескольких. Тогда вам нужно только проверить это.

Это легко сделать с помощью IDE, подобного Eclipse PDT, который предлагает поиск определенной функции PHP.

Рядом с этим, но без гарантии того, что он успешно работает, стоит написать плагин, который подключается к настройке заголовка, а затем дает вам проследить, какой код на самом деле устанавливает потенциал 404 (обратная трассировка). Это будет работать только если плагин использует функцию API WordPress. Первый способ поиска функции PHP будет работать независимо от API WP.

3
hakre

Требуется больше информации:

1) Почему так много плагинов?

2) Какую ОС использует ваш хостинг-провайдер?

3) Какой веб-сервер?

4) Есть ли у вас доступ к журналам сервера httpd, особенно к журналам ошибок?

5) Что говорят журналы ошибок в сроки, связанные с этими проблемами?

(Теперь, по правде говоря, если мы обобщаем для "среднего J6P, на котором работает WordPress, может возникнуть именно этот вопрос, мы могли бы начать с того, что указали бы указанному J6P ответить по крайней мере на 5 вопросов ...")

2
ZaMoose