it-swarm-es.com

¿Cómo eliminar errores 404 extraños en wp-admin?

Ejecuto un sitio de WordPress con unos 70 complementos activos.

De vez en cuando, aparece una página de error aleatorio ("No encontrado", aunque no he revisado los encabezados para ver si es un 404) en una página /wp-admin/ que aparece de la nada.

Simplemente intentarlo de nuevo resuelve el error, sin embargo, es bastante inconveniente si el error ocurre durante una actualización del complemento (porque la reactivación automática falla). Creo que este mismo problema es responsable de que ciertos módulos de mi Panel de Control no se carguen a veces.

Dada la lista de complementos que he instalado , ¿alguien sabe de problemas con o entre ellos que puedan causar este problema?

Editar:

Información de alojamiento: DreamHost; Creo que el servidor está ejecutando una compilación personalizada de Debian con Apache httpd

8
dgw

estuve teniendo problemas todo el día con lo que parecían ser 404 faltas de personal.

de todos modos, acabo de conversar con una persona de soporte técnico de dreamhost que me dijo que una cuenta de usuario que tenía con ella estaba alcanzando los límites de los recursos de memoria del proceso (todos los procesos) y eso era lo que estaba causando problemas extraños, aparentemente relacionados con htaccess. ¡Estaba recibiendo errores 404 intermitentes de un archivo htaccess que no debería haberse llamado en absoluto! era Dreamhost con un servidor de casa encantada.

al parecer, el proceso que mata al robot que utiliza Dreamhost matará un proceso web en el medio y luego, por alguna razón, el (ahora zombi) Apache realmente intenta terminar su trabajo (haciendo todo lo posible por salir del final poco glamoroso de una sub-petición). es mi mejor conjetura). arroja un error 500 en el registro http principal, pero después de hacerlo, en realidad desencadena la condición de reescritura y la regla que nunca debería haber sido activada (utilizando el archivo estándar -f y el directorio -d htaccess archivo anterior), y no lo hace No escriba una nueva entrada de registro! una nueva solicitud (invisible man) activa el archivo de índice en la última línea del archivo htaccess

¡Cuidado con los límites de recursos en las cuentas básicas de Dreamhost! Si superas sus límites, y tienes problemas con las líneas mod_rewrite, verás cosas extrañas que solo son aptas para la noche de Halloween: hombres invisibles, ¡404 perseguidos! Procesos no muertos! Apache zombie! htaccess moviéndose por su cuenta! ¡Ay!

espero que esto te ayude a evitar algunas horas de dolor.

6
sophistry

La única forma de depurar esto es deshabilitar un complemento a la vez, cada vez que intente reproducir el problema antes de deshabilitar otro complemento. Comience con los complementos que tienen algo que ver con la administración de WP, luego continúe con los complementos de temas regulares, widgets y demás.

Inspeccione la página "No encontrado" que le sirva mejor (navegue con Opera y abra el panel de información que le mostrará los encabezados, alternativamente navegue con Firefox y tenga Firebug con el panel "Red" habilitado) y realice una búsqueda en todos Tus plugins para ver si pueden estar sirviéndolos directamente. Si no, mire el registro del servidor web para averiguar qué recurso exacto no puede servir; un complemento podría estar realizando una redirección o reescritura sofisticada, por lo que no es necesariamente la URL que ve en su navegador lo que está causando el 404.

4
Asbjørn Ulsberg

Solo puedo relacionar mi propia experiencia, y hasta ahora, no he encontrado una regla "definitiva" para corregir todos problemas de una sola vez.

El principal problema con la configuración de DreamHost es que, en la lucha eterna para mantener el consumo de memoria al mínimo, significa deshacerse de tantas funciones como sea posible, es decir, todo lo que reducirá el ancho de banda (¡bueno para los visitantes!) O CPU (bueno para el servidor, pero DreamHost no controla el consumo de CPU tan agresivamente como controlan la RAM). Por ejemplo, esto significa deshacerse de gzip'ed HTML + CSS (que consumirá CPU + RAM) o cualquiera de los varios complementos de Minify (que también consumirán RAM). Cuanto más sofisticada sea la caché (me gusta usar W3 Total Cache, o al menos WP Super Cache), más RAM también se consumirá.

