Deploying WordPress.org

This page covers getting a change from a merged pull request, or a working copy on your sandbox, onto WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.

You need RW access to meta.svn and/or dotorg.svn — see Becoming a Meta committer — and an SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/. password, which you generate from your profile as described in Subversion Access.

What a deploy actually does

Read this before your first deployDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors..

A deploy ships all code in the tree, not just your changes. WordPress.org runs WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. trunk and a large number of plugins. Anything committed since the last deploy goes out with yours. You must be ready to respond to breakage you did not cause.
A deploy takes roughly four to eight minutes, and is not atomic. Expect some PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php fatals while it runs — a new file added to core, or a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. updating mid-deploy, will briefly be half-present.
It runs the test suite and clears the mid-deploy cache, which is part of why it is slow. Let it finish; do not interrupt it.
A deploy may stop and ask you to commit changes you did not make. deploy-dotorg.sh exports the latest root files from core.svn before deployingDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors., so an updated wp-settings.php can appear as a pending change. It prompts “There are changes to make, please test and commit them” — test and commit them. Answering no may break production.

Committing

Always sync your working copy first:

svn up

Review what you are about to send:

svn diff path/to/file

Commit a single path:

svn ci path/to/file -m "Component Name: Fix the thing. See #1234. Props username."

Commit several paths as one changeset, either by listing them or by referencing siblings from inside a plugin directory:

svn ci path/to/file1 path/to/file2 -m "..."

cd wp-content/plugins/support-forums
svn ci . ../../themes/pub/wporg-support-2024/ -m "..."

