Supongo que hay muchas situaciones que pueden provocar esta situación. Yo al menos he leído unas cuantas. Por ejemplo, aquí se trata algo parecido:

Lost my text formatting tools.
Visual Editor/TinyMCE problems

Os intentaré contar como me he encontrado con este problema y como lo solucioné.

Lo cierto es que estas cosas no ocurren porque sí.

En mi caso, trataba de mejorar la seguridad de un servidor Apache en el cual había creado un portal Web con WordPress, siguiendo las recomendaciones que he encontrado en otros artículos (como por ejemplo en esta artículo de anieto2k sobre Las páginas blancas de la seguridad en WordPress).

Concretamente el problema se produjo al incluir en el directorio “wp-includes” de la instalación de wordpress, un archivo .htaccess con el siguiente contenido:

Order Allow,Deny
  Deny from all
  <Files ~ ".(css|jpe?g|png|gif|js)$">
    Allow from all
  </Files>

Con estas líneas, lo que trato es de prohibir el acceso a cualquier fichero que no sea una imagen, una hoja de estilo o un archivo de javascript.

A partir de ese momento el editor visual de wordpress dejó de responder (en otras palabras, no podía acceder a la pestaña visual del editor). Utilizando la “Consola de errores” de Mozilla Firefox pude comprobar que se estaba generando un error de javascript con el mensaje “tinymce is not defined“, y en el archivo que guarda los log de error en el servidor, se estaba produciendo un error de tipo “client denied by server configuration” en el acceso a dos archivos: wp-tinymce.php y editimage.html

La solución fue modificar el archivo .htaccess como sigue:

Order Allow,Deny
  Deny from all
  <Files ~ ".(css|jpe?g|png|gif|js)$">
    Allow from all
  </Files>
  <Files wp-tinymce.php>
    Allow from all
  </Files>
  <Files editimage.html>
    Allow from all
  </Files>

Con las modificaciones estoy permitiendo el acceso “desde el exterior” a los archivos wp-tinymce.php (en el directorio wp-includes/js/tinymce/) y editimage.html (en el directorio wp-includes/js/tinymce/plugins/wpeditimage/).

No he tenido tiempo de comprobar la razón del error, pero intuyo que desde el entorno de edición de wordpress se trata de lanzar una llamada de tipo AJAX al archivo wp-tinymce.php, que interviene en el funcionamiento de la barra de herramientas del editor. Respecto al archivo editimage.html creo que el error se ha producido al intentar utilizar el editor de imágenes de WordPress, por lo que supongo que tiene que ver el lanzamiento del interfaz de usuario de dicho editor (al intentar abrir la ventana que permite editar las imágenes desde el entorno de edición de wordpress).

Dejo una pregunta en el aire, si alguien se anima a participar. ¿Qué implicaciones en la seguridad tiene permitir el acceso a estos archivos? ¡Estoy en ello!

Como muestra la imagen anterior, al acceder al menú de módulos …, no muestra la lista de módulos. Concretamente, el sistema (el backend de Prestashop) interrumpe su ejecución antes de enviar la lista al navegador Web, interrumpiendo también la carga del resto del entorno (el pie de página, etc.).

He tenido este problema al actualizar una tienda desde la versión 1.4.5.1 a la versión 1.4.7.2, y parece ser que no he sido el único.

En mi caso, creo que el problema estaba en un excesivo consumo de memoria (la versión 1.4.7.2 incluye 63 módulos). Cuando accedemos a este apartado del backend, prestashop procesa todos los módulos existentes en el directorio “modules” de nuestro servidor (estén instalados o no), para elaborar la lista a la que accedemos para instalar/desinstalar, activar/desactivar, configurar, etc., los módulos de nuestra tienda.

En varios artículos recomiendan añadir la instrucción “ini_set” en el archivo /config/config.inc.php, para aumentar la memoria que se pone a disposición de php para ejecutar nuestros procesos. Sin embargo en mi caso no ha tenido efecto. He probado con varios valores, e incluso con -1, como he leído en prestashop bug tracker (aquí: PSCFI-1126).

Mi solución ha consistido en eliminar (a través de ftp) todos los módulos del directorio “modules”, y luego subir de nuevo únicamente los que tenía instalados y activos antes de la actualización, además del archivo index.php.
Antes de realizar esta operación hice una lista de los módulos que tenía activos (aunque se puede saber comprobando el campo “active” de la tabla XXX_XXmodule, o como se llame, dependiendo del sufijo de vuestras tablas).

Espero que le sea de utilidad a alguien!