De manera similar, muchos complementos que limitan el número de consultas de MySQL para mejorar el rendimiento consumirán RAM. Por lo tanto, encontrar una compensación en la que pueda seguir respondiendo a su sitio con un buen rendimiento evitando consumir preciosos RAM ¡es una tarea difícil!

Hasta ahora, mis mejores resultados en sitios ocupados es desmarcar la Optimización de la velocidad de la página y la Seguridad Web adicional que aparentemente consumirán una gran cantidad de RAM, y en cambio confían en una combinación con W3 Total Cache y Cloudflare (servicio de proxy inverso gratuito). Cloudflare hará efectivamente lo mismo que el módulo "Seguridad web adicional", pero como se ejecuta fuera de DreamHost, está bien. W3 Total Cache consume mucha memoria, pero una vez que las páginas se almacenan de forma estática localmente, Cloudflare las almacenará de manera muy eficiente, por lo que puede obtener 404/500 al editar publicaciones, al menos sus visitantes no las experimentarán (Cloudflare también puede servir páginas estáticas incluso si DreamHost da un 404 o un 500).

Además, gracias a este artículo , he descubierto que FastCGI usa más RAM que CGI "normal". Y dado que PHP 5.3 es mejor para administrar RAM (recolección de basura más agresiva, menos pérdidas de memoria), he cambiado experimentalmente a PHP 5.3 CGI (no FastCGI ) sin la optimización de la velocidad de la página ni la seguridad web adicional, confiando en W3 Total Cache + Cloudflare para acelerar el sitio. Ahora el backoffice es más lento (¡más consumo de CPU!) Pero al menos no veo 404/500 (¡hasta ahora!).

Todavía no estoy contento con la combinación, así que ciertamente continuaré con la configuración de Tweak DreamHost con la esperanza de reducir aún más el consumo de RAM y aún así obtener el rendimiento adecuado. Como dijo @dgw, también uso muchos complementos, porque necesito su funcionalidad. No todo el mundo que aloja WP con DreamHost tiene necesidades simples de creación de blogs; cuanto más complejo sea el sitio, más funcionalidad requerirá ... y esa es la belleza de WordPress, solo necesita usar los complementos que realmente necesita, y mantener el núcleo WP instalar de forma simple si está feliz con pocas necesidades. Los complementos, sin embargo, no son necesariamente "malos" o tan pesados ​​en el sitio; Pero es cierto que algunos pueden consumir mucha RAM ...

3
Gwyneth Llewelyn

Esto es solo una idea aproximada: si obtiene un error 404 "real" (con los encabezados establecidos), puede buscar a través de sus complementos y buscar la función PHP header() y el número 404 . Esto podría desglosar el número de complementos de 70 a solo algunos. Entonces solo necesitas chequearlos.

Esto se puede hacer fácilmente con una IDE como Eclipse PDT que ofrece la búsqueda de una llamada a la función PHPespecífica.

Además de eso, pero sin ninguna garantía de que funcione correctamente, es escribir un complemento que se enganche en la configuración del encabezado y, a continuación, le indique qué código está configurando un potencial 404 (retroceso). Esto solo funcionaría si el complemento utiliza la función de API de WordPress. El primer método para buscar la función PHP funcionará independientemente de WP API.

3
hakre

Más información necesaria:

1) ¿Por qué tantos complementos?

2) ¿Qué sistema operativo está ejecutando su proveedor de alojamiento?

3) ¿Qué servidor web?

4) ¿Tiene acceso a los registros del servidor httpd, en particular a los registros de errores?

5) ¿Qué dicen los registros de errores en los plazos que rodean estos problemas?

(Ahora, a decir verdad, si estamos generalizando para "el promedio de J6P que ejecuta WordPress podría tener esta pregunta exacta, podríamos comenzar por indicar a dicho J6P que responda al menos a las 5 preguntas anteriores ...)

2
ZaMoose