Ir al contenido principal

[phpMyAdmin] El almacenamiento de configuración phpMyAdmin no está completamente configurado...

Estaba trabajando en la página de Wordpress para mi cliente, en mi instalación local (localhost) y cuando se me ocurre actualizar un par de plugins de WP, todo se cae. Wordpress me da unos avisos horribles de que el usuario de base de datos de WP no tiene el privilegio para alterar la BD... Me sugiere reparar las tablas. Y cuando voy a phpMyAdmin (pMA), el administrador de la BD, éste me sale con el mensaje:

El almacenamiento de configuración phpMyAdmin no está completamente configurado, algunas funcionalidades extendidas fueron deshabilitadas. Averigüe por qué.

Le doy click al link de "Averigüe por qué" y me muestra un nuevo mensaje, que me informa que la "Configuración de pma ... no recibió el OK".

El primer mensaje me apareció en la pantalla de inicio de phpMyAdmin. 

Pero yo primero lo vi (no exactamente el mismo) en la pestaña de Operaciones de la BD de WP... y sucesivamente en la pestaña de Operaciones de todas las BD. En este caso, me ofrecía crear las tablas de la base de phpMyAdmin en la base en curso, mientras que en la página de inicio, me ofrecía crear la base de phpMyAdmin desde cero. 

Como entré en mini-pánico, al principio le dí a Crear las Tablas en la BD en curso, y así vi aparecer en la BD de WP las tablas de phpMyAdmin (todas llevan el prefijo "pma__"), momento tras el cual las borré todas de allí. Acto seguido busqué info por internet, y aunque no me dieron muchas luces, volví a pMA y entré a la BD de phpMyAdmin para crear sus tablas. Allí me encontré con que las tablas ya existían, pero estaban vacías (salvo una). Pensé que por ahí iba el error. Pero no.

Incluso le concedí todos los permisos al usuario de BD WP, para ver si con eso se resolvía al menos el problema por parte de WP, pero tampoco funcionó.

Volviendo a pMA, y tras leer algunas respuestas en internet, resolví revisar el archivo config.inc.php de la instalación de pMA (en mi caso, ubicado en C:\xampp\phpMyAdmin\). Pero todos los datos estaban correctamente ingresados.

Revisando la documentación sugerida por pMA, me topé con un par de líneas que me dieron ciertas luces. Si el usuario pma, el definido en config.inc.php para administrar la BD de phpMyAdmin, no existía en el servidor, tal vez por ahí podría encontrar la solución.

Entonces se me ocurrió revisar en pMA los Privilegios de la BD de phpMyAdmin. Y ahí me encontré con que no estaba asociado el usuario pma, definido en la configuración. Este usuario existía, pero a nivel servidor solamente. Entonces ingresé a editar sus privilegios, de modo de darle los correspondientes sobre la BD de phpMyAdmin. Et voilà!

GRANT SELECT, INSERT, UPDATE, DELETE ON `<pma_db>`.* TO 'pma'@'localhost';

(Yo reemplacé el <pma_db> por el nombre de la BD de phpMyAdmin en mi localhost). Cabe destacar como último punto importante, que tal vez sea necesario reiniciar tanto Apache como el servidor de BD para ver reflejados los cambios.

Eso, espero que les ayude si es que tienen el mismo problema, y así eviten tener que editar demasiadas cosas en su instalación de pMA, como sugieren en los sitios que leí.

Fuentes:

Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

[tsql] Error: La instrucción INSERT EXEC no se puede anidar

Holas a todos. Mientras programaba un procedimiento almacenado, intenté obtener los datos de otro procedimiento, como lo he venido haciendo desde que descubrí tamaña maravilla de la programación sql. Pero hoy me topé con este extraño error: La instrucción INSERT EXEC no se puede anidar . Tras investigar por algunos lados, di con la respuesta: no se puede almacenar en una tabla temporal de procedimiento almacenado, el resultado de otro procedimiento que también esté realizando una inserción de este tipo. Esto es algo como tener: CREATE PROCEDURE miProcedimiento AS  INSERT INTO #tablita EXEC otroProcedimiento;  SELECT * FROM #tablita; END; CREATE PROCEDURE nuevoProcedimiento AS  INSERT INTO #tabla1 EXEC miProcedimiento; END; Esto significará que si ejecuto: EXEC nuevoProcedimiento; ...SQL me arrojará el error antes mencionado. La solución al problema es no llamar a un procedimiento que esté llamando a otro ya en su interior. En algunos lados leí que transf
2 comentarios
Leer más

[mysql] Pasar array a parámetro de procedimiento almacenado (Mysql)

Me tocó hacer una consulta que retornaba una lista de items relacionados con una lista de usuarios que podían o no tener registros en común (vale decir, tabla de quiebre). La lista debía retornar siempre la lista de items, independiente de si había usuarios por los cuales consultar y/o si los usuarios tenían relación con ellos, pero debía mostrarme el status de los usuarios por cada item, de haberlos, esto es, una lista de nombres con una columna que podía estar vacía o no. Para el caso de tener que consultar los items relacionados con usuarios, al hacer la consulta utilizando un LEFT JOIN, me daba resultados si los usuarios tenían relación con los ítems, pero no si los usuarios no tenían items asociados pues, obviamente, al no estar relacionados, la consulta retorna vacío. Por ello, la solución era hacer la consulta de los items primero, y luego por cada item preguntar el status del usuario por cada uno. Para ello, tenía dos alternativas: hacerlo por programación o hacerlo por bas
11 comentarios
Leer más

[php] NuSOAP HTTP Error: socket read of headers timed out

Holas a todos. Este es para comentar un problema que he tenido al trabajar un servicio web montado en PHP con la clase NuSOAP. El problema surgió cuando intenté llamar al servicio web desde el otro servidor, pero se caía a los exactos 30 segundos de ejecución, mostrando el mensaje que titula este registro: HTTP Error: socket read of headers timed out Sabía que el problema era el timeout, pero ¿el timeout de qué? En los servidores y páginas web hay timeouts por todos lados: el de la Conexión a internet o la red, el del Servidor (hardware), el del Servidor Web en sí (Apache, mi caso), el de PHP (mi caso)... Pero nunca se me habría ocurrido que las Aplicaciones o frameworks también pudieran tener :o Por eso, tras buscar por la red la solución a mi problema, la respuesta vino precisamente de alguien que señaló sencillamente que había que modificar el timeout de la clase NuSOAP. Y dicho y hecho, eso solucionó el problema. Si están usando en su servidor y/o cliente la clase NuSOAP, y d
Publicar un comentario
Leer más