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

Question

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

18 авг. 2010 г., 06:46:16

Просмотры: 20.4K

Голосов: 8

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

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

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

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

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

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

dgw

359

плагины wp admin ошибки 404 ошибка отладка

Комментарии

Не хочу быть занудой, но это скорее вопрос поддержки, а не то, что мы бы стали обсуждать здесь; я проголосую за закрытие. Задайте ваш вопрос на http://wordpress.org/support. Если вы проведете тестирование и сузите вопрос так, чтобы он был применим не только к вашей ситуации, тогда, возможно, это будет уместным вопросом для нашего сообщества. Еще раз извиняюсь за такой подход, но вопросы на WordPress Answers должны быть полезны всем пользователям, а поток запросов в поддержку может это разрушить.

MikeSchinkel

18 авг. 2010 г. 08:15:39

Согласен, поэтому я тоже проголосую за закрытие.

Ben Everard

18 авг. 2010 г. 12:57:16

Поддерживаю. Голосую за закрытие как слишком узкоспециализированный вопрос.

John P Bloch

18 авг. 2010 г. 17:16:02

Я голосую против закрытия. Многие новички в WordPress могут столкнуться с ошибками 404 в WP-Admin, и в конечном итоге это сводится к багу в плагине или теме, или их влиянию, возможно, на правило перезаписи (хранящееся в базе данных в wp-options или в файле .htaccess). Вместо этого нам следует предоставлять общие шаги по устранению неполадок, которые помогут быстрее выявить проблемную область.

Volomike

18 авг. 2010 г. 23:21:36

Ну, даже несмотря на то, что это больше похоже на вопрос поддержки, здесь достаточно информации, чтобы хотя бы предложить способы быстрого решения проблемы.

hakre

20 авг. 2010 г. 13:11:14

Все ответы на вопрос

Комментарии

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

dgw

23 окт. 2010 г. 23:56:03

Проблема не только в Dreamhost. Я переехал с Dreamhost на частный сервер в другом месте, но у меня до сих пор регулярно возникает эта проблема.

supertrue

24 сент. 2012 г. 01:09:23

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

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

Asbjørn Ulsberg

281

18 авг. 2010 г. 23:17:29

Комментарии

При 70 плагинах было бы очень удобно найти способ сделать это сверхбыстро, без необходимости вручную отключать и тестировать каждый из них, например, с помощью тестового файла для плагинов.

Volomike

18 авг. 2010 г. 23:23:45

Я вижу, вы отредактировали свой первоначальный ответ, добавив отличный совет для более быстрого поиска решения.

Volomike

18 авг. 2010 г. 23:45:07

Спасибо, asbjornu. Я займусь этим после возвращения с отпуска с семьей.

dgw

19 авг. 2010 г. 18:45:28

Я просмотрел логи сервера, но не смог найти ничего конкретнее, чем "Premature end of script header". Видимо, это не может быть так просто...

dgw

1 сент. 2010 г. 23:34:59

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

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

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

hakre

12.9K

20 авг. 2010 г. 13:08:34

Комментарии

Звучит многообещающе. Что-то ещё, что нужно изучить после моего отпуска. :)

dgw

21 авг. 2010 г. 07:16:16

Мне удалось немного покопаться, пока я ещё в отъезде, и я обнаружил, что мой плагин для резервного копирования, кажется, вызывает вывод 404 ошибки. Firebug показывает, что это действительно 404. Есть прогресс... Однако теперь у меня проблемы с воспроизведением этой ошибки, так что, пожалуй, сделаю перерыв. Ненавижу плавающие баги!

dgw

1 сент. 2010 г. 23:33:59

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

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

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

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

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

Gwyneth Llewelyn

130

11 сент. 2011 г. 17:02:26

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

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

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

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

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

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

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

ZaMoose

1.67K

18 авг. 2010 г. 23:47:37

Комментарии

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

dgw

1 сент. 2010 г. 23:37:11

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

Странно.

ZaMoose

3 сент. 2010 г. 23:44:46

User 100 · Accepted Answer · 2010-10-23T05:38:07Z

Весь день у меня были проблемы, которые казались ложными срабатываниями 404 ошибок.

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

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

Будьте осторожны с лимитами ресурсов в базовых аккаунтах Dreamhost! Если вы превысите их лимиты и у вас есть htaccess с mod_rewrite, вы увидите странные вещи, подходящие только для Хэллоуина — невидимые запросы, 404-призраки! Неживые процессы! Зомби-Apache! Htaccess, который двигается сам по себе! Ужас!

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