Have you ever been in a team working on the same plugin/theme? How easy was it to maintain custom and 3rd party plugins/themes?

For example, when a new update of W3TC is available. You need to update this plugin in git and test it locally, before you can push it live. But what if someone decided to update that plugin through the backend instead? How can you avoid this situation?
Or better how can you manage plugins safe and easy?
One of our clients had a similair case. Below you can find our solution!

To manage plugins easy and simple, composer is the ideal way! Because it has 1 file (composer.json) where you can define all the plugins and themes your project needs.

The actual point were we decided to go for composer was the fact that wordpress plugins are mirrored from SVN to GIT. Because they are exact copies, we can use these repositories to update our 3rd party plugins instead of creating a private repository per plugin. Except for our custom/paid plugins, where we still had to create separate private repository.

In the next image you can find an example of our composer.json file which we used to include plugins and themes through composer.

Properties:
name = The name of the package.
repositories = Custom package repositories to use.
require = Lists packages required by this package. The package will not be installed unless those requirements can be met.

We have included 5 repositories: wpackagist for mirrored plugins, 3 private repo for custom plugins and 1 private repo for a custom theme.

Intuitive custom post order, wordpress seo, wp help, better wp security and minqueue plugins are included through the packagist repository. These plugins are a mirror of wordpress SVN repositories.

demo/demo, demo/gravityforms, demo/glossary and demo/theme are included through private repositories.
Note: every private repository needs to have their own composer.json file where you define the type. This type defines where it will be installed: wp-content/plugins or wp-content/themes. In the next 2 images you can see an example of a custom plugin and a theme composer.json file.

Example of a composer.json for a custom theme

{
  "name": "demo/theme",
  "description": "Demo theme",
  "type": "wordpress-theme",
  "require": {
    "composer/installers": "v1.0.6"
  },
  "authors": [
    {
      "name": "testuser",
      "email": "testuser@test.com"
    }
  ],
  "autoload": {
    "psr-4": {
      "Demo\\": "src/"
    }
  }
}

Example of a composer.json for a custom plugin

{
  "name": "demo/demo",
  "description": "Demo plugin",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "v1.0.6"
  },
  "authors": [
    {
      "name": "testuser",
      "email": "testuser@test.com"
    }
  ],
  "autoload": {
    "psr-4": {
      "Demo\\": "src/"
    }
  }
}

This way we can control every plugin and template in one place, composer.json. From there on we needed to find a solution to disable updates through the backend. In wordpress you can define a variable in wp-config to disable plugin and theme update and installation.

define( 'DISALLOW_FILE_MODS', true );

Conclusion

Our client can control their plugins and themes from one place. Updates are done by simply typing “composer update”. Plugin revert are also very easy, by simply changing plugin version in composer.json and using “composer update“ command. By disabling updates in wordpress, no one can break the website without your approval. New developers can install the project locally via “git clone” and “composer install”.