WordPress con phpMyAdmin - 404 en todas partes

Question

He intentado hacer varios cambios en un tema personalizado de WordPress que presenta una revisión completa del Tablero. Sigo encontrando pequeños problemas con el tema original que necesito corregir (no verificando correctamente las publicaciones duplicadas cuando importas nuevas, los metadatos no se almacenan correctamente, las publicaciones no se ordenan en sus categorías apropiadas, etc.)

Como he estado trabajando con esto, he tenido que mirar y modificar la base de datos en innumerables ocasiones para ver lo que el tema está haciendo en la base de datos o arreglar cosas que arruinaron. Desafortunadamente no pude instalar phpMyAdmin, así que he estado haciendo cambios escribiendo directamente SQL e insertándolo en el tema en los lugares apropiados, y luego tengo el script die() para poder ver el resultado de mi SQL.

De repente me di cuenta de que podía encontrar un complemento que integra la funcionalidad de phpMyAdmin en WordPress. Así que instalé wp-phpMyAdmin.

Todo parece ir bien hasta que intente realmente DO cualquier cosa. Puedo ver las tablas, ver las filas y mirar todo. Pero cuando trato de editar una fila o borrar una fila, me redireccionan a un error 404, diciendo que cualquiera de las partes de phpMyAdmin a las que estaba accediendo (por ejemplo, tbl_row_action.php) no existe. Si voy directamente a estas páginas sin enviar el formulario para editar o eliminar una fila, funcionan muy bien y recibo un mensaje de error de que mi consulta SQL estaba en blanco.

¿Alguien más ha experimentado esto? Realmente no puedo entender exactamente por qué o dónde está enviando un 404. Es absolutamente ridículo.

EDITAR - Un poco más de información:

he aprendido que sólosale un error 404 cuando phpMyAdmin llama sql.php con el parámetro establecido sql_query

EDITAR (de nuevo) - Una nueva actualización:

Solo obtengo el error 404 cuando sql_query contiene una consulta válida. Mirando a través de sql.php (no he gastado demasiado tiempo buscándome), me doy cuenta de que parece analizar la consulta y determinar si está SELECT ing, DROP ing, DELETE ing, etc. para que puedan consultar a su usuario permisos Puede estar relacionado con este código de análisis.

Las siguientes consultas no me dieron un 404:

test 
SELECT test 
SELECT test FROM test 
SELECT test FROM post_meta 
DELETE 
DROP 
DROP test 

El siguiente me dio un 404:

SELECT * FROM test 
SELECT * FROM post_meta 
DELETE FROM 
DELETE FROM test 
DELETE FROM post_meta 
DROP TABLE 
DROP TABLE test 

más ediciones -

Así que en la parte superior de SQL. php Puse esta línea de código:

die("Test"); 

No se apaga cuando hago las consultas incorrectas enumeradas anteriormente. Va directamente al mensaje 404. Es evidente que esto es algo que ver con el script de redireccionamiento de WordPress y no con phpMyAdmin

edición final -

he hecho mucho más investigación y ha grep'ing a los diablos de WordPress.

Sospecho que estoy teniendo este problema como resultado de alguna nueva característica de seguridad de WordPress. Las versiones anteriores de WordPress aparentemente se usaban para permitir que SQL ingresara en las URL, lo que representaba un ENORME riesgo de seguridad. Como resultado, es comprensible que no permitan que el SQL pase a través de las URL ahora. Justo antes de la plantilla, el valor de is_404() se establece en verdadero. Se trata de ser ajustado dentro de WP::parse_request() (que es llamada por WP::main() que es llamada por wp() que se llama dentro de wp-blog-header.php)

cualquier momento que haya una consulta SQL sospecha en cualquier lugar en el URI solicitado, me echan a una página 404. Me gustaría cambiar este comportamiento al hacer tan pocas modificaciones al núcleo de WordPress como sea posible. Necesito a alguien que sea realmente bueno con WordPress para ayudarme aquí. Supongo que existe una respuesta que involucra la variable $ wp_rewrite, que contiene una multitud de reglas de reescritura de URL.

PROBLEMA finalmente descubrió -

Para todos los interesados ​​que se encuentra este post o lo seguía o simplemente tenían problemas similares, por fin localicé la fuente de los errores 404. No miente con WordPress en absoluto. El problema recayó en mod_security, un módulo de Apache que evita cualquier solicitud que parezca sospechosa (incluidos aquellos con SQL en el URI de solicitud)

Recuerde siempre establecer correctamente la configuración de mod_security.

Answer 1

WordPress no debe interferir con phpMyAdmin, ya que el complemento lo carga en un iframe aislado.

Como uno de sus especificaciones para el proyecto que quiere WordPress SOLO instalado en su servidor ...

El plugin está, sin embargo, todavía phpMyAdmin (aunque 'envuelto' en la interfaz de usuario de WordPress) En otras palabras, que ya he instalado;)

... para evitar la molestia de actualizar y mantener otro software ...

'software' puede ser un término peligroso cuando se habla de web-apps - eso no quiere decir que no lo use en absoluto, pero para algunos puede evocar pensamientos de pantallas azules y los errores de tiempo de ejecución;)

en otras palabras, sólo destacar que la PMA es simplemente una colección de archivos en el servidor; no tiene una base de datos de es propio, es efectivamente sin estado, y la eliminación es tan simple como RMD /phpmyadmin.

...que quiere ser capaz de hacer todos los cambios administrativos necesarios desde el panel de WordPress

A pesar de los puntos que ya he hecho, si es absolutamente esencial que haya acceso a la administración de bases de datos en el cuadro de mandos, estoy a punto de escribir una alternativa rápida que usa phpMiniAdmin en su lugar (¡así es como me tropecé con esta pregunta de forma extraña!), y me gustaría compartirla para que la pruebes.

Answer 2

Como señaló @molnarm en los comentarios, ¿por qué no acaba de eliminar phpMyAdmin y conectarse a MySQL a través de SSH, usando algo como MySQL Workbench o Sequel Pro.

Tendría una forma mucho más fácil y rápida de interactuar con MySQL y podría eliminar la pesadilla que es phpMyAdmin.