Cómo usar el Editor Clásico en WordPress: Instalación, Configuración y Cuándo Tiene Sentido Usarlo

El WordPress Classic Editor es un editor de contenido WYSIWYG basado en TinyMCE que precede al sistema de bloques Gutenberg introducido en WordPress 5.0. Presenta un lienzo de edición único y lineal — visualmente similar a Microsoft Word — donde el texto, los medios y el HTML coexisten en un campo continuo en lugar de bloques discretos y apilables. Para los usuarios que necesitan instalarlo hoy, la respuesta breve es: instala el plugin Classic Editor oficial desde el repositorio de plugins de WordPress, actívalo y configura el editor predeterminado en Ajustes > Escritura.

Esa respuesta de dos oraciones cubre la consulta principal. El resto de esta guía cubre las diferencias arquitectónicas entre los dos editores, las razones técnicas legítimas para elegir uno sobre el otro, casos extremos de configuración y los escenarios donde forzar el Classic Editor en realidad crea más problemas de los que resuelve.

Classic Editor vs. Editor de Bloques Gutenberg: Una Comparación Técnica

Antes de tocar cualquier configuración, vale la pena entender entre qué estás cambiando realmente. La decisión no es puramente cosmética.

La diferencia operacionalmente más significativa es el almacenamiento de contenido. Classic Editor guarda HTML limpio. Gutenberg envuelve cada unidad de contenido en anotaciones de comentarios HTML que actúan como delimitadores de bloques. Si alguna vez migras contenido entre sistemas — a un CMS headless, un generador de sitios estáticos o una plataforma que no sea WordPress — el resultado del Classic Editor es mucho más fácil de analizar y portar. La gramática de bloques de Gutenberg es propietaria del analizador de WordPress.

Por Qué los Desarrolladores y Propietarios de Sitios Siguen Eligiendo Classic Editor

Compatibilidad con Plugins y Temas Heredados

Muchos plugins comerciales — particularmente constructores de formularios más antiguos, extensiones de comercio electrónico y plugins de tipos de publicaciones personalizadas — registran meta boxes que inyectan campos directamente en la pantalla de edición de publicaciones. En Gutenberg, estos meta boxes quedan relegados a un panel lateral plegable renderizado dentro de un shim de compatibilidad en iframe. Este shim no siempre se comporta correctamente: surgen conflictos de JavaScript, la lógica condicional se rompe y algunos frameworks de UI de meta boxes (los diálogos de jQuery UI, por ejemplo) no se inicializan correctamente dentro del contexto de documento anidado.

Si tu sitio depende de plugins que usan add_meta_box() con interfaces de usuario complejas dependientes de JavaScript, Classic Editor elimina toda esta clase de problemas.

Restricciones de REST API

El editor de Gutenberg realiza solicitudes continuas en segundo plano a la REST API de WordPress — para obtener patrones de bloques, guardar borradores automáticamente, recuperar el estado de bloqueo de publicaciones y validar permisos de usuario. En entornos de servidor reforzados donde la REST API está intencionalmente restringida (mediante add_filter('rest_authentication_errors', ...) o reglas a nivel de servidor que bloquean /wp-json/), Gutenberg fallará parcial o completamente al cargar. Classic Editor no tiene tal dependencia y funcionará normalmente bajo estas restricciones.

Control de Editor por Roles en Multisitio

En instalaciones de WordPress Multisitio, los administradores de red a veces necesitan imponer una experiencia de edición consistente en todos los subsitios — particularmente cuando hay editores no técnicos involucrados. El plugin Classic Editor admite una opción Settings > Writing para no permitir el cambio de editor por usuario, bloqueando a todos los usuarios en Classic Editor independientemente de sus preferencias individuales. Gutenberg no ofrece ningún mecanismo equivalente de aplicación a nivel de red sin código personalizado.

Velocidad de Flujo de Trabajo para Contenido con Mucho Texto

Para editores que producen grandes volúmenes de contenido de texto — artículos de noticias, documentación, escritos legales — el modelo de lienzo único del Classic Editor es genuinamente más rápido. No es necesario insertar un nuevo bloque, seleccionar un tipo de bloque ni navegar entre paneles de configuración de bloques. Presionas Enter y sigues escribiendo. Para los editores que trabajan con el teclado y usan atajos de la pestaña HTML, esto importa.

