Reemplazar editor TinyMCE por Quill en descripciones

jaimeiberia

Hola a todos,

Estoy teniendo un problema recurrente con el editor TinyMCE por defecto en las descripciones de productos. Cuando intento añadir HTML personalizado, como <iframe> de YouTube o <div> con estilos responsive y clases específicas para adaptabilidad, TinyMCE los elimina o los modifica agresivamente al guardar. Esto me obliga a usar solo texto plano o a reintroducir el código cada vez, lo cual es inviable.

He estado investigando y me gustaría reemplazarlo por Quill, que es mucho más moderno y flexible, y espero que respete mejor el HTML que le doy. Intenté anular el comportamiento de TinyMCE en AdminProductsController para que no se cargue, pero parece que sigue ahí o no sé cómo inyectar Quill correctamente.

Aquí tenéis un fragmento de mi intento en el AdminProductsController para intentar deshabilitar el editor por defecto y asignar una clase para Quill:

// En override/controllers/admin/AdminProductsController.php
class AdminProductsController extends AdminProductsControllerCore
{
    public function __construct()
    {
        parent::__construct();
        // Intentando deshabilitar TinyMCE para las descripciones
        foreach ($this->fields_form as &$fieldset) {
            foreach ($fieldset['form']['input'] as &$input) {
                if (in_array($input['name'], ['description_short', 'description'])) {

Con esto, autoload_rte = false hace que el textarea no se inicialice como TinyMCE, pero el contenido sigue siendo purificado al guardar. ¿Alguien ha logrado integrar un editor diferente o detener la purificación de HTML para campos específicos?

lucas_tech

Hola @jaimeiberia,

Entiendo perfectamente tu frustración con TinyMCE y la purificación de HTML. Es un dolor de cabeza común en PrestaShop. Tu intento de usar autoload_rte = false en AdminProductsController es un buen comienzo para evitar que el HelperForm inicie TinyMCE en esos campos específicos. Sin embargo, como mencionas, esto no detiene la purificación de HTML, que es una capa de seguridad de PrestaShop al guardar los datos.

El problema de fondo no es solo el editor, sino también cómo PrestaShop maneja la limpieza del HTML a través de Tools::purifyHTML() o Validate::isCleanHtml() cuando se guarda el objeto Product. Incluso si inyectas Quill, si la validación del producto sigue limpiando el HTML, perderás tus iframes.

¿En qué versión exacta de PrestaShop estás trabajando? Eso nos ayudaría a saber qué clases y métodos específicos están involucrados en la purificación.

Milo

Hola @jaimeiberia y @lucas_tech,

Tenéis toda la razón en que es un problema complejo, porque implica dos frentes: reemplazar el editor y evitar la purificación de HTML. La autoload_rte = false en AdminProductsController solo deshabilita la inicialización específica de TinyMCE para esos textarea. Sin embargo, TinyMCE se carga globalmente a través de AdminController::addJqueryPlugin('tinymce').

Para una solución completa, necesitaríamos:

Deshabilitar la carga global de TinyMCE: Esto se puede hacer anulando el método initHeader() de AdminController para quitar la llamada a addJqueryPlugin('tinymce').
Inyectar los assets de Quill: Añadir los archivos CSS y JS de Quill (y un script de inicialización) en el AdminProductsController modificado, usando addCSS() y addJS().
Evitar la purificación de HTML: Este es el punto más crítico. La limpieza se produce en la validación del objeto Product a través de Tools::purifyHTML() y Validate::isCleanHtml(). Para evitar que se elimine tu HTML, necesitamos anular la clase Product y modificar su método validateFields().

Aquí te dejo un ejemplo de cómo podrías modificar la clase Product para que no purifique los campos de descripción. Esto es más delicado y debes asegurarte de que el HTML que Quill genera sea seguro para evitar vulnerabilidades XSS:

// En override/classes/Product.php
class Product extends ProductCore
{
    /**
     * @see ObjectModel::validateFields()
     */
    public function validateFields($die = true, $error_return = false)
    {
        // Guardar temporalmente las descripciones para evitar que parent::validateFields las purifique
        $originalDescription = $this->description;

Explicación del snippet:

Líneas 9-10: Guardamos el contenido original de description y description_short que ha enviado Quill y que queremos preservar.
Líneas 13-14: Asignamos cadenas vacías a estos campos antes de llamar al parent::validateFields(). Esto engaña al validador de ObjectModel para que no aplique Tools::purifyHTML() a estos campos específicos, ya que no tienen contenido en ese momento.
Línea 17: Llamamos al método validateFields() de la clase padre. Este método procesará y purificará todos los demás campos del producto, pero ignorará las descripciones porque están vacías.
Líneas 20-21: Restauramos los contenidos originales de las descripciones que guardamos al principio. De esta manera, el HTML de Quill no se pierde.

Una vez hecho esto, el AdminProductsController que tú ya tenías con autoload_rte = false y class = 'custom-quill-editor' es correcto. Solo tendrías que añadir en ese mismo AdminProductsController (en el constructor o en initContent()) la carga de los archivos CSS y JS de Quill y un pequeño script JS para inicializar Quill en todos los textarea con la clase custom-quill-editor.

Recuerda borrar la caché de PrestaShop y recompilar los overrides después de hacer estos cambios.

jaimeiberia

¡Increíble @Milo! ¡Muchísimas gracias por la explicación tan detallada! No había caído en la capa de Product::validateFields() y la forma en que PrestaShop purifica el HTML allí. Tiene todo el sentido.

He implementado el override en override/classes/Product.php tal como indicaste, y también he ajustado mi AdminProductsController para cargar los assets de Quill y su script de inicialización.

¡Y funciona! Ahora Quill se carga correctamente y, lo más importante, mi HTML con iframes y estilos personalizados se guarda sin ser eliminado. Esto me ahorra una cantidad de tiempo brutal.

De nuevo, mil gracias por tu ayuda, @Milo. ¡Eres un crack!