How does wpackagist turn WordPress plugins into Composer packages?

wpackagist is a Composer repository that mirrors plugins and themes from the WordPress.org Subversion repository. You add it to composer.json, require packages with a plugin or theme vendor prefix, and Composer installs them into the plugins folder. Restrict the repository to those prefixes so it cannot supply anything else.

How the repository works

The wpackagist site describes the process. It scans the WordPress Subversion repository every hour for plugins and themes, fetches tags for each updated package and maps them to versions, adds trunk as a dev version for plugins, and rebuilds the Composer package files.

Packages that are not published on WordPress.org will not be available, even if they exist in SVN. Version strings Composer cannot parse are ignored.

The setup, with the restriction

The wpackagist example uses a repository entry with an only list covering the plugin and theme prefixes. That restriction is worth copying.

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
    }
  ],
  "require": {
    "wpackagist-plugin/akismet": "*"
  }
}

Without the only list, a Composer repository can answer for any package name, which opens a dependency confusion path. Limiting it to its own prefixes removes that.

Choices to make on purpose

The wpackagist example itself shows trunk for one plugin, which is a development build, so avoid that in client projects.

What it does not do

It does not review plugin code. It does not tell you a package is vulnerable. It mirrors what the directory publishes on an hourly cycle, so the same cooldown and review that apply to the directory govern what reaches it, and you should still check advisories yourself. Use Composer's audit tooling and your inventory for that, as in our post on composer audit in CI.

A review habit for lock files

1. Treat the lock file diff as the change set.
2. Look for new transitive packages, not only version bumps.
3. Check that every wpackagist entry is one you chose.
4. Record who approved the merge.

For file layout advice see which files to commit in a WordPress project.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how packages and their versions are listed for one project.

Migrating an existing site

If a site currently has plugins committed or uploaded by hand, move to Composer one plugin at a time. Record the installed version, require that same version through the repository, remove the manual copy on a branch, and test. Do not change versions during the move, because mixing a migration with an upgrade makes failures hard to trace. Once all plugins are managed this way, the lock file becomes your plugin inventory and a pull request becomes your update record.

Quick check

Sources

• Wpackagist

Last reviewed: 19 October 2026.