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

La única forma de depurar esto es desactivar un plugin a la vez, intentando reproducir el problema cada vez antes de desactivar otro plugin. Comienza con los plugins que tengan algo que ver con la administración de WP, luego pasa a los plugins del tema habitual, widgets y similares.

Inspecciona mejor la página "No encontrado" que te aparece (navega con Opera y abre el panel de Info que te mostrará las cabeceras, o alternativamente navega con Firefox y habilita el panel "Red" en Firebug) y busca en todos tus plugins para ver si alguno podría estar sirviéndola directamente. Si no, revisa el registro del servidor web para averiguar qué recurso exacto no puede servir; un plugin podría estar haciendo algún tipo de redirección o reescritura sofisticada, por lo que no necesariamente es la URL que ves en tu navegador la que está causando el error 404.

Esta es solo una idea aproximada: Si obtienes un error 404 "real" (con cabeceras establecidas), podrías buscar entre tus plugins y buscar la función PHP header() junto con el número 404. Esto podría reducir el número de plugins de 70 a solo algunos. Luego solo necesitarías revisar esos.

Esto puede hacerse fácilmente con un IDE como Eclipse PDT que ofrece búsqueda de llamadas específicas a funciones PHP.

Además de eso, pero sin garantía de que funcione con éxito, está escribir un plugin que se enganche al establecimiento de cabeceras y luego te dé un rastro de qué código está estableciendo un potencial 404 (backtrace). Esto solo funcionaría si el plugin está usando la función API de WordPress. El primer método de buscar la función PHP funcionará independientemente de la API de WP.

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

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

Del mismo modo, muchos plugins que limitan el número de consultas MySQL para mejorar el rendimiento consumirán RAM en su lugar. Así que encontrar un equilibrio donde aún puedas mantener tu sitio respondiendo con buen rendimiento sin consumir la preciada RAM es una tarea difícil.

Hasta ahora, mis mejores resultados en sitios concurridos han sido desmarcar la Optimización de Velocidad de Página y la Seguridad Web Extra, que aparentemente consumen mucha RAM, y confiar en cambio 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 Extra", 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 de forma local, Cloudflare las cacheará muy eficientemente —así que podrías recibir errores 404/500 al editar publicaciones, pero al menos tus visitantes no los experimentarán (Cloudflare también puede servir páginas estáticas incluso si DreamHost devuelve un 404 o un 500).

Además, gracias a este artículo, descubrí que FastCGI usa más RAM que el CGI 'normal'. Y dado que PHP 5.3 es mejor gestionando la RAM (recolección de basura más agresiva, menos fugas de memoria), experimentalmente cambié a PHP 5.3 CGI (no FastCGI) sin Optimización de Velocidad de Página ni Seguridad Web Extra, confiando en W3 Total Cache + Cloudflare para acelerar el sitio. Ahora el backoffice es más lento (¡mayor consumo de CPU!), pero al menos no veo errores 404/500 (¡hasta ahora!).

Todavía no estoy satisfecho con la combinación, así que definitivamente seguiré ajustando la configuración de DreamHost con la esperanza de reducir aún más el consumo de RAM y obtener un rendimiento adecuado. Como dijo @dgw, yo también uso muchos plugins —porque requiero su funcionalidad. No todos los que alojan WP con DreamHost tienen necesidades simples de blogging; cuanto más complejo es el sitio, más funcionalidad requerirá... y esa es la belleza de WordPress, solo necesitas usar los plugins que realmente necesitas y mantener la instalación principal de WP simple si estás satisfecho con pocas necesidades. Sin embargo, los plugins no son necesariamente "malos" o tan pesados para el sitio; pero es cierto que algunos pueden consumir mucha RAM...

Se necesita más información:

1) ¿Por qué tantos plugins?

2) ¿Qué sistema operativo utiliza tu proveedor de hosting?

3) ¿Qué servidor web estás utilizando?

4) ¿Tienes acceso a los registros (logs) del servidor HTTP, específicamente los registros de errores?

5) ¿Qué dicen los registros de errores en los períodos de tiempo relacionados con estos problemas?

(Ahora bien, siendo honestos, si estamos generalizando para el "usuario promedio de WordPress que podría tener esta misma pregunta", podríamos comenzar por dirigir a dicho usuario a responder al menos estas 5 preguntas...)