Cómo Instalar el Plugin Classic Editor

El Classic Editor no viene incluido con el núcleo de WordPress. Es mantenido como un plugin oficial por el equipo de Colaboradores de WordPress y está disponible en el repositorio de plugins de WordPress.org.

Método 1: Instalar desde el Panel de WordPress

1. Inicia sesión en tu panel de administración de WordPress (/wp-admin).
2. Ve a Plugins > Añadir nuevo plugin.
3. En el campo de búsqueda, escribe Classic Editor.
4. Localiza el plugin creado por WordPress Contributors — verifica el autor, ya que existen plugins imitadores con nombres similares.
5. Haz clic en Instalar ahora y luego en Activar.

Método 2: Instalar mediante WP-CLI

Si gestionas WordPress desde la línea de comandos — lo cual es práctica estándar en cualquier entorno de Hosting VPS — WP-CLI es significativamente más rápido que la interfaz del panel:

wp plugin install classic-editor --activate

Para instalarlo en toda la red en una instalación Multisitio:

wp plugin install classic-editor --activate-network

Método 3: Subida Manual

Descarga el ZIP del plugin desde wordpress.org/plugins/classic-editor, luego súbelo mediante Plugins > Añadir nuevo plugin > Subir plugin, o extráelo directamente en tu servidor:

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

Tras la extracción, actívalo mediante WP-CLI o el panel.

Configuración de los Ajustes del Classic Editor

Una vez activado, el plugin expone dos opciones de configuración en Ajustes > Escritura.

Editor Predeterminado para Todos los Usuarios

La primera opción establece el valor predeterminado para todo el sitio. Puedes elegir entre Classic Editor y Editor de Bloques. Configurarlo en Classic Editor significa que cada nueva publicación y página se abre en TinyMCE de forma predeterminada.

Permitir a los Usuarios Cambiar de Editor

La segunda opción controla si los usuarios individuales pueden anular el valor predeterminado del sitio por publicación. Cuando está habilitada, al pasar el cursor sobre una publicación en la lista Entradas > Todas las entradas se muestran dos enlaces de acción: Editar (abre con el editor predeterminado del sitio) y Editar (Classic Editor) o Editar (Editor de Bloques) según el valor predeterminado actual.

Configuración recomendada para la mayoría de los sitios heredados:

• Editor predeterminado: Classic Editor
• Permitir a los usuarios cambiar: No

Esto evita que los editores abran accidentalmente contenido en Gutenberg e inyecten inadvertidamente comentarios de gramática de bloques en publicaciones que fueron creadas en Classic Editor — una mezcla que puede causar anomalías de renderizado en algunos temas.

Uso de la Interfaz del Classic Editor

La Pestaña Visual (Modo WYSIWYG)

La pestaña Visual renderiza tu contenido a través de la vista previa basada en iframe de TinyMCE. La barra de herramientas proporciona:

• Formato de texto: Negrita (Ctrl+B), Cursiva (Ctrl+I), Tachado, Subrayado
• Estilos de párrafo: Encabezado 1 al Encabezado 6, Preformateado, Cita en bloque
• Listas: Ordenadas y desordenadas, con controles de sangría y sangría inversa
• Enlaces: Insertar/editar hipervínculos con atributos de destino y título
• Inserción de medios: Abre la Biblioteca de Medios de WordPress para imágenes, vídeo, audio y documentos
• Pegar desde Word: Elimina el marcado HTML propietario de Microsoft Word al pegar
• Modo de escritura sin distracciones: Alternancia a pantalla completa que oculta toda la interfaz de administración

La barra de herramientas tiene dos filas. Si solo ves una fila, haz clic en el botón Alternar barra de herramientas (el último icono de la primera fila) para mostrar la segunda fila, que incluye el selector de estilo de párrafo, color de texto, mapa de caracteres y deshacer/rehacer.

La Pestaña Texto (Modo HTML Sin Formato)

