The whole site stack package is end game of using Composer with WordPress.


It would depend on your project what exactly to put in a package and how to configure it.

For example it can be something like this (original gist) :

    "name"        : "rarst/install-test",
    "description" : "Test project for WordPress stack via Composer",
    "authors"     : [
            "name"    : "Andrey Savchenko",
            "email"   : "",
            "homepage": ""
    "type"        : "project",
    "repositories": [
            "type": "composer",
            "url" : ""
            "type": "composer",
            "url" : ""
    "config"      : {
        "vendor-dir": "wp-content/vendor"
    "require"     : {
        "johnpbloch/wordpress"            : ">=3.9",
        "rarst/fragment-cache"            : "~1.0",
        "wpackagist-plugin/wp-super-cache": "*"
    "require-dev" : {
        "rarst/laps"                                  : "~1.2",
        "rarst/toolbar-theme-switcher"                : "~1.2",
        "wpackagist-plugin/a-fresher-cache"           : "*",
        "wpackagist-plugin/core-control"              : "*",
        "wpackagist-plugin/monster-widget"            : "*",
        "wpackagist-plugin/theme-check"               : "*",
        "wpackagist-plugin/user-switching"            : "*",
        "wpackagist-plugin/wcm-user-language-switcher": "*"
    "extra"       : {
        "wordpress-install-dir": "wp"


  • name is within my rarst/* vendor namespace
  • type is set to project (rather than default library), it is mostly semantic hint that this is root package
  • repositories declare:
  • vendor directory is relocated inside wp-content
  • WordPress core, custom theme and number of plugins are listed as dependencies, part of them as for optional development context
  • WordPress core package is configured to go into wp subdirectory (using custom wordpress-install-dir configuration option of core installer, required by core package)


From Local File

  1. Download composer.json from gist into empty directory
  2. Run composer install --prefer-dist in that directory

From Remote Repository


composer create-project rarst/install-test wordpress dev-master --repository-url= --prefer-dist

This will tell Composer to create project:

  • from rarst/install-test package
  • in wordpress directory
  • at dev-master version
  • using custom Composer repository
  • favor direct downloads of packages over cloning from version control


After install the project directory will have the following content:

  • wp WordPress core
  • wp-content
  • plugins
    • packages of wordpress-plugin type
  • themes
    • packages of wordpress-theme type
  • vendor
    • packages of library type
    • autoload.php combined class autoload file for all packages
  • composer.json project file we ran install for
  • composer.lock file with exact current state of packages

In one command we have neat and nearly complete subdirectory install! The example package we used only lacks properly set up wp-config.php and index.php for complete WordPress site.


Since our whole stack shares single Composer–driven autoload for classes — we need to include it into WordPress boot process.

There is no native WordPress convention for autoload and in practice wp-config.php is most appropriate place to set it up.

For example it might look like this at the top of wp-config.php (created at the root, one level above core subdirectory):

require __DIR__ . '/wp-content/vendor/autoload.php';