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

Estuve teniendo problemas todo el día con lo que parecían ser 404 fallas en el sistema.

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

aparentemente, el robot de proceso que utiliza Dreamhost matará un proceso web en el medio y luego, por alguna razón, el apache (ahora zombie) intenta terminar su trabajo (haciendo todo lo posible para salir del extremo sin glamour a una subrequest es mi mejor conjetura). 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 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

¡Ten 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.

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 desplácese a los 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 realice una búsqueda a través de todos sus complementos para ver si pueden servirlo directamente. De lo contrario, eche un vistazo al 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.

Solo puedo relacionar mi propia experiencia, y hasta ahora, no he encontrado una regla "definitiva" para solucionar todos los problemas de todos 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 la CPU de forma tan agresiva como 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á RAM). Cuanto más sofisticada sea la memoria caché (me gusta usar W3 Total Cache, o al menos WP Super Cache), también se consumirá más RAM.

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 pueda seguir respondiendo a su sitio con un buen rendimiento y evitar consumir la valiosa RAM es una tarea difícil.

Hasta ahora, mis mejores resultados en sitios ocupados es deseleccionar Optimización de velocidad de página y 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 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, así que ciertamente continuaré 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 uso muchos complementos, porque necesito su funcionalidad. No todos los usuarios de WP con DreamHost tienen necesidades simples de blogueo; 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 algunas necesidades. Los complementos, sin embargo, no son necesariamente "malos" o tan pesados en el sitio; pero es cierto que algunos pueden consumir mucha RAM ...

Esto es solo una idea aproximada: si aparece un error 404 "real" (con los encabezados establecidos), puede buscar a través de sus complementos y buscar PHP header() function y el número 404. Esto podría desglosar el número de complementos de 70 a solo algunos. Entonces solo necesitas 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.

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 luego le dé un seguimiento del código que 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 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, en particular a los registros de errores?

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

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