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

8

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

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

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

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

Редактировать:

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

DGW
источник
1
Не для того, чтобы быть PITA, но это действительно вопрос поддержки, а не то, что мы хотели бы здесь осветить; Я собираюсь голосовать, чтобы закрыть. Спросите на http://wordpress.org/support вместо этого. Если вы проведете некоторое тестирование и сузите свой вопрос, чтобы его можно было применить не только к вашей ситуации, это может сделать вопрос приемлемым здесь. Опять же, извините, что так, но наши ответы на WordPress должны быть применимы ко всем пользователям, и тонны запросов на поддержку убьют это.
MikeSchinkel
Я согласен, поэтому я собираюсь голосовать, чтобы закрыть тоже.
Бен Эверард
1
Согласовано. Голосование по закрытию слишком локализовано.
Джон П Блох
2
Я голосую, чтобы не закрыться. Многие новички в WP могут столкнуться с ошибками 404 в WP-Admin, и в конечном итоге это сводится к ошибке в плагине или теме или их влиянию, возможно, на правило перезаписи (хранящееся в базе данных в параметрах wp или в. файл htaccess). Вместо этого мы должны предоставить общие шаги по устранению неполадок, которые можно предпринять, чтобы намного быстрее идентифицировать проблемную область.
Volomike
Ну, даже если это вопрос поддержки, у него достаточно информации, чтобы хотя бы предложить некоторые способы быстрого решения проблемы.
hakre

Ответы:

6

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

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

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

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

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


источник
У меня определенно много mod_rewriteвещей в моих .htaccessфайлах. Похоже, это то, что происходит со мной. Я знал, что достиг заданных пределов памяти при выполнении заданий резервного копирования, но не для «реальных» запросов. Спасибо за обмен вашего опыта; надеюсь, ваш ответ сэкономит много времени.
dgw
Это не просто Dreamhost. Я перешел с Dreamhost на частный сервер в другом месте, и у меня все еще есть эта проблема.
Supertrue
4

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

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

Асбьерн Ульсберг
источник
При 70 плагинах было бы очень удобно, если бы можно было найти способ сделать это очень быстро, без необходимости вручную деактивировать и тестировать каждый из них, например, с помощью файла тестера плагинов.
Volomike
Я вижу, что вы отредактировали свой оригинальный ответ с отличным советом, чтобы найти ответ быстрее.
Воломике
Спасибо, асбьёрну. Я займусь этим после того, как вернусь из отпуска со своей семьей.
dgw
Я просмотрел логи сервера и не смог найти ничего более конкретного, чем «Преждевременный конец заголовка скрипта». Думаю, это не может быть так просто ...
dgw
3

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

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

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

Пока что мои лучшие результаты на загруженных сайтах - снять флажок 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 использует больше оперативной памяти, чем «обычный» CGI. И поскольку PHP 5.3 лучше справляется с управлением ОЗУ (более агрессивный сбор мусора, меньше утечек памяти), я экспериментально переключился на PHP 5.3 CGI (не FastCGI) без оптимизации скорости страницы или Extra Web Security, полагаясь на W3 Total Cache + Cloudflare для ускорить сайт. Теперь бэк-офис работает медленнее (больше потребляет процессор!), Но, по крайней мере, я не вижу 404/500 (пока!).

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

Гвинет Ллевелин
источник
3

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

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

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

hakre
источник
Это звучит многообещающе. Что еще посмотреть после моего отпуска. :)
dgw
Мне удалось немного поэкспериментировать, пока я еще не в городе, и обнаружил, что мой плагин резервного копирования, похоже, требует вывода 404. Firebug показывает, что это действительно 404. Некоторый прогресс ... Однако сейчас у меня возникают проблемы с запуском проблемы, поэтому я думаю, что сделаю перерыв. Я ненавижу периодические ошибки!
2010 г.
2

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

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

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

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

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

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

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

ZaMoose
источник
У меня есть все эти плагины, потому что я использую функции, которые они выполняют; почему еще? Журналы ошибок ничего не говорят вообще. Я нахожусь на DreamHost, поэтому я думаю, что на сервере работает пользовательская сборка Debian с Apache httpd.
2010 г.
Теперь, когда вы упомянули об этом, я тоже вижу эти случайные ошибки на своих сайтах DH. Это особенно происходит, когда я пытаюсь обновить сеть в установках MS и запустить импортер. Странный.
ZaMoose