Follow the Core commit message conventions. In short: a human-readable component prefix (Plugin Directory: rather than plugin-directory:), a ticket reference if one exists (See #1234 or Fixes #1234), props listed without @, and Closes <pull request URL> in the body when the change came from a PR.

If a commit fails with svn: E175013: Access to '/!svn/me' forbidden, that is a permissions problem rather than a broken working copy — the account you are committing with does not have write access to that repository. See Becoming a Meta committer.

Deploying

deploy-dotorg.sh <target>

Targets include wporg, api, forums, mu, planetw, buddypress and others. Use the target that matches what you changed.

If your change touches shared code loaded by several sites, refresh every local SVN checkout and deploy them all:

svnup-all.sh
deploy all

deploy all takes considerably longer than a single target. Shared code may also need a WordCamp.org deploy on top of this.

Changes that come from GitHub

For components developed on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ and synced into SVN, do not hand-commit the change. Use the sync script, which rebases the merged PR into both meta.svn and dotorg.svn in one go.

WordPress.org and the Plugin Directory

Fork WordPress/wordpress.org, branch, and build your change.
Open a PR against WordPress/wordpress.org. Optionally, create a TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket and link it in the PR description.
Once approved, SSHSSH Secure SHell – a protocol for securely connecting to a remote system in addition to or in place of a password. to your sandbox.
Install and authenticate the gh CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. on the sandbox — the sync script needs it. The release tarball contains a prebuilt binary; you do not need to compile anything.
Run the sync script from the web root:

cd /home/wporg/public_html
bin/sync/github-wordpress.org.sh <pr-number>

If the PR adds a new plugin, handle the external first — see below.
Deploy:

deploy-dotorg.sh wporg

Pattern Directory

Squash and merge the PR on GitHub.
On the sandbox, svn up first.
Run bin/sync/pattern-directory.sh. The script waits for all GitHub Actions to finish before syncing.
When prompted, press d to view the diff before it commits. Do not press f — that skips waiting for the Actions to complete.
Deploy with deploy-dotorg.sh wporg.

Learn WordPress

learn.wordpress.org is developed in WordPress/Learn and synced into SVN.

Merge your PR on GitHub.
Run the sync from the WordPress.org web root, then refresh your checkouts and deploy:

cd /home/wporg/public_html
bin/sync/learn.sh
svnup-all.sh
deploy-dotorg.sh wporg

Make WordPress

make.wordpress.org is developed in WordPress/wporg-make and synced into SVN.

Merge your PR on GitHub.
GH will trigger an action, which will push the changes to the build branch. Confirm your changes are there.
Run the sync from the WordPress.org web root, then refresh your checkouts and deploy:

cd /home/wporg/public_html
bin/sync/wporg-make.sh
svnup-all.sh
deploy-dotorg.sh wporg

Shared mu-plugins

The mu-plugins shared across the WordPress.org network are developed in WordPress/wporg-mu-plugins and synced into dotorg.svn. This is the repository behind the wporg-mu-plugins external you will find in more than one web root — see Working on a sandbox.

Merge your PR to trunk on GitHub.
Wait for the build action to finish. The sync clones the repository’s build branch, not trunk, so syncing before the action completes picks up a stale build. The script warns you if actions are still running or have failed, but it does not wait for them.
Run the sync script from the web root:

cd /home/wporg/public_html
bin/sync/wporg-mu-plugins.sh

The script stages the built code into wp-content/mu-plugins/pub-sync on the sandbox, prints the diff, and then prompts you: press c to commit to dotorg.svn, or Control+C to abort. Aborting leaves the staged code on the sandbox rather than reverting it. It commits as mu-plugins: Sync with git WordPress/wporg-mu-plugins@<commit>.

After committing it offers to deploy for you — press y and it runs deploy-dotorg.sh all, which is what shared mu-plugins need. You do not have to deploy separately.

Two things to know before you run it. If pub-sync has local modifications the script stops and asks whether to back them up (b) or discard them (r). And if you abort after staging, undo it with:

svn revert -R /home/wporg/public_html/wp-content/mu-plugins/pub-sync
svn cleanup --remove-unversioned /home/wporg/public_html/wp-content/mu-plugins/pub-sync

Shared configuration

The .config/ directory is checked out into more than one web root: /home/wporg/public_html/.config/ and /home/wordcamp/public_html/.config/ are working copies of the same dotorg.svn path — see Working on a sandbox.

Commit the change once — both paths are the same working copy — then refresh and deploy each network separately. svnup-all.sh is run from inside that root’s .config/, once per root: running it in one root does not refresh the other.

cd /home/wordcamp/public_html/.config/
svnup-all.sh
# edit the file
svn ci -m "Describe the change."
deploy-wordcamp.sh

cd /home/wporg/public_html/.config/
svnup-all.sh
deploy-dotorg.sh all

The commit happens only in the root you start from; the second root needs the refresh and its own deploy, nothing more. Which network you do first does not matter, but both are required — skipping one leaves it serving the old configuration.

Smoke test across both networks afterwards, not just the one you were working in — for example wordpress.org, a profile page, central.wordcamp.org, and events.wordpress.org.

Adding a new plugin

If a PR adds a new plugin, the website repository needs an svn:externals entry pointing at its meta.svn path. Do this after the sync commit and before deploying:

svn propedit svn:externals .

Add the plugin under the correct section for metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. plugins:

<plugin-slug> https://meta.svn.wordpress.org/sites/trunk/wordpress.org/public_html/wp-content/plugins/<plugin-slug>/

Then commit, deploy, sync, and activate:

svn commit /home/wporg/public_html/wp-content/plugins -m "Plugins: Add the <plugin-slug> external. Fixes #1234."
deploy-dotorg.sh wporg
svn up
wp --url=https://wordpress.org/plugins/ plugin activate <plugin-slug>

If something breaks

Have these to hand before you need them.

Pin WordPress trunk to an earlier revision. If a core trunk change causes widespread breakage, pin to a known-good revision — find it at build.trac.wordpress.org/changeset.
Roll back a GutenbergGutenberg 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/ update. Edit svn:externals on wp-content/plugins and set the previous stable version tag.
Revert a commit. svn merge -c -<revision> . followed by a commit and another deploy. Confirm the exact incantation with a Meta committer before you need it in anger.

Deploying a revert is still a full deploy, with all the caveats at the top of this page.

Manual commits

If you need to commit a change without going through GitHub or a sync script — because something is broken and the normal path is not available — do it. Getting the fix out matters more; the history can be reconciled afterwards.

Deploying WordPress.org

In this article