WordPress Contributor Toolkit 1.2 ya soporta Gutenberg

En pocas palabras: WordPress Contributor Toolkit 1.2, lanzado el 25 de septiembre de 2026, suma un flujo completo para contribuir a Gutenberg (clonado del repo, build con npm 11, testeo de pull requests y envío de PRs), sumado al flujo para Core que ya existía desde la versión 1.0.

El equipo de WordPress lanzó la versión 1.2 del WordPress Contributor Toolkit el 25 de septiembre de 2026, sumando un flujo completo de contribución a Gutenberg (clonado del repo, build, testeo de pull requests y envío de PRs) al que ya existía para Core desde la versión 1.0, según el anuncio oficial en Make WordPress.

Que suene a «una app más para desarrolladores» es entendible, pero el problema que resuelve es bien concreto: contribuir código a un proyecto open source grande tiene una barrera de entrada que no tiene que ver con saber programar, sino con armar el entorno correcto. Clonar el repo equivocado, tener una versión de Node que no coincide, no saber qué rama bajar para un ticket puntual: eso es lo que hace que alguien con ganas de ayudar se frustre antes de escribir una sola línea. La Toolkit apunta directamente a ese punto, y hasta la 1.1 lo hacía solo para Core. Con la 1.2, Gutenberg entra al mismo circuito.

Vale la pena marcar el objetivo original de la herramienta: sacar de encima esa primera pared que se topa cualquier newcomer, sobre todo en un Contributor Day donde tenés cero paciencia para pelear con dependencias. Con el tiempo se volvió útil también para gente con experiencia.

¿Qué trae de nuevo la versión 1.2 del WordPress Contributor Toolkit?

La 1.2 agrega un flujo de contribución a Gutenberg equivalente, paso por paso, al que ya tenía Core desde la v1.0. Antes, si querías meterte con el editor de bloques tenías que armar el entorno a mano: clonar, instalar dependencias, compilar, levantar un WordPress de prueba. Ahora la app lo hace por vos.

La lógica de fondo no cambió: crear un sitio, vincular el ítem de trabajo (Trac ticket o GitHub issue, según el caso), probar lo que ya existe, escribir tu fix y mandarlo. Lo que cambió es que ahora ese camino también sirve para Gutenberg, y no solo para wordpress-develop. En la práctica, eso significa que aprender el flujo una vez te sirve para los dos proyectos: no hay una curva nueva que subir si ya usaste la app para Core.

¿Te conviene usar la Toolkit para tu primera contribución, o mejor armás el entorno a mano?

No hace falta ser purista para preguntarse si vale la pena instalar una app más. Según lo que describe el propio anuncio, hay algunas señales que ayudan a decidir:

• Si nunca clonaste wordpress-develop ni Gutenberg: la app resuelve clonado, dependencias y build en un solo paso continuo, que es justo la parte donde más se traba un newcomer.
• Si querés probar un pull request ajeno antes de escribir el tuyo: el botón «Apply…» hace el checkout con los commits del autor conservados, algo que a mano implica manejar remotes y fetches manualmente.
• Si ya tenés tu propio entorno armado y funcionando: el valor de la app baja bastante; su punto fuerte es el arranque desde cero, no reemplazar un setup que ya te sirve.
• Si vas a trabajar en varios tickets o issues en paralelo: las branches con nombre (ticket/N, issue/N, pr/N) están pensadas para eso, y ahí sí ahorran tiempo real de gestión.

¿Cómo se crea un sitio de Gutenberg en la app paso a paso?

Se crea con el botón «Create a site», eligiendo una carpeta y marcando «Gutenberg» en vez de «WordPress Core» (que es la opción por defecto). Esa elección define qué repo clona la app, cómo lo compila y cómo lo corre, y no se puede cambiar después: si te equivocaste, arrancás un sitio nuevo.

El resto del flujo es el mismo sea Core o Gutenberg: mismo sidebar, misma terminal, misma pantalla de revisión, mismas formas de enviar el trabajo. Tema relacionado: sumarte a la comunidad de wp-community.

• Clonado y build inicial: la app clona el repo del block editor, instala las dependencias con el npm 11 que trae bundled y compila los paquetes, todo en un solo paso continuo.
• Start dev server: levanta un WordPress estándar corriendo en Playground, con tu checkout montado como plugin de Gutenberg y ya activado.
• Persistencia: posts, ajustes y uploads sobreviven a parar el servidor o cerrar la app.
• Start build watch: corre el npm run dev propio de Gutenberg, que recompila todo una vez y después recompila en cada guardado.

Como el setup termina con un build completo, el servidor arranca en segundos. Nada de esperar a que compile antes de ver si tu cambio anduvo.

Ejemplo hipotético: una primera contribución de punta a punta