La pestaña Texto expone el HTML sin formato almacenado en post_content. No es un editor de código completo — carece de resaltado de sintaxis y numeración de líneas — pero te da acceso directo al marcado. Escenarios útiles:

• Insertar incrustaciones <iframe> sin formato que TinyMCE eliminaría o escaparía
• Añadir atributos HTML personalizados que la interfaz de usuario de la pestaña Visual no expone
• Depurar problemas de renderizado causados por la limpieza automática de etiquetas de TinyMCE

Comportamiento crítico a entender: TinyMCE realiza una sanitización HTML cuando cambias de la pestaña Texto a la pestaña Visual. Cerrará etiquetas no cerradas, eliminará ciertos elementos (como <script> en algunas configuraciones) y normalizará los espacios en blanco. Si escribes HTML sin formato en la pestaña Texto, verifica siempre que sobreviva un viaje de ida y vuelta a Visual antes de publicar.

Los Meta Boxes de Extracto, Campos Personalizados y Discusión

Debajo del lienzo principal del editor, Classic Editor muestra el conjunto completo de meta boxes nativos de WordPress en su diseño original:

• Extracto: Resumen en texto plano utilizado por temas y plugins SEO para meta descripciones
• Campos personalizados: Pares clave-valor almacenados en wp_postmeta — accesibles directamente sin cambiar a un panel lateral
• Discusión: Configuración de comentarios y trackbacks por publicación
• Slug: Campo de slug de URL editable (también en el cuadro Publicar)
• Autor: Reasignar la autoría de la publicación sin navegar fuera

Estos meta boxes siempre son visibles y de ancho completo en Classic Editor. En Gutenberg, están ocultos en la barra lateral o renderizados en el iframe de compatibilidad — una diferencia de UX significativa para los flujos de trabajo que dependen en gran medida de los campos personalizados.

Cambiar Entre Editores por Publicación

Si habilitaste la opción “Permitir a los usuarios cambiar”, el selector de editor por publicación funciona de la siguiente manera:

Desde la lista de publicaciones:

1. Ve a Entradas > Todas las entradas.
2. Pasa el cursor sobre el título de la publicación.
3. Haz clic en Editar (Classic Editor) o Editar (Editor de Bloques) según sea necesario.

Desde dentro del editor:

En Gutenberg, aparece un enlace que dice Cambiar al Classic Editor en el menú de tres puntos (arriba a la derecha). En Classic Editor, aparece un enlace que dice Cambiar al Editor de Bloques cerca de la parte superior de la pantalla.

Advertencia: Cambiar una publicación creada en Gutenberg al Classic Editor — y luego guardarla — preservará las anotaciones de comentarios de gramática de bloques en el HTML sin formato. Estos comentarios son inofensivos para el renderizado en el front-end, pero aparecerán como texto literal en la pestaña Texto del Classic Editor, lo que puede ser confuso. Volver a Gutenberg los analizará correctamente. El escenario inverso (contenido de Classic Editor abierto en Gutenberg) es limpio, ya que Gutenberg envuelve el HTML no reconocido en un bloque Clásico automáticamente.

Deshabilitar Classic Editor Sin el Plugin

Si deseas forzar Gutenberg y evitar que se use Classic Editor — o si deseas deshabilitar Gutenberg sin instalar un plugin — WordPress proporciona un hook de filtro:

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

Esto logra el mismo efecto que el plugin Classic Editor para la edición de publicaciones, pero no afecta al Editor del Sitio (Edición Completa del Sitio). Para deshabilitar Gutenberg completamente incluyendo FSE:

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

Este enfoque es preferible en entornos donde la instalación de plugins adicionales está restringida por política, o donde deseas que la lógica de deshabilitación esté controlada por versiones en tu tema o plugin en lugar de depender del estado de activación de un plugin de terceros.

Classic Editor y Entornos de Hosting de WordPress

El plugin Classic Editor en sí es ligero y no impone requisitos significativos del lado del servidor. Sin embargo, el contexto más amplio de tu entorno de hosting afecta la experiencia de edición de maneras que vale la pena señalar.

