WordPress Contributor Toolkit v2.0.0

This release redesigns the interface with the WordPress Design System, adds a settings dialog and a dark theme, and makes the app translatable, with ten languages included. The packaged app is also about 350 MB smaller.

It follows v2.0.0-beta.1, released on 13 October. The changes since the beta are listed under Since the beta.

Interface

• Redesigned the window with the WordPress Design System: shell, page header and details, cards, dialogs and tray (#591).
• The sites list shows each site's server status beside its name (#652).
• The next-action cue is visible on warning notices (#675).
• The Trac window uses the app's theme (#649).

Settings

Added a settings dialog (#638). It opens from the Settings button in the footer, the app menu on macOS, or the File menu on Windows and Linux.

• Default location for new sites, WordPress.org username and event (#638).
• Language, applied at the next launch (#639). The default follows the operating system language, including languages Chromium does not ship, such as Galician and Spanish (Mexico) (#632).
• PHP version and the WP_DEBUG flags, applied at the next server start (#640). The site details show the values the next start will use.
• Start the dev server or build watch when a site opens, and restart what was running at quit (#641).
• Theme: light, dark, follow the system, or custom background and primary colour (#642, #650, #651).

Translations

All interface strings are now translatable (#634, #635, #636, #643, #644, #645, #646, #647, #653, #654, #656, #664, #665). This includes the setup checklist, trunk update, Review & submit, pull request and GitHub sign-in, ticket and branch notices, patch apply errors, Terminal and Logs output, the mail dialog, the app menu, and app dialogs that previously used the browser's confirm() and alert().

Included languages: Czech, Dutch, English (Canada), English (UK), Galician, Hungarian, Lao, Polish, Serbian and Turkish. A language is included when it is at least 80% translated on translate.wordpress.org. Lao, Serbian and Turkish are new since the beta (#711).

Since the beta

• The site details list the changed files as trees, and each file opens in the editor (#677).
• A ticket's Trac details are kept across a relaunch, and the ticket card is reorganised (#696).
• The footer's tray buttons are labelled with their names (#700).
• The empty Server tab in Logs shows a placeholder (#698).
• The review dialog's buttons are readable in the dark theme (#697).
• The pull request preview no longer lists trunk's files when the site's trunk is behind (#702).
• A stale cached redirect no longer blocks opening a pull request (#667).
• The packaged app is about 350 MB smaller: unused PHP builds, renderer libraries and Chromium locales are left out (#707).

Fixes

• Sites run as a local environment, so Application Passwords can be tested over HTTP (#662).
• Adminer opens the correct database with randomized SQLite storage or a custom DB_PATH (#619).
• The Debug.log pane no longer shows a line twice or replays the file when it is saved from an editor (#637).
• A site's terminal no longer shows stretched text when the site was not open at launch (#592).
• A failed dev server start no longer leaves event listeners behind (#663).

Security

• The main window can no longer be navigated away from the app's page or open other windows, and HTML mail is shown in a separate frame (#571).

Development

• Guide screenshots are generated automatically (#620, #621, #631, #633).
• Release process documented in RELEASING.md (#546, #547).
• Markdown-only pull requests skip the test suites (#660, #676).
• The E2E journeys can run locally without taking the screen or the focus (#671).
• Fixed a flaky E2E teardown (#607) and two integration tests that timed out in a terminal (#680). Moved site status into a hook (#593).

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-2.0.0-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-2.0.0-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-2.0.0-linux-x86_64.AppImage

Full changelog: v1.2.1...v2.0.0

WordPress Contributor Toolkit v2.0.0-beta.1

First beta of 2.0. This release redesigns the interface with the WordPress Design System, adds a settings dialog and a dark theme, and makes the app translatable, with seven languages included.

This is a pre-release. v1.2.1 remains the latest stable release. Report problems in GitHub issues.

Interface

• Redesigned the window with the WordPress Design System: shell, page header and details, cards, dialogs and tray (#591).
• The sites list shows each site's server status beside its name (#652).
• The next-action cue is visible on warning notices (#675).
• The Trac window uses the app's theme (#649).

Settings

Added a settings dialog (#638). It opens from the Settings button in the footer, the app menu on macOS, or the File menu on Windows and Linux.

• Default location for new sites, WordPress.org username and event (#638).
• Language, applied at the next launch (#639). The default follows the operating system language, including languages Chromium does not ship, such as Galician and Spanish (Mexico) (#632).
• PHP version and the WP_DEBUG flags, applied at the next server start (#640). The site details show the values the next start will use.
• Start the dev server or build watch when a site opens, and restart what was running at quit (#641).
• Theme: light, dark, follow the system, or custom background and primary colour (#642, #650, #651).

Translations

All interface strings are now translatable (#634, #635, #636, #643, #644, #645, #646, #647, #653, #654, #656, #664, #665). This includes the setup checklist, trunk update, Review & submit, pull request and GitHub sign-in, ticket and branch notices, patch apply errors, Terminal and Logs output, the mail dialog, the app menu, and app dialogs that previously used the browser's confirm() and alert().

Included languages: Czech, Dutch, English (Canada), English (UK), Galician, Hungarian and Polish. A language is included when it is at least 80% translated on translate.wordpress.org.

Fixes

• Sites run as a local environment, so Application Passwords can be tested over HTTP (#662).
• Adminer opens the correct database with randomized SQLite storage or a custom DB_PATH (#619).
• The Debug.log pane no longer shows a line twice or replays the file when it is saved from an editor (#637).
• A site's terminal no longer shows stretched text when the site was not open at launch (#592).
• A failed dev server start no longer leaves event listeners behind (#663).

Security

• The main window can no longer be navigated away from the app's page or open other windows, and HTML mail is shown in a separate frame (#571).

Development

• Guide screenshots are generated automatically (#620, #621, #631, #633).
• Release process documented in RELEASING.md (#546, #547).
• Markdown-only pull requests skip the test suites (#660, #676).
• Fixed a flaky E2E teardown (#607). Moved site status into a hook (#593).

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-2.0.0-beta.1-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-2.0.0-beta.1-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-2.0.0-beta.1-linux-x86_64.AppImage

Full changelog: v1.2.1...v2.0.0-beta.1

WordPress Contributor Toolkit v1.2.1

This is a small fix release. New Gutenberg sites install again (#588).

Gutenberg recently switched npm to its linked install strategy (WordPress/gutenberg#83847). That installer names its folders with a SHAKE256 hash, and the Node that ships inside Electron doesn't have SHAKE256. So creating a Gutenberg site on 1.2.0 stopped at the npm install step with Error: Digest method not supported. The app now supplies SHAKE256 itself when the runtime is missing it. Core sites don't use the linked installer, so nothing changes for them.

Already have a Gutenberg site that failed on 1.2.0? Update the app, open the site, and click Retry npm install.

Also in this release

• Electron moves from 43.2.0 to 43.6.0 (#537, #539). It's pinned there because 43.7.0 and later crash the dev server on Apple Silicon Macs.
• @wordpress/components moves from 28 to 41 (#563), the base for the upcoming design refresh. You might notice the buttons are a bit bolder and the text inputs are a little taller.
• The first-run screen is ready for translation (#541). Translations come in a later release, so the app is still English for now.
• Everything else is under the hood. The site screen is now split into smaller components and hooks (#567 to #587), and dependencies are updated (#537, #538).

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.2.1-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.2.1-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.2.1-linux-x86_64.AppImage

Full changelog: v1.2.0...v1.2.1

WordPress Contributor Toolkit v1.2.0

32 commits since v1.1.0, and one thing changes what the app is for. A site can now be a checkout of Gutenberg, not only of WordPress Core. You pick the target when you create the site; the app clones it, installs and builds it, serves it, links the issue you are working on, checks out the pull requests that answer it, and opens yours. Same app, same buttons, a second project.

You still install nothing. No Git, no Node, no Docker.

Two betas went before it, tested on macOS and Windows; everything they turned up is fixed here.

Contribute to Gutenberg

• Choose what a site contributes to: WordPress Core or Gutenberg (#476). The choice is made once, in the create dialog, and the site remembers it.
• A Gutenberg site is served as a plugin in a stock WordPress (#471). Playground boots the latest WordPress and mounts your checkout as its Gutenberg plugin, so what you see is what a user of the plugin would see.
• The build watch and the terminal scripts are the target's own (#470). On Gutenberg the watch is npm run dev, and the scripts the terminal accepts are the ones that work without Docker.
• A GitHub issue is a Gutenberg site's work item (#480). Link the issue you are working on; the app lists the pull requests that cite it, and checks one out as a real branch with its author's commits, as it does for a Trac ticket's patches.
• Open a pull request against WordPress/gutenberg from the app (#481), on your fork, citing the issue.
• The guide covers the Gutenberg workflows (#486): first site, issue, pull request checkout, review and submit.

A Gutenberg site builds once, and says when it is ready

Gutenberg's build watch (npm run dev) removes build/ and rebuilds every package before it watches. Most of what the betas found was the app starting, pausing or restarting that watch at the wrong moment.

• A built site's dev server starts at once, without the watch (#500). Start the watch yourself when you want edits under packages/ compiled on save. When the watch does run, the server waits for its first build (#489) instead of serving a plugin with no build.
• Applying a pull request and updating trunk leave the one rebuild to the watch (#508, #516), instead of a build of their own that the resumed watch then threw away. Linking an issue or switching work items no longer restarts the watch at all (#517).
• The screen says when the watch is still rebuilding (#493, #511): the applied banner stays amber until the watch is watching, and turns red if it stops first.
• The install and build steps stay in progress until their command has exited (#496, #504), so a status refresh can no longer read a half-written node_modules or build/ as done.
• The hint under the terminal names each project's own source directory (#491): src/ on Core, packages/ on Gutenberg.

Switching to an older pull request

Checking out a pull request based on a months-old trunk, on a site installed on today's trunk, is the everyday case on Gutenberg, and it left things behind.

• Files the other branch ignored are no longer counted as your changes after a switch (#524).
• A directory the older pull request does not have is removed when all it holds is an install or TypeScript build info (#530, #532). Gutenberg's trunk-only routes/dashboard/ used to survive the switch and fail the build with ENOENT ... routes/dashboard/package.json. Anything else in such a directory, a file of yours included, keeps it where it is.

Windows

• A Gutenberg build opens no console windows (#512). Closing one used to break the build.
• A script whose worker outlives npm still finishes (#513). The app gives it three seconds after npm exits, then ends the tree and reports npm's exit code, instead of staying in progress for as long as the worker ran.

macOS

• A Gutenberg build no longer fills the Dock with "exec" tiles (#519). Build workers now run through the app's Helper bundle, which the Dock does not show.
• Builds that set NODE_OPTIONS work (#528). Electron on macOS ignores that variable in processes it did not start itself, so an older Gutenberg pull request whose token build relies on it failed; the app's shims now pass those options as arguments.

A change on Core sites

• Stop dev server no longer stops the build watch (#489). The two were always meant to be independent; stop the watch from its own button.

Under the hood

• npm 11 is bundled (#468), the floor wordpress-develop and Gutenberg now set.
• A registry of contribution targets drives the clone, the built check, the watcher and the terminal's script list (#469), so a third target is a registry entry.
• Stop forces the whole process tree when its SIGTERM is ignored (#479), not only the runner.
• The docs site publishes per release (#487), not on every trunk push, so the guide matches the app you downloaded.
• The manual real-setup workflow passes again (#531), with time budgets sized for the slowest hosted runners, and a new site on each platform and target built end to end on this release's code.

Of the 32 commits since v1.1.0, 7 are docs, tests, the docs site and the three version bumps, and do not reach the app.

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.2.0-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.2.0-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.2.0-linux-x86_64.AppImage

On Windows the app runs Node and Gutenberg's build tools as x64; on a Windows on ARM machine they run under emulation, and a Gutenberg build takes several minutes and needs 8 GB of memory or more.

Full changelog: v1.1.0...v1.2.0

WordPress Contributor Toolkit v1.2.0-beta.2

The second beta of 1.2.0: 9 commits since v1.2.0-beta.1, every one of them a fix that the first beta's pass turned up, on macOS and on Windows. Nothing new to learn; the Gutenberg workflows from beta.1 are the same, and each of the things below is one that made them slower or noisier than they needed to be.

You still install nothing. No Git, no Node, no Docker.

A Gutenberg site rebuilds once, not twice

Gutenberg's build watch (npm run dev) removes build/ and rebuilds every package when it starts. Three things in the app paused that watch for their own work, ran a full build of their own, and then resumed the watch, which threw that build away and did it again. On macOS that was a minute where half a minute would do; on Windows it was closer to a quarter of an hour.

• Applying a pull request leaves the one rebuild to the resumed watch (#508). The checklist shows the build step skipped and names the watch; the confirmation arrives when the watch is watching again.
• Updating trunk does the same (#516). The card stays on its third step, reading The build watch is rebuilding, until the watch's ready line, which is where "Update complete" now belongs. Stop the watch during that wait and the update is reported incomplete, with the retry it always had. On WordPress Core nothing changes: grunt watch starts for free, so the update keeps its own build.
• Linking an issue, or switching between work items, no longer restarts the watch at all (#517). A switch only moves the checkout, and a running watch recompiles what changed on its own, the way it does for a patch. The one switch that still pauses it is the one that puts back a pull request you had parked on a work item, because that one installs and builds afterwards; and a switch made while the watch is still doing its first build, which is not yet watching.
• The applied banner follows the watch (#511). It sat green, saying the site was ready, while the resumed watch was still rebuilding; it now stays amber until the watch is watching, and goes red if the watch stops before then.

Windows

• A Gutenberg build opens no console windows (#512). The build's own tools spawned cmd.exe below the app's runners, where nothing had hidden it; the same treatment the runners get now reaches every Node process below them. Closing one of those windows used to break the build (#497).
• A script whose worker outlives npm still finishes (#513). When something kills part of a build's process tree, npm exits but a worker can survive holding the output pipe, and the checklist stayed in progress for as long as it ran. The app now gives a script three seconds after npm exits, then ends the tree and reports npm's exit code.

macOS

• A Gutenberg build no longer fills the Dock with "exec" tiles (#519). Every build worker runs on the app's own Electron as Node, and a worker that sets its process title was being registered with the Dock under the app's own bundle. Those workers now run through the app's Helper bundle, which the Dock does not show. Same Electron, same build, no tiles.

Under the hood

• The applied banner's place in the card is asserted as document order (#515), not as pixel coordinates measured mid-scroll, which was the one flaky journey.

Of the 9 commits since v1.2.0-beta.1, 2 are tests and this version bump, and do not reach the app.

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.2.0-beta.2-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.2.0-beta.2-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.2.0-beta.2-linux-x86_64.AppImage

On Windows the app runs Node and Gutenberg's build tools as x64; on a Windows on ARM machine they run under emulation, and a Gutenberg build takes several minutes and needs 8 GB of memory or more.

Full changelog: v1.2.0-beta.1...v1.2.0-beta.2

WordPress Contributor Toolkit v1.2.0-beta.1

The first beta of 1.2.0: 17 commits since v1.1.0, and one thing changes what the app is for. A site can now be a checkout of Gutenberg, not only of WordPress Core. You pick the target when you create the site; the app clones it, installs and builds it, serves it, links the issue you are working on, checks out the pull requests that answer it, and opens yours. Same app, same buttons, a second project.

You still install nothing. No Git, no Node, no Docker.

Contribute to Gutenberg

• Choose what a site contributes to: WordPress Core or Gutenberg (#476). The choice is made once, in the create dialog, and the site remembers it.
• A Gutenberg site is served as a plugin in a stock WordPress (#471). Playground boots the latest WordPress and mounts your checkout as its Gutenberg plugin, so what you see is what a user of the plugin would see.
• The build watch and the terminal scripts are the target's own (#470). On Gutenberg the watch is npm run dev, and the scripts the terminal accepts are the ones that work without Docker.
• A GitHub issue is a Gutenberg site's work item (#480). Link the issue you are working on; the app lists the pull requests that cite it, and checks one out as a real branch with its author's commits, as it does for a Trac ticket's patches.
• Open a pull request against WordPress/gutenberg from the app (#481), on your fork, citing the issue.
• The guide covers the Gutenberg workflows (#486): first site, issue, pull request checkout, review and submit.

What the beta pass fixed before this build

• The dev server waits for Gutenberg's watcher to finish its first build (#489). Gutenberg's npm run dev removes build/ before it rebuilds it; a server started too early served a plugin with no build. The URL now appears once the watcher reports it is watching.
• A built Gutenberg site's dev server starts at once, without the watch (#500). That first build is twenty seconds on macOS and minutes on Windows, and on a site the wizard just built it produced what was already there. Start the watch yourself when you want edits under packages/ compiled on save; applying a pull request rebuilds on its own.
• The install and build steps stay in progress until their command has exited (#496, #504). A status refresh mid-way (switching windows was enough) read a half-written node_modules or a half-written build/ as done, and unlocked the next step over it.
• The screen says when the watch is still rebuilding a change just applied (#493), on the applied banner and in the log tab's title, so a site that is briefly unbuilt after a pull request checkout is not mistaken for a broken one.
• The hint under the terminal names each project's own source directory (#491): src/ on Core, packages/ on Gutenberg.

A change on Core sites

• Stop dev server no longer stops the build watch (#489). The two were always meant to be independent (#247); stopping the server used to take the watch down with it by accident. Stop the watch from its own button.

Under the hood

• npm 11 is bundled (#468), the floor wordpress-develop and Gutenberg now set.
• A registry of contribution targets drives the clone, the built check, the watcher and the terminal's script list (#469), so a third target is a registry entry.
• Stop forces the whole process tree when its SIGTERM is ignored (#479), not only the runner; Gutenberg's watcher is a tree that shrugs off a signal to npm alone.
• The docs site publishes per release (#487), not on every trunk push, so the guide matches the app you downloaded.

Of the 17 commits since v1.1.0, 3 are docs, the docs site and this version bump, and do not reach the app.

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.2.0-beta.1-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.2.0-beta.1-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.2.0-beta.1-linux-x86_64.AppImage

On Windows the app runs Node and Gutenberg's build tools as x64; on a Windows on ARM machine they run under emulation, and a Gutenberg build takes several minutes and needs 8 GB of memory or more.

Full changelog: v1.1.0...v1.2.0-beta.1

WordPress Contributor Toolkit v1.1.0

The stable 1.1.0, and the largest release since 1.0: 57 commits since v1.0.1. Two things change what the app is. It ships a real Git and drives every checkout with it, so the repository it leaves behind is one any Git on any machine can continue. And someone else's pull request now arrives as a real branch with its author's commits, instead of a diff with no name on it.

You still install nothing. No Git, no Node, no Docker.

The app brings its own Git

The JavaScript engine 1.0 used was a partial Git, and the remaining work on the ticket flow kept turning into a list of behaviours Git already has. Shipping the real one settles it: the app carries the binary, you never see it, and the day you open the site from a terminal there is nothing to have got subtly wrong (#364).

• The app carries its own Git binary (#401). It runs with none of your machine's Git settings, so a Git you already have, or the lack of one, changes nothing.
• A new site clones the whole history of wordpress-develop, without old file contents (#403). With the history present the app can tell how a ticket's work relates to trunk, at the cost of a larger .git folder.
• Ticket branches, patch apply and revert, trunk updates and discards all run on the bundled Git (#402, #404, #407, #410). A patch is applied by git apply, the same command a reviewer will run, so "fits" means the same thing on both machines.
• Move a ticket onto the current trunk with one click (#408), from the notice on the ticket card, replacing 1.0's five-step manual path.
• When the move cannot be done, the refusal names the files and the kind of conflict (#418). The verdict matches git merge, and nothing is moved.
• Writes are refused while a merge started outside the app is open (#420), naming the terminal commands that finish or abandon it, instead of erasing it on the next write.
• Sites created by an earlier version are refused for writes, and the card says so (#405).

A pull request is a branch, not an unattributed diff

Applying a pull request used to flatten it onto the ticket branch, so the author's history was lost and you could not tell their work from your own edits afterwards (#290, #458).

• A pull request is checked out as a local pr/<number> branch (#459, #460, #461). The author's commits stay theirs, and your edits on top stay with that local copy.
• Leaving a PR gives your own work back (#461). Ticket or trunk work is parked before the switch, and Back to ticket #N or Back to trunk restores it. The review screen attributes edits to the active PR, so the author's commits cannot be submitted as yours.
• If the PR moves upstream while your local copy has edits, the app offers Return to saved copy (#461) rather than overwriting them.
• A ticket remembers its applied PR across unlink, switching tickets and a restart (#463), and restoring one rebuilds the site, installing dependencies only when the lockfile actually changed.
• A pull request's generated files are no longer counted as your changes (#463). One real wordpress-develop PR exposed 1,784 generated Gutenberg files as the contributor's work, and reviewing a large added file failed while the screen claimed there was nothing to send.

Open a ticket from your browser

• The app answers wpct://ticket/<id> (#464, #465). A link, a bookmarklet or a browser extension can hand a ticket straight to the app instead of making you retype the number.
• The link asks before it links, naming the ticket and the site. Linking parks a branch and checks out another, and a click in a browser is not consent to that. Anything that is not a ticket is refused before the window is even raised.

On Windows the scheme is registered the first time you open the app, so open it once before trying a link.

Clearer, and safer, on every platform

• The app package ships only what it needs (#450). The packaging rule is a list of what goes in rather than what stays out, so a stray file cannot end up inside the installer.
• A build no longer spawns processes without bound (#395). Tools started through the app's node shims misread their own path as an argument and restarted themselves forever.
• A patch carried into a ticket takes its record with it (#236). Returning to trunk used to meet a panel naming a patch and offering to revert it over a tree that held none of it.
• No more false "Update incomplete" banner after updating trunk from a ticket (#446). Sites already showing it are corrected once.
• A patch apply that silently skipped a file is now caught (#417), verified file by file and rolled back if one is missing.
• Deleting a site stops its processes first (#415). A running dev server used to make the delete fail on Windows and leave the site half gone.
• The build works on Windows with Git for Windows installed (#422).
• A ticket's recorded trunk base survives an overlapping write (#454).
• Disabled ticket actions say why (#451), to screen readers and in a tooltip. A run that never started is reported as a failure (#452) instead of leaving the terminal waiting.
• The apply panel now sits above the site's other tickets (#472), and the sidebar heading reads Contributor Toolkit (#482).

Under the hood

• The old JavaScript Git engine is retired, and every test fixture is built with the bundled Git (#411).
• The bundled Git inside the Linux AppImage was exercised on Linux before this release: binary, exec bits, symlinks, certificates and an HTTPS clone (#388). Snap and deb are no longer built, because nobody can probe them yet.
• The review standard asks that review evidence is recorded in the pull request (#433, #442, #448, #453) and that a pull request someone else opened is reviewed, not taken over (#456). CodeRabbit reviews on request against that same standard (#400, #455).
• CI runs on pinned actions with scoped credentials (#423), rejects focused tests and keeps Playwright reports (#443), and a manual workflow sets up a real wordpress-develop site end to end (#444).
• Dead exports, a brittle set of renderer source-text tests and a few aliases are gone (#416, #434 to #441). macOS signing failure handling is simpler (#398), and the README downloads badge counts withdrawn assets and excludes prereleases (#447, #449).

Of the 57 commits since v1.0.1, 24 are tests, docs, CI and cleanups that do not reach the app.

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.1.0-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.1.0-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.1.0-linux-x86_64.AppImage

Full changelog: v1.0.1...v1.1.0

WordPress Contributor Toolkit v1.1.0-beta.2

The second beta for 1.1.0, published so contributors can keep testing before the stable tag. Everything in v1.1.0-beta.1 is still here, the bundled Git included, and this build adds the other half of reviewing someone else's work: a pull request now arrives as a real branch with its author's commits, not as an unattributed diff. It also gives the app an address (like wpct://ticket/<id>,), so a link in a browser can hand it a ticket.

It is a pre-release: please try it on a real ticket and report anything that breaks. Use the feedback button or the installation-bug issue template.

Check out a pull request, instead of flattening it into a diff

Applying a GitHub pull request used to drop its commits onto the ticket branch, so the author's history was lost and the contributor could not tell the PR's work apart from their own edits afterwards (#290, #458).

• A pull request is checked out as a local pr/<number> branch (#461). The author's commits stay theirs, and your edits on top stay with that local copy.
• Leaving a PR gives the work back (#461). Ticket or trunk work is parked before the switch, and Back to ticket #N or Back to trunk restores it. The review screen attributes edits to the active PR, so the author's commits cannot be submitted as your own.
• If the PR moves upstream while your local copy has edits, the app offers Return to saved copy (#461) rather than overwriting them.
• A ticket remembers its applied PR across unlink, switching tickets and an app restart (#463). Revert this PR clears the association and restores the ticket work.
• Restoring a PR rebuilds the site, and installs dependencies only when the lockfile actually changed (#463).
• A pull request's generated files are no longer counted as your changes (#463). One real wordpress-develop PR exposed 1,784 generated Gutenberg files as the contributor's work; reviewing a large added file also failed with Maximum call stack size exceeded while the screen claimed there was nothing to send. Both are fixed.

Applying a local or Trac .patch or .diff is unchanged: it still modifies the active branch and is still reversible as a layer.

Open a ticket from your browser

• The app answers wpct://ticket/<id> (#465, #464). Find a ticket on Trac, and a link, a bookmarklet or a browser extension can hand it straight to the app instead of making you retype the number.
• The link asks before it links. Arriving at the app the ticket is offered, naming the ticket and the site, and one click answers. Linking parks a branch and checks out another, and a click in a browser is not consent to that.
• Anything that is not a ticket is refused, and refused before the window is raised, so a page cannot pull the app in front of what you are doing.

Under the hood

• The checkout work landed as a reviewed stack: the module and the Git reads it needs (#459), the IPC wiring (#460), then the panel (#461).
• diff moves from 5.2 to 8.0.4, which fixes patch generation for large files (#463).
• A failed review now shows an error instead of an empty-state claim, and PR reviews name the PR as their comparison base (#463).

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.1.0-beta.2-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.1.0-beta.2-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.1.0-beta.2-linux-x86_64.AppImage

Full changelog: v1.1.0-beta.1...v1.1.0-beta.2

WordPress Contributor Toolkit v1.1.0-beta.1

This is the beta for 1.1.0, published so contributors can test it before the stable tag. The headline is that the app now ships a real Git and drives every checkout with it, in place of the JavaScript Git engine 1.0 used. You still install nothing. What changes is what you end up with: a repository produced by Git itself, which any Git on any machine can continue, and conflicts, merges and patch verdicts that are Git's own. Sites created by 1.0 cannot be written to by this version, so start a new site to test it.

It is a pre-release: please try it on a real ticket and report anything that breaks. Use the feedback button or the installation-bug issue template.

The app brings its own Git

The JavaScript engine was a partial Git, and the remaining work on the ticket flow kept turning into a list of behaviours Git already has. Shipping the real one settles it: the app carries the binary, the contributor never sees it, and the day they open the site from a terminal there is nothing to have got subtly wrong (#364).

• The app carries its own Git binary (#401). It runs with none of your machine's Git settings, so a Git you already have installed, or the lack of one, changes nothing about how a site behaves.
• A new site clones the whole history of wordpress-develop, without old file contents (#403). With the history present the app can tell how a ticket's work relates to trunk, at the cost of a larger .git folder.
• Ticket branches, patch apply and revert, trunk updates and discards all run on the bundled Git (#402, #404, #407, #410). A patch is applied by git apply, the same command a reviewer will run, so "fits" means the same thing on both machines.
• Move a ticket onto the current trunk with one click (#408). The notice on the ticket card carries a button that does it, replacing the five-step manual path from 1.0.
• When the move cannot be done, the refusal names the files and the kind of conflict (#418). The verdict matches git merge, and nothing is moved.
• Sites created by an earlier version are refused for writes, and the card says so (#405). You can still save its work as a patch, and the banner offers to create a new site.
• Writes are refused while a merge started outside the app is open (#420). A git merge or git rebase stopped on a conflict used to be erased by the app's next write. It now blocks the write and names the terminal commands that finish or abandon it.

Ships only what it needs

• The app package ships only what it needs (#450). The packaging rule is now a list of what goes in rather than what stays out, so a stray file cannot end up inside the installer. The Windows native module ships its binary only.

Clearer, and safer, on every platform

• A build no longer spawns processes without bound (#395). Tools started through the app's node shims misread their own path as an argument and restarted themselves forever.
• No more false "Update incomplete" banner after updating trunk from a ticket (#446). Sites already showing it are corrected once.
• A patch apply that silently skipped a file is now caught (#417). The app now verifies every file and rolls back if one is missing.
• Deleting a site stops its processes first (#415). A running dev server used to make the delete fail on Windows and leave the site half gone.
• The build works on Windows with Git for Windows installed (#422). Its GNU tar read a C: path as a remote host; a bare tar now resolves to Windows's own.
• A ticket's recorded trunk base survives an overlapping write (#454). Site metadata is written as one read-change-write, so a ticket started while a trunk update finishes keeps the base its patches are measured against.
• Disabled ticket actions say why (#451), to screen readers and in a tooltip.
• A run that never started is reported as a failure (#452), instead of leaving the terminal waiting forever.
• The README downloads badge now counts withdrawn assets and excludes prereleases (#447, #449).

Under the hood

• The old JavaScript Git engine is retired, and every test fixture is built with the bundled Git (#411).
• The review standard now asks that review evidence is recorded in the pull request (#433, #442, #448, #453) and that a pull request someone else opened is reviewed, not taken over (#456). CodeRabbit reviews on request against that same standard (#400, #455).
• CI workflows run on pinned actions with scoped credentials (#423), reject focused tests and keep Playwright reports (#443), and a manual workflow sets up a real wordpress-develop site end to end (#444).
• Dead exports, a brittle set of renderer source-text tests and a few aliases are gone (#434 to #441).

Of the 45 commits since v1.0.1, 24 are tests, docs, CI and cleanups that do not reach the app.

Downloads

• macOS (Apple Silicon): wordpress-contributor-toolkit-1.1.0-beta.1-mac-arm64.dmg
• Windows (x64): wordpress-contributor-toolkit-1.1.0-beta.1-win-x64.exe
• Linux (x64): wordpress-contributor-toolkit-1.1.0-beta.1-linux-x86_64.AppImage

Full changelog: v1.0.1...v1.1.0-beta.1

WordPress Contributor Toolkit v1.0.1

A maintenance release. Two changes since v1.0.0 reach the app; everything else is tests and documentation.

Deleting a site no longer leaves half of it behind

Deleting a site on Windows silently left behind anything a real Git wrote (#381, in #382). Git marks the objects it writes read-only, and the delete walked past them without a word, so the site disappeared from the app while its files stayed on disk. Deletion now clears the read-only mark as it goes, and when a path still cannot be removed the app names it instead of reporting success.

macOS downloads before this release were withdrawn

Builds up to v1.0.0 packaged an internal file used for signing. It was revoked as soon as we found it and the packaging is fixed — nothing on your machine is affected, and there is nothing to clean up. Windows and Linux were never affected.

#399 tracks the packaging change behind it.