scribu
  • 0
Гуру

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

  • 0

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

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

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

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

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

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

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

    • 0
  2. У меня были проблемы весь день с пропусками зажигания 404.

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

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

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

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

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

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

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

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

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

    До сих пор мои лучшие результаты на загруженных сайтах — это снять флажки Оптимизация скорости страницы и Дополнительная веб-безопасность, которые, по-видимому, будут потреблять много оперативной памяти, и вместо этого полагаться на комбинацию с 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) без оптимизации скорости страницы и дополнительной веб-безопасности, полагаясь на W3 Total Cache + Cloudflare для ускорить работу сайта. Теперь бэкофис работает медленнее (больше потребление процессора!), но по крайней мере я не вижу 404/500 (пока!).

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

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

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

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

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

    1) Зачем столько плагинов?

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

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

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

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

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

    • 0

Оставить ответ

You must login to add an answer.