En planes de hosting compartido, el panel de administración de WordPress puede sentirse lento porque la ejecución de PHP y las consultas de base de datos compiten con otros inquilinos en el mismo servidor. Classic Editor es notablemente más ligero que Gutenberg en este contexto — menos llamadas a la REST API, sin sobrecarga de renderizado de React y una carga útil de JavaScript más pequeña significan cargas de página más rápidas en el administrador. Si estás en un plan de Hosting Web Compartido y encuentras el editor de bloques lento, Classic Editor es una optimización práctica.

En un VPS con cPanel, tienes control total sobre los límites de memoria PHP, la configuración de OPcache y el almacenamiento en caché de consultas MySQL. En este entorno, ambos editores funcionan bien y la elección se convierte puramente en una preferencia de flujo de trabajo en lugar de una necesidad de rendimiento.

Para instalaciones de WordPress de alto tráfico en Servidores Dedicados, la elección del editor tiene esencialmente cero impacto en el rendimiento del front-end — la interfaz de edición solo la cargan los usuarios administradores autenticados, y el resultado HTML publicado es lo que importa para la velocidad de la página.

Errores Comunes y Casos Extremos

TinyMCE eliminando HTML válido: La configuración valid_elements y extended_valid_elements de TinyMCE controla qué etiquetas y atributos HTML están permitidos en el editor Visual. De forma predeterminada, elimina etiquetas como <article>, <section>, <figure> (en configuraciones más antiguas) y cualquier atributo de datos personalizado. Si tu contenido requiere estos, debes ampliar los elementos permitidos de TinyMCE mediante el filtro tiny_mce_before_init:

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Conflictos de guardado automático: Classic Editor usa la función JavaScript wp_autosave() más antigua, que envía solicitudes POST a wp-admin/post.php con action=autosave. Si tu servidor tiene una limitación de velocidad agresiva o una regla WAF que bloquea solicitudes POST repetidas a wp-admin, los guardados automáticos fallarán silenciosamente. Monitorea los registros de errores de tu servidor si se produce pérdida de contenido.

Classic Editor y temas de Edición Completa del Sitio (FSE): Si tu tema activo es un tema FSE (uno que declara "blockTemplates": true en theme.json), Classic Editor seguirá funcionando para el contenido de publicaciones y páginas, pero el Editor del Sitio (/wp-admin/site-editor.php) está completamente basado en Gutenberg y no se ve afectado por el plugin Classic Editor. No puedes usar Classic Editor para editar plantillas de temas FSE.

Comportamiento al desactivar el plugin: Desactivar el plugin Classic Editor no convierte tu contenido. Las publicaciones creadas en Classic Editor permanecen como HTML limpio. Las publicaciones creadas en Gutenberg conservan su gramática de bloques. Gutenberg analizará correctamente ambas. No hay riesgo de pérdida de datos al desactivar el plugin.

Matriz de Decisión: ¿Qué Editor Deberías Usar?

Usa Classic Editor si:

• Tu sitio usa plugins con interfaces de usuario de meta boxes complejas que se rompen en la capa de compatibilidad de Gutenberg
• Tu servidor restringe la REST API de WordPress
• Estás migrando contenido a una plataforma que no es WordPress y necesitas HTML limpio y portable
• Tu equipo editorial es grande, no técnico y está capacitado en el flujo de trabajo de Classic Editor
• Estás ejecutando WordPress en un entorno de hosting compartido con recursos limitados

Usa Gutenberg si:

• Estás construyendo nuevos sitios sin dependencias de plugins heredados
• Tu tema está basado en bloques o es compatible con FSE
• Necesitas bloques reutilizables, patrones de bloques o diseños complejos de múltiples columnas sin un constructor de páginas
• Estás construyendo bloques personalizados con register_block_type() para proyectos de clientes
• Deseas aprovechar el Editor del Sitio para la personalización completa del tema

Usa ambos (con cambio por usuario habilitado) si:

• Tienes un equipo mixto donde algunos editores prefieren Classic y otros prefieren Gutenberg
• Estás en un período de transición migrando un sitio heredado a una arquitectura basada en bloques
• Los diferentes tipos de publicaciones en tu sitio tienen diferentes requisitos de complejidad

Lista de Verificación Técnica Práctica

