El 29 de julio WooCommerce metió en producción el Checkout Block 2.0 y, desde el primer día, he visto en foros y grupos de agencias la misma pregunta repetida: «¿por qué mi plugin de campos personalizados ha dejado de funcionar sin avisar?». La respuesta corta es que Automattic ha cambiado la arquitectura del checkout de raíz. La larga es que te lo venden como modernización y tú te quedas con el trabajo sucio de descubrir qué se ha roto en cada tienda.
Según Online Store News, el nuevo checkout sustituye el shortcode clásico por un motor 100 % basado en bloques de Gutenberg. Los campos ya no pasan por filtros PHP como woocommerce_checkout_fields; ahora se gestionan con una Checkout Fields API en JavaScript. En papel suena limpio. En la práctica, cualquier extensión que enganchaba esos hooks deja de hacer nada en cuanto activas el bloque nuevo.
Y aquí viene lo que me molesta: la matriz de compatibilidad oficial cubre unas 140 extensiones de las casi 900 que hay en el repositorio relacionadas con checkout, según el mismo artículo. Eso es menos del 16 %. El resto está en tierra de nadie. Automattic promete un escáner de compatibilidad para suscriptores de WooCommerce.com a partir del 20 de agosto, pero mientras tanto las tiendas que actualizan a ciegas se comen el susto.
Coincide además con el retraso de WooCommerce 11.0. La versión debía salir el 28 de julio y Automattic la aplazó al 4 de agosto — hoy — tras detectar un error fatal en la RC1, como recoge Digital Applied. Dos movimientos grandes en la misma ventana: checkout reescrito y core retrasado por un bug en una feature de rendimiento que ni siquiera nombran con claridad. Si gestionas varias tiendas, el calendario de actualizaciones se te ha convertido en una ruleta rusa.
Lo que pocos comentan es el coste real para agencias y pymes. No es solo «activar el bloque y listo». Hay que auditar cada plugin de checkout, campos extra, validaciones fiscales, integraciones con ERP, pasarelas locales que añaden campos de NIF o código postal especial. Todo eso solía resolverse con un par de filtros PHP en el tema hijo. Ahora implica reescribir lógica en la API de JavaScript o esperar a que el desarrollador del plugin publique actualización. Y muchos no lo harán: el mercado de extensiones WooCommerce está lleno de autores que llevan años sin tocar sus productos.
Automattic empuja la narrativa de rendimiento y experiencia de usuario — arrastrar campos en el editor, menos PHP en el servidor, checkout más rápido. No lo niego, puede tener sentido en una tienda nueva montada desde cero con bloques. Pero la mayoría de las tiendas que conozco llevan cinco o diez años acumulando customizaciones sobre el shortcode. Para ellas, «migrar al checkout moderno» no es una mejora; es un proyecto de varias semanas disfrazado de actualización menor.
Tampoco ayuda el contexto de fondo. Rumores recientes, recogidos por Ecommerce Times, apuntan a que Automattic estaría explorando separar WooCommerce en una entidad independiente con inversión externa. Un audit interno habría calificado las herramientas de desarrollo «entre 18 y 24 meses por detrás de Shopify». Da igual si el spinout se confirma o no: el mensaje que llega al ecosistema es que WooCommerce necesita acelerar, y acelerar en software propietario-open-source suele traducirse en cambios breaking que el usuario final paga.
Shopify, por comparar, avisó hace semanas del apagado de scripts en checkout el 26 de agosto — ya lo comentamos aquí — y al menos lo comunica con fecha y documentación. WooCommerce hace lo propio pero con una capa de complejidad WordPress encima: temas, plugins, hosting compartido, cachés que no se enteran del JavaScript del bloque. El checkout dejó de ser «una página con un formulario» y pasó a ser una mini-aplicación React dentro de WordPress. Eso cambia quién puede mantenerlo. Ya no basta con saber PHP; necesitas alguien que entienda el ecosistema de bloques, la Store API y las extensiones del editor.
Mi consejo, si tienes tienda en Woo y no has tocado el checkout este verano, es no activar el Block 2.0 hasta que hayas hecho tres cosas. Primero, lista todos los plugins que tocan checkout o campos de pedido. Segundo, prueba en staging con el escáner de compatibilidad cuando esté disponible o revisa manualmente la matriz publicada. Tercero, habla con tu agencia o desarrollador sobre el coste de migrar campos custom a la nueva API antes de darle al botón en producción. El shortcode clásico sigue ahí por ahora, y en mi experiencia es mejor un checkout viejo que funciona que uno moderno que pierde el campo de CIF y te deja pedidos sin facturar.
El discurso de «bloques nativos» repite el guion de Gutenberg en 2018: modernización inevitable, resistencia de los dinosaurios, etc. Pero en 2018 no tenías millones de tiendas facturando con plugins atados a hooks concretos. La diferencia es que ahora el breaking change llega cuando WooCommerce compite con Shopify por credibilidad enterprise y necesita demostrar que no va rezagado. El problema es que quien paga la factura de esa carrera no es Automattic: eres tú, con tu catálogo de 3.000 SKU y tu plugin de envíos que nadie ha actualizado desde 2023.
¿Cuántos pedidos perderías si activaras mañana el Checkout Block 2.0 sin probar y tu plugin de campos obligatorios dejara de guardar el NIF en el 30 % de los checkouts móviles?