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

Ejecuto un sitio de WordPress con unos 70 complementos activos.

De vez en /wp-admin/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 que aparece de la nada.

Simplemente intentarlo nuevamente resuelve el error, sin embargo, es bastante inconveniente si el error ocurre durante una actualización del complemento (porque falla la reactivación automática). Creo que este mismo problema es responsable de que ciertos módulos en mi Tablero 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 ejecuta una compilación Debian personalizada con Apache httpd

Tuve problemas todo el día con lo que parecían ser 404 errores.

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

aparentemente, el robot que mata el proceso que utiliza dreamhost matará un proceso web en el medio y luego, por alguna razón, el apache (ahora zombie) en realidad intenta terminar su trabajo (haciendo todo lo posible para salir limpiamente del final poco glamoroso a una subrequest es mi mejor suposición) arroja un error 500 en el registro http principal, pero después de hacerlo, en realidad dispara la condición de reescritura y la regla que nunca debería haberse disparado (usando el archivo estándar -f y el archivo -d htaccess arriba) - y no lo hace No escriba una nueva entrada de registro! una nueva solicitud (hombre invisible) 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 acceso a las líneas mod_rewrite, verás cosas extrañas que solo son aptas para la noche de Halloween: ¡hombres invisibles, 404 encantados! procesos no muertos! zombie apache! ¡Htaccess se mueve solo! ¡Ay!

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

La única forma de depurar esto es deshabilitar un complemento a la vez, cada vez que se intenta reproducir el problema antes de deshabilitar otro complemento. Comience con los complementos que tienen algo que ver con la administración de WP, luego baje a complementos de tema, 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 haga una búsqueda a través de todos sus complementos para ver si podrían estar sirviéndolo directamente. Si no es así, eche un vistazo al registro del servidor web para averiguar qué recurso exacto no puede servir; un complemento podría estar haciendo una redirección o reescritura elegante, por lo que no es necesariamente la URL que ve en su navegador la que está causando el 404.

Solo puedo relatar mi propia experiencia, y hasta ahora, no he encontrado una regla "definitiva" para solucionar todos los problemas de un solo golpe.

El principal problema con la configuración de DreamHost es que, en la eterna lucha por 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 ellos controlan la RAM). Por ejemplo, esto significa deshacerse de HTML + CSS gzip'ed (que consumirá CPU + RAM) o cualquiera de los varios complementos de Minify (que también consumirá RAM). Cuanto más sofisticado sea el caché (me gusta usar W3 Total Cache, o al menos WP Super Cache), más RAM se consumirá también.

Del mismo modo, muchos complementos que limitan la cantidad de consultas MySQL para mejorar el rendimiento consumirán RAM. Por lo tanto, encontrar una solución de compromiso en la que aún pueda mantener su sitio respondiendo con un buen rendimiento mientras evita consumir RAM preciosa es una tarea difícil.

Hasta ahora, mis mejores resultados en sitios ocupados es desmarcar Optimización de velocidad de página y Seguridad web adicional, que aparentemente consumirá mucha RAM, y confío en una combinación con W3 Total Cache y Cloudflare (servicio gratuito de proxy inverso). Cloudflare efectivamente hará 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 estáticamente localmente, Cloudflare las almacenará en caché 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 , descubrí que FastCGI usa más RAM que CGI 'normal'. Y dado que PHP 5.3 es mejor en la administración de RAM (recolección de basura más agresiva, menos pérdidas de memoria), he cambiado experimentalmente a PHP 5.3 CGI (no FastCGI) sin Optimización de velocidad de página ni 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, por lo que seguiré modificando la configuración de 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 utilizo muchos complementos, porque necesito su funcionalidad. No todos los que alojan WP con DreamHost tienen necesidades simples de blogging; 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 la instalación básica de WP simple si está satisfecho con pocas necesidades. Sin embargo, los complementos no son necesariamente "malos" o pesados ​​en el sitio; pero es cierto que algunos pueden consumir mucha RAM ...

Esta es solo una idea aproximada: si obtiene un error 404 "real" (con los encabezados configurados), puede buscar entre sus complementos y buscar la función PHPheader() y el número 404. Esto podría reducir la cantidad de complementos de 70 a solo algunos. Entonces solo necesita verificarlos.

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

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

Se necesita más información:

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, particularmente a los registros de errores?

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

(Ahora, la verdad sea dicha, si estamos generalizando para "J6P promedio que ejecuta WordPress podría tener esta pregunta exacta, podríamos comenzar dirigiendo dicho J6P para responder al menos las 5 preguntas anteriores ...)