El siguiente recorrido es un ejemplo hipotético, armado a partir de lo que describe el anuncio oficial, y no corresponde a un caso real reportado. Imaginemos a alguien que participa por primera vez de un Contributor Day y elige meterse con Gutenberg en vez de Core.

Abre la app, hace clic en «Create a site», elige una carpeta y marca «Gutenberg». Mientras la app clona el repo, instala dependencias con el npm bundled y compila, esa persona aprovecha para buscar un «good first issue» en el repositorio de Gutenberg. Con el número de issue en mano, lo pega en la tarjeta correspondiente apenas termina el setup: el sitio arma automáticamente una branch issue/N para ese trabajo puntual.

Antes de tocar código, revisa si ya hay un pull request abierto para ese issue. Encuentra uno, hace clic en «Apply…», ve qué archivos va a tocar y lo deja probado en su propia branch pr/N, con los commits del autor original visibles. Después de probarlo, usa «Revert this PR» para volver a su propio punto de partida y escribir su versión del fix. Cuando termina, abre «Review & submit changes», revisa el diff completo, y en «Open a pull request» inicia sesión por GitHub device flow. La app hace el fork, pushea la branch y abre el PR con la línea «Fixes #N» ya agregada. Todo el recorrido, de la instalación al pull request abierto, sin salir de la aplicación.

¿Cómo se vincula un issue de GitHub y se prueba un pull request existente?

Se vincula ingresando el número del issue o pegando su URL en la tarjeta correspondiente, que en un sitio de Gutenberg reemplaza a la tarjeta de ticket de Trac que ves en Core. Al vincularlo, el issue arma su propia branch dentro del sitio.

Ahí es donde se nota que la app comparte lógica entre los dos flujos: todo lo que hacían las ticket branches en Core funciona igual acá. Podés saltar entre issues en segundos, dejar un trabajo pausado sin perderlo, o mover un issue a la trunk actual con un solo click.

Un issue vinculado muestra los pull requests que lo resuelven, con su estado. Cada PR tiene un botón «Apply…»: la app te muestra qué archivos va a tocar, y después hace el checkout de esos commits en una branch propia (pr/N), con el autor original conservado en el historial. Si querés volver a tu propio trabajo, «Revert this PR» te devuelve ahí.

¿Cómo se envía la contribución: revisión y pull request?

Se envía con «Review & submit changes», que abre el diff completo de lo que cambiaste. En un sitio de Gutenberg el destino es «Open a pull request»: iniciás sesión en GitHub por device flow, y la app forkea WordPress/gutenberg a tu cuenta, pushea la branch y abre el PR vía API. Cubrimos ese tema en detalle en probar tus cambios en un entorno de staging.

La autorización vive solo en memoria y desaparece cuando cerrás la app. Nada queda guardado en disco esperando a que alguien lo encuentre.

El formulario pide título y notas para revisores. Como los reviewers de Gutenberg quieren pasos de testeo concretos (qué abrir, qué clickear, qué debería pasar), ahí es donde tenés que poner el esfuerzo: la app no te va a completar eso por vos. La app agrega la línea Fixes #N automáticamente, así que el PR aparece en el issue apenas se abre. No hay que postear nada en ningún otro lado.

¿Por qué cada sitio es ahora un repositorio Git real y qué cambia respecto a la v1.0?

Cada sitio es un repositorio Git real desde la v1.1, cuando la app dejó de usar isomorphic-git (una implementación de Git en JavaScript) y pasó a bundlear el mismo cliente que corre GitHub Desktop, ejecutado sin tocar la configuración de tu máquina.

La v1.0 cubría el flujo básico, pero el clon que armaba no tenía historial atrás. En la práctica, eso significaba que la app no podía mergear el pull request de otra persona sobre tu trabajo, ni mover tu ticket a la trunk del día. Y cuando un patch no encajaba, a veces se saltaba un archivo que Git directamente hubiera rechazado, algo que puede pasar desapercibido hasta que el reviewer te avisa que el patch no aplica limpio de su lado.

Ahora cada operación es un comando Git real corriendo por vos: crear un sitio es un clone, vincular un ticket es una branch, aplicar un patch es git apply, probar un pull request es un fetch más un checkout, actualizar trunk es un fetch más un merge. Eso trae varias ventajas concretas, y no son poca cosa para quien viene de pelear con checkouts rotos: en mantener tu instalación siempre actualizada profundizamos sobre esto.

• Historial completo desde la terminal: git log, git blame y git bisect funcionan como en cualquier clon normal.
• Commits reales al aplicar un PR: después de «Apply…», git log lista los commits del pull request con sus autores originales en la branch pr/N.
• Branches con nombre: cada ticket de Core vive en ticket/N, cada issue de Gutenberg en issue/N, cada PR probado en pr/N.
• El sitio sobrevive a la app: borrás el Toolkit, o abrís la carpeta en otra máquina, y el repositorio sigue funcionando con el Git que haya instalado ahí.

