La semana que viene arranca la beta de WordPress 7.1 y, entre los cambios que ya están en el calendario, hay uno que parece menor hasta que lo miras con calma: el bloque Classic desaparece del inserter. No se elimina del todo, no rompe entradas antiguas, no te migra nada automáticamente. Simplemente deja de estar ahí cuando quieres insertar bloques nuevos. Y eso, en mi experiencia, es justo el tipo de cambio que WordPress sabe vender como progreso mientras te deja el trabajo sucio en el taller.
El equipo de Core lo explica con elegancia en Make WordPress: el bloque sigue registrado, el contenido existente se edita igual, TinyMCE no se toca en los post types que no usan el editor de bloques. Todo correcto. Pero lee el roadmap de 7.1 y la foto completa se aclara: esto es el primer paso hacia deprecar el Classic block y hacer TinyMCE opt-in. No es limpieza cosmética; es una retirada gradual disfrazada de mejora de rendimiento.
¿Te suena? Gutenberg lleva años prometiendo que el editor de bloques sustituiría al clásico sin traumatismos. Luego llegaron los bloques híbridos, el Classic block como puente, los plugins de compatibilidad, las guías de migración que nadie lee hasta que un cliente llama enfadado. Ahora, con 7.1, el puente sigue en pie pero le quitan la rampa de acceso. Si tu plantilla interna, tu theme o tu flujo editorial dependía de pegar HTML en un bloque Classic porque Gutenberg no tenía equivalente decente, a partir de la beta del 15 de julio vas a buscarlo en el inserter y no estará.
Lo irónico es que el argumento oficial tiene sentido técnico. Un editor más ligero sin arrastrar TinyMCE para quien no lo necesita mejora tiempos de carga y reduce superficie de mantenimiento. Seravo y otros medios del ecosistema ya avisan de que 7.1 llega con un calendario apretado: beta el 15 de julio, RC el 5 de agosto, release final el 19. Cuatro semanas para probar un cambio que afecta a flujos editoriales reales. Si gestionas webs de clientes con contenido legacy — y en España eso es casi todas las pymes con WordPress de más de tres años — no es un detalle: es una auditoría de contenido que nadie te ha presupuestado.
Fix It Phill publicó un checklist que resume bien la trampa: no hay migración automática. Los bloques Classic que ya tienes siguen ahí, pero crear uno nuevo implica instalar un plugin, activar un filtro (wp_classic_block_supports_inserter) o rehacer el contenido bloque a bloque. Tres caminos, ninguno gratis. El plugin Enable Classic Block ya existe precisamente porque alguien ha visto venir el lío. Cuando la solución oficial a un cambio de Core es un plugin de terceros o un snippet en mu-plugins, el mensaje es claro: la decisión está tomada, tú adapta tu stack.
Lo que más me molesta no es esconder el bloque. Es el timing. WordPress 7.0 salió en mayo con IA nativa, Abilities API, colaboración en tiempo real pospuesta otra vez, y un ecosistema de plugins aún digiriendo la numeración nueva. WooCommerce 11.0 está previsto para finales de julio, justo antes de 7.1. Si tienes tienda y mantienes plantillas con HTML embebido en Classic blocks — banners, tablas, scripts de terceros, shortcodes raros de hace una década — te enfrentas a actualizar Woo, probar 7.0.1 (que sale el 9 de julio) y encima revisar si tus editores pueden seguir trabajando como antes. Todo en el mismo verano. Suena a planificación de producto, no a planificación de agencia.
Y aquí está el debate que pocos quieren tener en voz alta: ¿cuántos sitios realmente necesitan el Classic block en 2026? Seguro que muchos menos que en 2020. Pero «muchos menos» no es «cero», y WordPress no distingue entre la web corporativa nueva hecha en bloques nativos y la tienda Woo con 400 productos importados de un CSV que dejó páginas con markup imposible de convertir sin perder horas. El Core optimiza para el futuro; las agencias cobran por arreglar el pasado. Esa asimetría no es bug, es el modelo de negocio de un CMS con cuarenta por ciento de internet encima.
Mi consejo, si gestionas webs en producción, es práctico y aburrido: antes del 15 de julio, busca en la base de datos posts con bloques core/freeform, documenta quién los usa y para qué, prueba en staging con la beta y decide si activas el filtro, instalas el plugin o migras contenido. No esperes al «general release» del 19 de agosto para descubrir que la persona de marketing no puede pegar su HTML de confianza. Y si eres quien vende mantenimiento, mete esta revisión en el presupuesto ahora; cuando salga 7.1 estable, cobrar urgencias es más caro y menos elegante.
WordPress quiere un editor más rápido y coherente. Yo también lo quiero. Pero esconder herramientas sin migración asistida no es modernizar: es externalizar el coste a quien ya paga hosting, plugins y horas de soporte. Si la apuesta es que Gutenberg ya está listo para sustituir al Classic block en todos los casos reales, que lo demuestren con conversores fiables, no con un filtro PHP que la mitad de los usuarios no sabrá activar.
Si mañana tu cliente te pide pegar un iframe de un proveedor que solo da código HTML crudo y el bloque Classic ya no aparece en el inserter, ¿le cobras la hora de desarrollo para habilitarlo por filtro o le dices que aprenda a usar el bloque HTML personalizado y se olvide del flujo que llevaba usando cinco años?