Title: Deploying WordPress.org
Author: Boro Sitnikovski
Published: August 25, 2026
Last modified: September 14, 2026

---

# Deploying WordPress.org

## In this article

 * [What a deploy actually does](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#what-a-deploy-actually-does)
 * [Committing](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#committing)
 * [Deploying](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#deploying)
 * [Changes that come from GitHub](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#changes-that-come-from-github)
    - [WordPress.org and the Plugin Directory](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wordpress-org-and-the-plugin-directory)
    - [Pattern Directory](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#pattern-directory)
    - [Learn WordPress](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#learn-wordpress)
    - [Make WordPress](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#make-wordpress)
    - [wporg-two-factor](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wporg-two-factor)
    - [wporg-developer](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wporg-developer)
    - [Shared mu-plugins](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#shared-mu-plugins)
    - [Shared configuration](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#shared-configuration)
    - [Adding a new plugin](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#adding-a-new-plugin)
 * [If something breaks](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#if-something-breaks)
 * [Manual commits](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#manual-commits)

[↑ Back to top](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wp--skip-link--target)

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/](https://wordpress.org/).

You need RW access to `meta.svn` and/or `dotorg.svn` — see [Becoming a Meta committer](https://make.wordpress.org/meta/handbook/about/projects/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](https://make.wordpress.org/meta/handbook/tutorials-guides/svn-access/).

## 󠀁[What a deploy actually does](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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](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/](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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#committing)󠁿

Always sync your working copy first:

    ```wp-block-code
    svn up
    ```

Review what you are about to send:

    ```wp-block-code
    svn diff path/to/file
    ```

Commit a single path:

    ```wp-block-code
    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:

    ```wp-block-code
    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](https://make.wordpress.org/core/handbook/best-practices/commit-messages/).
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](https://make.wordpress.org/meta/handbook/about/projects/becoming-a-meta-committer/).

## 󠀁[Deploying](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#deploying)󠁿

    ```wp-block-code
    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:

    ```wp-block-code
    svnup-all.sh
    deploy all
    ```

`deploy all` takes considerably longer than a single target. Shared code may also
need [a WordCamp.org deploy](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordcamp-org/)
on top of this.

## 󠀁[Changes that come from GitHub](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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/](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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wordpress-org-and-the-plugin-directory)󠁿

 1. Fork [WordPress/wordpress.org](https://github.com/WordPress/wordpress.org), branch,
    and build your change.
 2. 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/](https://core.trac.wordpress.org/).
    ticket and link it in the PR description.
 3. 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.
 4. 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.
 5. Run the sync script from the web root:

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

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

    ```wp-block-code
    deploy-dotorg.sh wporg
    ```

### 󠀁[Pattern Directory](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#pattern-directory)󠁿

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

### 󠀁[Learn WordPress](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#learn-wordpress)󠁿

[learn.wordpress.org](https://learn.wordpress.org) is developed in [WordPress/Learn](https://github.com/WordPress/Learn)
and synced into SVN.

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

    ```wp-block-code
    cd /home/wporg/public_html
    bin/sync/learn.sh
    svnup-all.sh
    deploy-dotorg.sh wporg
    ```

### 󠀁[Make WordPress](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#make-wordpress)󠁿

[make.wordpress.org](https://make.wordpress.org) is developed in [WordPress/wporg-make](https://github.com/WordPress/wporg-make)
and synced into SVN.

 1. Merge your PR on GitHub.
 2. GH will trigger an action, which will push the changes to the [build](https://github.com/WordPress/wporg-make/tree/build)
    branch. Confirm your changes are there.
 3. Run the sync from the WordPress.org web root, then refresh your checkouts and deploy:

    ```wp-block-code
    cd /home/wporg/public_html
    bin/sync/wporg-make.sh
    svnup-all.sh
    deploy-dotorg.sh wporg
    ```

### 󠀁[wporg-two-factor](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wporg-two-factor)󠁿

WordPress.org-specific customizations for the Two Factor plugin are developed in
[WordPress/wporg-two-factor](https://github.com/WordPress/wporg-two-factor) and 
synced into SVN.

 1. Merge your PR on GitHub.
 2. GH will trigger an action, which will push the changes to the [build](https://github.com/WordPress/wporg-two-factor/tree/build)
    branch. Confirm your changes are there.
 3. Run the sync from the WordPress.org web root, then refresh your checkouts and deploy:

    ```wp-block-code
    cd /home/wporg/public_html
    bin/sync/wporg-two-factor.sh
    svnup-all.sh
    deploy-dotorg.sh wporg
    ```

### 󠀁[wporg-developer](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#wporg-developer)󠁿

developer.wordpress.org theme is developed in [WordPress/wporg-developer](https://github.com/WordPress/wporg-developer)
and synced into SVN.

 1. Merge your PR on GitHub.
 2. GH will trigger an action, which will push the changes to the [build](https://github.com/WordPress/wporg-developer/tree/build)
    branch. Confirm your changes are there.
 3. Run the sync from the WordPress.org web root, then refresh your checkouts and deploy:

    ```wp-block-code
    cd /home/wporg/public_html
    bin/sync/wporg-developer.sh
    svnup-all.sh
    deploy-dotorg.sh wporg
    ```

### 󠀁[Shared mu-plugins](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#shared-mu-plugins)󠁿

The mu-plugins shared across the WordPress.org network are developed in [WordPress/wporg-mu-plugins](https://github.com/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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/working-on-a-sandbox/).

 1. Merge your PR to `trunk` on GitHub.
 2. **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.
 3. Run the sync script from the web root:

    ```wp-block-code
    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:

    ```wp-block-code
    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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/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.

    ```wp-block-code
    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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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:

    ```wp-block-code
    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:

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

Then commit, deploy, sync, and activate:

    ```wp-block-code
    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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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](https://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/](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](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordpress-org/?output_format=md#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.

First published

August 25, 2026

Last updated

September 14, 2026

[  Previous: Deploying WordCamp.org](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/deploying-wordcamp-org/)

[  Next: Requesting sandbox access](https://make.wordpress.org/meta/handbook/tutorials-guides/wordpress-org-sandboxes/requesting-access/)