TL;DR: WordPress Contributor Toolkit v1.2.0 has been released providing full Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ contribution workflows for first-time contributors.

The WordPress Contributor Toolkit was created to remove the points of friction first-time contributors face before they write a line of code, especially during Contributor Days, but is becoming a great tool also for experienced contributors.

The app started by providing a seamless setup of a full WordPress contribution development environment, the first wall most newcomers hit. Version 1.0 brought a full Core contribution workflow into the app: from reading a Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket Created for both bug reports and feature development on the bug tracker. and testing the work attached to it, to sending your own fix back as a pull request or a Trac patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., without ever leaving the app.

Now, version 1.2 adds also a full Gutenberg contribution workflow.

A Gutenberg contribution follows the same path as a Core ticket in the app: create a site, link the work item, try the work that already exists, write your fix, and send it.

Click Create a site, choose a folder, and pick what the site contributes to: WordPress Core, the default, or Gutenberg. That choice decides what the site clones, how it builds and how it runs, and it cannot be changed afterwards. Everything else is the same app: the sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., the terminal, the review screen, the ways to submit.

A Gutenberg site clones the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor’s repository, installs its dependencies with the bundled npm 11, and builds the packages, all as one continuous setup. When it finishes, click Start dev server. The app runs a stock WordPress in Playground with your checkout mounted as the Gutenberg plugin, already activated. Posts, settings and uploads survive stopping the server and restarting the app.

Setup ends with a full build, so the server starts in seconds. To have what you save recompiled, click Start build watch, which runs Gutenberg’s own npm run dev. It rebuilds everything once, then recompiles each save.

Where a Core site has its Trac ticket card, a Gutenberg site has a GitHub issue card. Enter the issue number or paste its URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to link the issue to the site.

The issue gets its own branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". inside the site, so everything ticket branches do on a Core site works here too: switch between issues in seconds, park work you are not ready to finish, move an issue onto the current trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. with one click.

A linked issue shows the pull requests that fix it showing the pull request’s state.

Each PR associated to an issue has an Apply… button. The app previews the files it will touch, then checks the pull request out on its own branch, with the author’s commits. Revert this PR brings your own work back.

Click Review & submit changes to inspect the complete diff. On a Gutenberg site the destination is Open a pull request. You sign in to GitHub through the device flow, and the app forks WordPress/gutenberg to your account, pushes a branch and opens the pull request through the API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. The authorization lives in memory only, and is gone when you quit the app.

The form asks for a title and notes for reviewers. Gutenberg reviewers want testing steps, so that is where they go: what to open, what to click, what should happen. The app adds the Fixes #N line for you, so the pull request appears on the issue as soon as it opens. There is nothing to post anywhere else.

Since v1.1, a pull request you try arrives as its own branch with its author’s commits, its conflicts are the same ones GitHub reports, and your ticket can move onto today’s trunk. That comes from one change: the app now ships Git itself (the client GitHub Desktop uses) instead of the JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com reimplementation 1.0 relied on.

It runs with none of your machine’s settings, and you never see it. A Git you already have, or the lack of one, changes nothing about how a site behaves.

Every operation is now a Git command run on your behalf. Creating a site is a clone, linking a ticket is a branch, applying a patch is git apply, trying a pull request is a fetch and a checkout, updating trunk is a fetch and a merge. What the app does in that folder is exactly what you would see if you had typed the commands yourself. That also means a patch fits or fails the way it will for the reviewer, and when it fails the app names the regions that failed and leaves the checkout unchanged.

What this gives you:

• The whole history, from the terminal or your editor. Open the site folder and git log, git blame and git bisect work as they do on any clone. A new site brings the full history of wordpress-develop or Gutenberg, fetching old file contents only when something asks for them, so it is not much larger than the shallow clone 1.0 made.
• A pull request you apply shows up as its author’s commits. After Apply…, git log lists the pull request’s commits, with their authors, on a pr/N branch. You can read them, diff them, and see exactly what you are testing.
• Your work is on branches you can name. Each Core ticket lives on ticket/N, each Gutenberg issue on issue/N, each pull request you try on pr/N. Parking a ticket in the app is a checkout, and git branch shows everything the app is holding for you.
• The site outlives the app. Delete the app, or open the folder on another machine, and the repository continues with whatever Git is there. Nothing you did depends on the Toolkit staying installed.

Working from the terminal is fine too. Reading the site with git log or git diff never gets in the app’s way, and if you start a merge or a rebase yourself the app waits: it refuses to write until you finish or abandon it, and names the commands that do either.

Sites created before 1.1 cannot be written to by this version. You can still read them and save their work as a patch, but to keep contributing you create a new site. The app says so on the site’s card, and offers to create one.

Since 1.1 the app answers wpct://ticket/N links, so a link can hand a Trac ticket to the app instead of making you type the number. The app asks before it links the ticket to the site you have open, because linking switches branches, and a ticket link that arrives while a Gutenberg site is open waits for a Core site. On Windows, open the app once before trying a link.

This enables much smoother contribution workflows. For example, with WP Trac Triager, a Chrome extension for triaging Core Trac tickets, every ticket on Trac gets a link that opens it in Contributor Toolkit, with its pull requests ready to test.

Try it on a real ticket or issue and tell us how it went:

• Something broke? Open an issue with what you did and what happened.
• Something felt off? Use the feedback form, or the feedback button in the app.
• Want to talk it through? Ask in #core, or #core-editor for the Gutenberg flow, or comment below.

Gutenberg support is new, so the most useful reports come from taking an issue all the way to a pull request.

• Download WordPress Contributor Toolkit
• Follow the Toolkit getting started guide
• Working on a GitHub issue, in the Toolkit guide
• Read the v1.2 release notes
• Learn how to contribute code to WordPress Core
• Read the Gutenberg contributing guide
• Browse good first bugs on Core Trac
• Browse good first issues on Gutenberg

Props to @greenshady and @welcher for review and feedback.

+make.wordpress.org/playground/ +make.wordpress.org/test/ +make.wordpress.org/community/

#contributor-day, #playground, #wordcamp