Antes de cambiar tu sitio de producción a Classic Editor, verifica lo siguiente:

• ] Confirma que la versión del plugin Classic Editor está actualizada (consulta [wordpress.org/plugins/classic-editor para la última versión)
• [ ] Prueba las interfaces de usuario de meta boxes de todos los plugins activos en Classic Editor en un entorno de pruebas antes de implementar en producción
• [ ] Revisa tus filtros tiny_mce_before_init si tienes configuraciones personalizadas de TinyMCE que puedan entrar en conflicto con los valores predeterminados del plugin
• [ ] Decide la política de “permitir cambio” y documéntala para tu equipo editorial
• [ ] Si usas WP-CLI, confirma que el plugin está activado con wp plugin list --status=active
• [ ] Verifica que tu tema no dependa de estilos de bloques específicos de Gutenberg (clases CSS wp-block-*) para el renderizado en el front-end
• [ ] Haz una copia de seguridad de tu base de datos antes de realizar cualquier cambio de editor en un sitio con contenido existente de Gutenberg
• [ ] Si estás en una red Multisitio, decide si activar en toda la red o por sitio y aplícalo mediante Settings > Writing a nivel de red

Complementa tu configuración de WordPress con un dominio correctamente asegurado asegurándote de que tus Certificados SSL sean válidos y se renueven automáticamente — el panel de administración de WordPress transmite cookies de autenticación que deben estar protegidas por HTTPS independientemente del editor que uses.

Para equipos que gestionan flujos de trabajo editoriales que incluyen notificaciones por correo electrónico, comunicaciones con autores o integraciones de boletines, una configuración dedicada de Hosting de Correo Electrónico garantiza que los correos electrónicos transaccionales de WordPress (restablecimientos de contraseña, notificaciones de comentarios, cambios de estado de publicaciones) se entreguen de manera confiable en lugar de enrutarse a través del sendmail predeterminado de un servidor compartido.

Preguntas Frecuentes

¿El plugin Classic Editor afecta el renderizado del front-end o el rendimiento del sitio?

No. El plugin Classic Editor solo modifica la interfaz de edición del lado del administrador. No tiene ningún impacto en cómo WordPress renderiza las páginas para los visitantes. El rendimiento del front-end está determinado por tu tema, la capa de caché y la configuración del servidor — no por qué editor se usó para escribir el contenido.

¿Cambiar de Gutenberg a Classic Editor corromperá mi contenido existente basado en bloques?

No. Gutenberg almacena las anotaciones de bloques como comentarios HTML dentro de post_content. Classic Editor mostrará este HTML sin formato en su pestaña Texto e intentará renderizarlo en la pestaña Visual. El contenido no se elimina ni se corrompe. Si guardas una publicación de Gutenberg en Classic Editor sin editarla, las anotaciones de bloques se conservan. Si editas y guardas, TinyMCE puede normalizar algunos espacios en blanco pero no eliminará las anotaciones de comentarios.

¿Puedo usar Classic Editor para algunos tipos de publicaciones y Gutenberg para otros?

Sí, pero no a través de la interfaz de configuración del plugin Classic Editor. Necesitas usar el filtro use_block_editor_for_post_type en el código:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

¿El plugin Classic Editor va a mantenerse permanentemente?

WordPress.org se ha comprometido a mantener el plugin Classic Editor con actualizaciones de seguridad y compatibilidad hasta al menos 2024, y continúa recibiendo actualizaciones más allá de ese compromiso. Sin embargo, no recibe nuevas funciones — está en modo de mantenimiento. Para nuevos proyectos a largo plazo, Gutenberg es la dirección estratégica del núcleo de WordPress.

¿Classic Editor funciona con WooCommerce?

Sí. El editor de productos de WooCommerce ha sido construido históricamente sobre los meta boxes de Classic Editor. Las versiones recientes de WooCommerce (8.x+) introdujeron un nuevo editor de productos basado en bloques, pero el formulario de producto heredado basado en Classic Editor sigue disponible y es el predeterminado para la mayoría de las instalaciones. El plugin Classic Editor no interfiere con las pantallas de edición de productos de WooCommerce.