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


8

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


1
No para ser un PITA, pero esto es realmente un problema de soporte y no es algo que debamos cubrir aquí; Voy a votar para cerrar. Pregunte en http://wordpress.org/support en su lugar. Si hace algunas pruebas y limita su pregunta para que sea aplicable a algo más que su situación, podría ser una pregunta aceptable aquí. Una vez más, lamento ser de esta manera, pero las respuestas de WordPress deberían ser aplicables a todos los usuarios y toneladas de solicitudes de soporte matarán eso.
MikeSchinkel

Estoy de acuerdo, así que voy a votar para cerrar también.
Ben Everard

1
Convenido. Votación para cerrar como demasiado localizada.
John P Bloch

2
Yo voto para no cerrar. Muchas personas nuevas en WP pueden encontrar errores 404 en WP-Admin y, en última instancia, se trata de un error en un complemento o tema, o su efecto tal vez en una regla de reescritura (almacenada en la base de datos en wp-options o en el. archivo htaccess). Lo que deberíamos hacer, en cambio, es proporcionar pasos generales de solución de problemas que uno puede tomar para identificar el área del problema mucho más rápido.
Volomike

Bueno, incluso esto tiende a ser una pregunta de soporte, tiene suficiente información para al menos sugerir algunas formas de resolver el problema rápidamente.
Hakre

Respuestas:


6

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.


Definitivamente tengo muchas mod_rewritecosas en mis .htaccessarchivos. Parece que esto es lo que me está pasando. Sabía que había alcanzado los límites de memoria con mis trabajos de respaldo, pero no para solicitudes "reales". Gracias por compartir tu experiencia; Esperemos que su respuesta le ahorre tiempo a mucha gente.
dgw

No es solo Dreamhost. Me mudé de Dreamhost a un servidor privado en otro lugar, y todavía tengo este problema todo el tiempo.
supertrue

4

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.


Con 70 complementos, sería realmente genial si uno pudiera encontrar una manera de hacerlo súper rápido sin tener que desactivar y probar cada uno manualmente, como con un archivo de prueba de complementos.
Volomike

Veo que has editado tu respuesta original con un gran consejo para encontrar la respuesta más rápido.
Volomike

Gracias asbjornu. Investigaré esto después de regresar de vacaciones con mi familia.
dgw

Miré a través de los registros del servidor y no pude encontrar nada más específico que "Fin prematuro del encabezado del script". Supongo que no podría ser tan fácil ...
dgw

3

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


3

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.


Esto suena prometedor. Algo más que considerar después de mis vacaciones. :)
dgw

Me las arreglé para mirar un poco mientras aún estaba fuera de la ciudad, y solo encontré que mi complemento de copia de seguridad parece requerir la salida de un 404. Sin embargo, Firebug muestra que realmente es un 404. Algunos progresos ... Sin embargo, ahora tengo problemas para desencadenar el problema, así que supongo que me tomaré un descanso. Odio los errores intermitentes!
dgw

2

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 ...)


Tengo todos esos complementos porque uso las funciones que sirven; por que mas Los registros de errores no dicen mucho en absoluto. Estoy en DreamHost, así que creo que el servidor está ejecutando una compilación Debian personalizada con Apache httpd.
dgw

Ahora que lo menciona, yo también veo esos errores aleatorios en mis sitios DH. Ocurre especialmente cuando intento realizar una actualización de red en mis instalaciones de MS y ejecuto el importador. Extraño.
ZaMoose
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.