Desde WordPress 5.0 y la salida del editor de bloques, el editor clásico ha estado ahí… pero ahora comienza la cuenta atrás para su despedida.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 22 al 28 de junio de 2026.

Ya se ha confirmado el primer paso concreto en la desaparición progresiva del bloque Clásico: a partir de WordPress 7.1, el bloque Clásico deja de aparecer en el insertor de bloques por defecto.

Esto no afecta a nada que ya tengas: el bloque sigue registrado, cualquier bloque Clásico existente sigue funcionando y siendo editable exactamente igual que antes, y el editor Clásico tradicional, ya sea a través del plugin Classic Editor o en tipos de contenido que no usan el editor de bloques, no se ve afectado en absoluto.

Lo único que cambia es que ya no podrás añadir un bloque Clásico nuevo desde el menú, la biblioteca de bloques o los comandos de barra inclinada.

La razón de fondo es de coherencia arquitectónica: el bloque Clásico es el único bloque de Core que no se comporta como un bloque, sino como HTML opaco renderizado a través de un editor TinyMCE incrustado, lo que obliga a tratarlo como caso especial en buena parte de las mejoras que se hacen al sistema de bloques.

Si necesitas seguir teniendo el bloque Clásico disponible, hay un filtro específico, que se puede activar globalmente o de forma condicional según el tipo de contenido, y también existe ya un pequeño plugin llamado Enable Classic Block que hace exactamente eso sin tocar código, ya enviado para su aprobación en el directorio de plugins.

El objetivo a más largo plazo, que se irá tratando en entradas futuras, es que el bloque Clásico sea completamente opcional y que TinyMCE solo se cargue cuando realmente se necesite, pero ese trabajo queda fuera del alcance de WordPress 7.1, dejando la tarea para WordPress 7.2 o 7.3.

Otra propuesta de fusión interesante para WordPress 7.1 detalla cómo se va a construir por debajo la función de Guías de Estilo. La propuesta es incorporar en el núcleo un nuevo tipo de contenido llamado Conocimiento, con su propio post type, pensado como una pieza genérica de almacenamiento para conocimiento del sitio dirigido tanto a autores humanos como a agentes de IA. La idea es que en lugar de que cada plugin de IA invente su propio sistema de almacenamiento, permisos y API REST, WordPress ofrezca una única base común, igual que ya hizo en su momento con plantillas y bloques.

Knowledge no es una función visible en sí misma, sino la base sobre la que se construye Guidelines, que sí tiene interfaz propia en Ajustes. El sistema define tres tipos de registro: guideline, un texto fuente de verdad sobre tono, voz o reglas de imagen que algo o alguien tiene que aplicar; memory, contexto duradero guardado explícitamente por el usuario, como preferencias o datos estables, siempre privado y propiedad de su autor; y note, texto de trabajo libre como notas adhesivas o borradores. Los plugins pueden registrar tipos adicionales propios, como un glosario de terminología. El acceso está bastante controlado: los registros nuevos son privados por defecto, ningún tipo de usuario salvo administrador puede gestionar los registros globales del sitio, y nada de esto se expone públicamente a través de consultas del front-end.

El equipo de Core es bastante explícito sobre lo que esto no es: no hay proveedor de IA, ni modelo, ni algoritmo de recuperación, ni sistema de memoria autónomo. Lo que se fusiona es únicamente el almacenamiento y el modelo de acceso; cualquier cosa parecida a relevancia, caducidad o consolidación de memoria queda fuera de Core y a cargo de plugins.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.