v1.0.0-beta.1

WordPress Contributor Toolkit v1.0.0-beta.1

This is the beta for the first 1.0, published so contributors can test it before the stable tag. The headline is that the patch flow now goes both ways: you can pull the work that already exists on a Trac ticket into your checkout and test it, and you can send your own change back — as a file, as a mentor handoff, or as a real pull request — without ever leaving the app. On the way, the app also opens and debugs your code, and keeps a site's trunk current instead of freezing it on the day it was cloned.

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.

Try the work already on a ticket

The whole point is the Contributor-Day failure this prevents: several people writing overlapping patches because none of them could see anybody else's.

• A site knows which Trac ticket it is for (#123). Asked optionally at creation — "What are you working on?" — or set, changed and cleared later, and it survives restarts. Parsing accepts what a contributor actually pastes: a bare number, #12345, or any core Trac URL with an anchor, trailing slash or ?format= still attached.
• The ticket's pull requests, listed and applyable (#136). Newest first, each with its state and last-updated date; Apply… fetches that PR's diff into the preview → apply → rebuild flow.
• The ticket's Trac attachments too (#139). On many good-first-bugs the patch is a .diff attached to the ticket, not a PR. Because Trac serves the attachment list only to a real browser, one click opens the ticket in an embedded window, the contributor clears the proof-of-work challenge once, and the app scrapes the list into a native view — each .diff/.patch with Apply…, non-patches shown but marked as such.
• A "Latest" pill marks the most recent patch across both (#140), PR or attachment, so a contributor arriving at a ticket knows which fix to try first.

Apply a patch, then rebuild

• Choose a patch file → preview → apply and rebuild (#135). The preview lists the files the patch touches, flags collisions with your own edits, names binary files it will skip, and says whether package-lock.json moves so an install runs before the rebuild. The applied patch is recorded so it can be reverted after a restart.
• Apply a PR straight from a pasted URL or number (#142), without it having to be linked to the ticket. Same release also fixes three states found in testing: the apply error persisting after Cancel, the "try someone else's patch" sub-copy contradicting itself during a PR preview, and two failure sentences running together.
• Honest empty state (#189): the revert control tells the truth when there is no patch left to revert.

Send your change back

• The patch flow names its destinations, each with its real cost (#166). Attaching to Trac saves the file and deep-links this site's ticket attach page; nothing is uploaded, no account is asked for. Submit patch → Create patch, because it makes a file, it does not submit one.
• Mentor handoff, zero accounts (#166). The saved patch carries a provenance header — handle, event, ticket, base revision, date — so someone else can push it and the props still land on whoever wrote it.
• Open a pull request from the app, with no push credential on disk (#179). Device-code sign-in, then fork, commit and pull request through GitHub's API. No password is typed in, nothing is written to disk, and the token is forgotten on quit. The OAuth application belongs to the WordPress organisation, so no contributor sees an individual's name on their consent screen. Verified end to end on macOS and Windows against wordpress-develop, with checks running and props-bot picking the PRs up.
• Every pull request gets a testable description a reviewer can read in five minutes (#170), and a notes field placed above the paperwork asks what a reviewer actually needs (#204). Two facts from the core handbook a first-timer cannot guess are stated inline: PRs on GitHub are not monitored and must be attached to a Trac ticket to be considered, and nothing is merged on GitHub — which is why the flow ends by sending you back to Trac.
• The destinations are grouped by who does the sending (#200) — file-and-carry (Trac, mentor) in one card, push-on-your-behalf (pull request) in its own — and the diff sits first, with the destinations beside it (#207), because the code is what you opened the screen to look at.

Open and debug your code without leaving the app

• Open in editor and Show in Finder / Explorer / file manager on every site (#158), next to the path. First use offers a picker of the editors found on the machine; after that the button names the editor and launches straight through. Because a packaged app does not inherit the shell PATH, detection stats absolute install locations rather than running which/where — the reason the old dropdown was removed.
• Open a site's folder while it is still being cloned (#212), instead of the app spending several minutes refusing to open a folder it just created.
• Debug your WordPress code (#217). The blueprint now sets WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG and WP_DISABLE_FATAL_ERROR_HANDLER, so notices, deprecations, _doing_it_wrong() and — crucially — a real fatal surface as themselves instead of behind WordPress's recovery screen. The debug log gets its own tab, with the file's path, Show in folder, Copy and Clear.

Keep a site current

• Update to latest trunk, at any time, without recreating the site (#111). Sites used to be pinned forever to the trunk of the day they were cloned, so patches aged against a frozen snapshot and stopped applying on Trac. The site header now shows "trunk as of <date>"; past 14 days an amber notice warns that patches you create may not apply, and Update to latest trunk in the ☰ menu re-fetches, reinstalls dependencies if they changed, and rebuilds.

Clearer, and safer, on every platform

• The editor opens with a visible window on Windows (#201), and main.js is held to using windowsHide only where it belongs (#224).
• The app shows the directory it created from the moment it creates it (#223), and says what actually went wrong when a folder will not open (#211).
• Only http and https addresses open externally (#121).
• Says which files need a rebuild, and why (#210), and points contributors at the terminal for a rebuild or reinstall (#187).
• Stops promising a dark mode the window does not have (#206).
• Refuses to delete a path that is not a registered site (#138), and the quit sweep now covers all four child-process registries (#163).

Under the hood

• A LICENSE file and license metadata (#102), README badges for the latest release and total downloads (#101), and download counts recorded on a metrics branch (#103, #105), documented in STATS.md (#106).
• The agent-review setup moved to an agent-neutral standard in AGENTS.md and .github/instructions (#112, #125, #127) after the credential-carrying CI review was retired.
• Substantial new test coverage around the IPC handlers, the child-process modules, logging and the trunk-update flow (#131, #153–#157), and the renderer bundle is no longer committed (#122).

Downloads

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

Full changelog: v0.1.2...v1.0.0-beta.1