Repository navigation
Support Gutenberg as a contribution target, not only WordPress Core #251
Description
The gap
Today the toolkit assumes every site is a wordpress-develop checkout. The repo it
clones, the way it decides whether a site is "built", the dev/build workflow, and the
whole open-a-pull-request path are all hard-wired to WordPress Core. A contributor who
wants to work on the block editor has no path in — even though the shape of the work is
nearly identical.
Gutenberg is the obvious next contribution target: it is one of the largest and most
active areas people are pointed at on their first contribution, and its workflow parallels
Core closely enough that the app can host both without a second, separate flow.
The idea
Give each site a project type (WordPress Core or Gutenberg to start), chosen when the
site is created, and let that type drive the parts of the flow that differ:
- Setup — clone the right upstream repository and default branch for the chosen type.
- Status — "is this site ready / built?" is answered differently per project. The Core
heuristic (a builtwp-includesdist directory) does not describe a Gutenberg checkout,
which has its own notion of dependencies installed and dev build having run. - Run / build — surface the dev and build commands that belong to the chosen project
rather than Core's. - Submit a pull request — fork the correct upstream, target the correct default branch,
and phrase the commit for the right project. The existing fork → push → compare flow
stays the same in shape; only the repository coordinates change.
Scope notes
- This should extend the current site model (a site that holds many tickets), not the
older single-purpose layout. The project type is a property of the site alongside its
existing metadata. - Default remains WordPress Core, so nothing changes for existing sites or the common path.
- Keep the type set small and explicit at first (Core, Gutenberg). The value is proving the
app can host more than one contribution target cleanly; a general plugin/theme framework
can come later if it earns its place.
Why file this now
There is an early, unmerged sketch (PR #7) that stubbed a two-project config and a parallel
Gutenberg clone/PR path. It predates the current architecture by a wide margin and is not
revivable as code, but it confirms the intent is sound and worth doing properly against
today's trunk. This issue captures that intent so the implementation can start fresh.
Activity
[Add] a per-site project type driving clone, status and build (#251)
[Add] Work on a Gutenberg issue and open a pull request to it (#251)
[Add] Work on a Gutenberg issue and open a pull request to it (#251)
[Add] a per-site project type driving clone, status and build (#251)
[Add] Serve a Gutenberg site in a real WordPress via Playground (#251)
[Add] Apply Gutenberg pull requests to a Gutenberg site (#251)
[Add] Work on a Gutenberg issue and open a pull request to it (#251)
juanmaguitar commentedon Aug 13, 2026
Closing as not planned for the current validation phase. Expanding from WordPress Core to Gutenberg adds substantial product and maintenance scope before the Core workflow has enough real-user feedback. The related pull requests are intentionally not being changed by this issue triage; this issue can be reopened if a concrete Gutenberg testing cohort makes the expansion part of the next experiment.
[Fix] Stop a build from spawning processes without bound, Fixes #275 (#…
[Add] Guard the bundled npm floor, and let the lockfile record it
juanmaguitar commentedon Sep 15, 2026
Reopened for v1.2.0: this is the milestone's headline feature.
The earlier stack (#255, #261, #264, #269) stays closed; it was cut at
907cb65and trunk has since replaced the Git engine and added pull-request checkout (#459 to #461), so it is being redone on today's code. What ports as-is: the pure modules it introduced (project-type.cjs,playground-plan.cjs,work-item.cjs,renderer/github-issue.cjs) with their tests. What it no longer needs: #264's "apply a Gutenberg PR as a repo-relative patch", since a PR is now a checkout ofrefs/pull/N/headfrom the site's own origin, which works unchanged on a Gutenberg clone.The stack, in order, each PR on the previous one:
npm cirefusing npm 10.9.3 in under a second (devEngines.packageManagernpm >=11.16.0,onFail: error, whichengine-strict=falsedoes not relax). On npm 11 through the app's own Node shims: clone 21 s,npm ci59 s,npm run build29 s,npm run devbuilds then watches.npm run devfor Gutenberg,grunt -- _watchstays for Core).WordPress/gutenberg(fix/issue-N,Fixes #N).wpct://issue/Ndeep link.Out of scope for v1.2.0: a generic plugin or theme project type (the registry allows it, nothing wires it), Trac-style attachments for Gutenberg, running Gutenberg's own test suites from the app.
One thing the spike changed from the old plan: Gutenberg no longer builds into
build/block-library; packages land underbuild/scripts/<handle>/andbuild/styles/, so that is the "is it built" marker.[Fix] Resolve only the registry's own ids, and say what a type over I…
128 remaining items
[Fix] Name each project's own source directory in the hint under the …
[Add] Say on screen while the build watch is still rebuilding or comp…
Bump version to 1.2.0-beta.1 (#505)
[Fix] Let the resumed build watch do the one rebuild after a Gutenber…
[Fix] Let the applied banner follow the build watch instead of turnin…
[Fix] Hide console windows in every Node process below the runners, n…
[Fix] Let a script go three seconds after npm exits when a descendant…
[Fix] Let the resumed build watch do the one rebuild after a Gutenber…
[Fix] Let a work-item switch leave the build watch running instead of…
[Fix] Run Electron as Node through the Helper bundle on macOS so buil…
Bump version to 1.2.0-beta.2 (#520)
Bump version to 1.2.0 (#533)
juanmaguitar commentedon Sep 25, 2026
Shipped in v1.2.0: a site can now be a Gutenberg checkout, served as a plugin in a stock WordPress, with GitHub issues as work items, pull request checkout and opening a pull request from the app. The guide covers the workflows.
Move "Open a pull request" out of SiteRow into a hook and a component (…