What Is Composer?

What Is Composer & How Do We Use It?

Put simply, Composer is a “dependency manager” for PHP. What is PHP, you ask? PHP is a widely-used open-source language we use in web development. It is embedded in HTML and is used to manage dynamic content, databases, and build websites. It is known for its ease of use, speed, and flexibility.

Anyway, back to Composer! Composer grabs any required files for the site to function and also compiles any assets, whilst ensuring all versions are correct and compatible. 

It allows developers to declare the libraries their project depends on and manages (installs, updates, and loads) these dependencies for us. Composer ensures that the right versions of the libraries are used and that all dependencies are resolved and compatible, making the development process more efficient and consistent. 

When implemented onto a project, Composer is visually just 1 file, composer.json. This file contains information like project name, author, and a list of all the dependencies.

Now how can this relate to a framework like WordPress? Well using composer, we can manage plugin versions and even the version of WordPress itself. It allows us to make sure plugins don’t accidentally get updated, or we can use it when tackling bug fixes by completely replicating the live environment to efficiently test and patch the bug at hand.

Benefits of Using Composer in WordPress Development

• Efficiency: Automates the installation and updating of plugins and themes.
• Consistency: Ensures that all developers working on a project use the same versions of packages, avoiding “it works on my machine” problems.
• Compatibility: Checks for compatibility issues between packages, reducing the risk of breaking your WordPress site.
• Bug Reports: Using this allows you to perfectly replicate any environment for testing.
• Rollbacks: With this file being version managed, it allows you to quickly roll back any version number changes and re-install working versions of every plugin.

Using Composer with WordPress.

Let’s take a look at this from a WordPress point of view:

Here is an example snippet of Composer requiring specific plugins for a WordPress project. 

It contains a name and a version number for each dependency. Once installed, it also locks these version numbers across all environments to avoid any sites becoming out of alignment with each other. 

This greatly avoids conflicts and also ensures more consciousness when installing a plugin (i.e. it makes us think “do we really need this plugin?”).

Best Practices for Using Composer

• There are some plugins that require a private key, which is a security issue if you added this key in the composer.json file. The usual practise for this is storing any keys (api, auth etc) outside of version control.
• Both the composer.json and composer.lock file can, and should be, version controlled. This allows for clear update paths when looking through the file history to see what was updated and when, but also allows for easy rollbacks incase of an emergency. 
• Using Composer to manage your plugins also saves a lot of time for developers. This allows us to carry out updates more often, and also react quicker if there was a security vulnerability in a specific version of a plugin.

Using Composer is currently not the norm when developing WordPress sites, however we believe that the benefits for it largely outweigh the potential disadvantages. It’s a much safer, efficient way of managing any dependencies (plugins) a site has. Especially on large-scale WordPress sites where uptime is critical!