Eso sí: los sitios creados antes de la 1.1 no se pueden escribir con esta versión. Podés leerlos y guardar el trabajo como patch, pero para seguir contribuyendo tenés que crear un sitio nuevo (la propia tarjeta del sitio te lo avisa y te ofrece hacerlo). Si estás probando este flujo en local antes de llevarlo a un entorno propio, después vas a necesitar dónde alojar el resultado final; para eso, un hosting WordPress como el de Donweb te evita el paso extra de configurar servidor desde cero.

¿Cómo se reportan errores o feedback sobre la nueva versión?

Se reportan por tres canales distintos según el tipo de problema: un issue en GitHub para bugs concretos, un formulario de feedback (o el botón dentro de la app) para sensaciones generales, y los canales de Slack #core o #core-editor para discutirlo en vivo.

El soporte de Gutenberg en la app es nuevo, así que los reportes más útiles son los de gente que lleva un issue completo hasta un pull request abierto. No sirve tanto probar dos clicks y abandonar: lo que necesita el equipo es ver el flujo entero puesto a prueba, con feedback sobre en qué punto se traba o qué paso no queda claro.

Errores comunes al usar WordPress Contributor Toolkit 1.2

• Elegir Core cuando en realidad ibas a tocar Gutenberg: la elección entre «WordPress Core» y «Gutenberg» al crear el sitio es irreversible. Si te confundís, no hay forma de cambiarla: hay que borrar el sitio y arrancar de nuevo.
• Seguir usando un sitio creado antes de la 1.1 para escribir cambios: esa versión anterior no permite escritura con el cliente Git nuevo. Podés leer y sacar un patch, pero para seguir trabajando necesitás un sitio nuevo.
• Iniciar un merge o rebase manual desde la terminal y volver a la app esperando que siga andando sola: la app detecta que hay una operación Git a mitad de camino y se detiene a esperar que la termines o la abandones vos mismo; no escribe nada hasta entonces.
• Escribir notas vagas al abrir el pull request: los revisores de Gutenberg piden pasos de testeo concretos (qué abrir, qué clickear, qué resultado esperar), no un resumen genérico del cambio.

Preguntas Frecuentes

¿Qué es WordPress Contributor Toolkit?

Es una aplicación de escritorio del proyecto WordPress que arma automáticamente el entorno de desarrollo para contribuir a Core o a Gutenberg, sin que el contribuidor tenga que instalar ni configurar nada a mano. Nació para bajar la fricción en Contributor Days, pero hoy la usa también gente con experiencia.

¿Qué trae de nuevo la versión 1.2 respecto a la 1.0?

La 1.2 suma un flujo completo de contribución a Gutenberg, algo que en la 1.0 solo existía para Core. El resto de la app (sidebar, terminal, pantalla de revisión) se mantiene igual para ambos casos, según detalla la publicación cruzada en Make WordPress Test.

¿Necesito tener Git instalado para usar la app?

No. Desde la versión 1.1 la app bundlea su propio cliente Git, el mismo que corre GitHub Desktop, y lo ejecuta sin depender de la configuración de tu máquina. Tengas Git instalado o no, el comportamiento del sitio no cambia.

¿Puedo seguir usando un sitio creado con la versión anterior de la app?

Podés leerlo y guardar tu trabajo como patch, pero no podés escribir cambios nuevos con la versión 1.2. La app lo indica en la tarjeta del sitio y te ofrece crear uno nuevo compatible.

¿Cómo se envía una contribución a Gutenberg una vez terminada?

Con «Review & submit changes» y después «Open a pull request»: la app te pide iniciar sesión en GitHub por device flow, forkea el repositorio WordPress/gutenberg a tu cuenta y abre el PR vía API, agregando la línea «Fixes #N» de forma automática.

Conclusión

Lo que cambió con la 1.2 es concreto: Gutenberg ya no queda afuera del flujo simplificado que Core tenía desde hace rato. Para alguien que nunca contribuyó código a WordPress, eso significa una pared menos entre «quiero ayudar» y «mandé mi primer pull request». Y para quien ya contribuye, el cliente Git real desde la 1.1 es la diferencia entre una app de juguete y una herramienta que podés usar en serio, sin sorpresas cuando un patch no aplica limpio.

Si venís de pelear con setups locales de Gutenberg a mano (dependencias que no cierran, builds que tardan una eternidad, versiones de npm que no coinciden), esta versión te ahorra ese dolor de cabeza específico. El paso lógico ahora es probarla con un issue real marcado como «good first issue» y ver si el flujo aguanta hasta el pull request abierto, que es justo el tipo de feedback que pide el equipo.

Fuentes

• Make WordPress Community – Anuncio oficial de WordPress Contributor Toolkit 1.2
• Make WordPress Test – Publicación cruzada del anuncio 1.2
• Gutenberg – Página oficial del proyecto en WordPress.org
• Git – Sitio oficial del sistema de control de versiones