WooCommerce 10.7 estaba previsto para el 14 de abril de 2026 y, segun el calendario publicado en el blog de desarrolladores, el trabajo de esta versión va muy claro a una cosa: quitar consultas de más donde duelen (pedidos, checkout y API) y meter por fin un sistema de fulfillment con API de verdad, aunque todavía en beta. Si te ganas la vida con tiendas WooCommerce, no es un “número de versión más”: es una actualización que te puede cambiar el tiempo de respuesta y, si tienes plugins tocando fulfillment, el fin de semana en el que tocas código.
Qué prometieron en el núcleo: métricas que no son humo
En la entrada oficial de WooCommerce para desarrolladores cuentan que las consultas HPOS en /wc/v4/orders bajan de 271 a 132 gracias a “cache priming” que elimina patrones N+1 durante la serialización de la REST API. Eso no es solo una cifra para el changelog: si tu tienda hace muchas peticiones a la API de pedidos (integraciones, apps, dashboards externos), cada request deja de ser una pequeña bomba SQL.
También mencionan alrededor de un 15% menos de consultas SQL en flujos de checkout. En mi experiencia, cuando el checkout se dispara en picos de tráfico, no suele ser un solo bloque culpable sino la suma de consultas repetidas; aquí el mensaje es que están reduciendo esa suma en el flujo real de compra, no solo en un laboratorio de pruebas.
Además aplican cache priming de forma más consistente en grillas de productos, productos enlazados y pedidos; añaden índices nuevos en woocommerce_shipping_zone_methods para acelerar búsquedas de zonas; y el endpoint de productos de la Store API cachea el timestamp Last-Modified para saltarse una consulta a base de datos cuando hay acierto de caché. Para un sitio con tráfico medio-alto, eso se nota en latencia y en factura de hosting.
El API de fulfillment en beta: lo que te importa si vendes físico
En 10.7 el sistema de fulfillments recibe una de las actualizaciones más grandes hasta la fecha, pero Automattic lo deja claro: sigue en beta. Lo relevante para ti es que los proveedores de envío personalizados pasan a apoyarse en una taxonomía nueva wc_fulfillment_shipping_provider y hay una página de ajustes en Envío > Proveedores de envío.
En PHP expone métodos tipados como get_tracking_number(), set_tracking_number() y get_shipping_provider(). Los eventos del ciclo de vida del fulfillment se registran como notas de pedido con un grupo de notas dedicado, y el data store queda registrado vía woocommerce_data_stores para que una extensión pueda sustituir implementaciones si lo necesita.
Traducción: si hasta ahora tu “tracking” era un chapuzón de meta campos y hooks frágiles, aquí hay una base más estándar. Eso también significa que si tu plugin o snippet asumía comportamentos viejos, toca probar en staging antes de actualizar en producción.
Store API: pesos, medidas y relaciones sin martillear el servidor
Los productos en la Store API ahora devuelven weight, dimensions, formatted_weight y formatted_dimensions. Para frontend que calcula envíos o muestra fichas en un headless, te evitas concatenar peticiones extra.
También incorporan upsells, cross-sells y relacionados como _links embebidos con embeddable: true, de modo que un ?_embed puede traer datos relacionados sin un bombardeo de llamadas. Y hay un par de endurecimientos: productos borrador o no publicados devuelven 404 en rutas single de la Store API, y arreglan detalles de srcset en miniaturas para el carrito.
El aviso que te puede ahorrar un susto: cambio de namespace
En la misma entrada dejan un “developer advisory” explícito: el namespace de fulfillments pasa de Automattic\WooCommerce\Internal\Fulfillments a Automattic\WooCommerce\Admin\Features\Fulfillments. Si tu extensión referencia la ruta antigua directamente, en 10.7 lo vas a notar.
También listan endurecimiento de seguridad en varios endpoints y handlers AJAX, y un arreglo en campos de contraseña de pasarelas cuando el valor contiene el carácter %. No es ruido de marketing: es el tipo de cambio que te evita un ticket de soporte a las dos de la madrugada.
Qué haría yo antes de pulsar “actualizar”
Primero: staging con un clon realista de datos de pedidos y envíos. Segundo: revisar plugins que toquen fulfillments, shipping providers o notas de pedido. Tercero: si dependes de la REST API de pedidos para integraciones, medir antes y después con las mismas peticiones. Cuarto: leer el changelog completo en el repositorio porque siempre hay matices que no caben en un resumen.
La buena noticia es que la dirección es clara: menos SQL innecesario, API más predecible y un sistema de fulfillment que empieza a parecerse a lo que las tiendas medianas pedían desde hace años. La mala noticia es la de siempre: si vives de plugins desactualizados o a medias, la major version te la encuentras a ti, no al revés.
Fuentes
- WooCommerce 10.7: What’s coming for developers (WooCommerce Developer Blog)
- Changelog / readme.txt (plugins/woocommerce en GitHub)
Si mañana tu tienda pasa a 10.7 y solo puedes medir una cosa en las primeras 48 horas, ¿prefieres que baje el tiempo de respuesta del checkout o el número de consultas en la API de pedidos?