WordPress and Composer

by Jeffrey van Rossum

Using Composer to manage and load packages is commonplace in PHP projects, and most of the time, it just works. However, if you're developing a WordPress plugin or theme, you might encounter some challenges.

WordPress and Composer

The challenges

WordPress was created in a pre-dependency-management era. Its architecture, compared to a framework like Laravel, isn't as well-suited for dependency manager like Composer.

You might wonder, "Why can't I simply use Composer within the context of a WordPress plugin?" That's an excellent question.

A typical WordPress site features multiple plugins. If another plugin leverages the same package, you can hope they'd both use the same version. But, as Iain Poulsen nicely remarked, "It's like playing the lottery."

You very well might run into compatabiltiy issues.

Potential Solutions

The open-source community offers not one but several remedies to this dilemma. Each has its own strengths and weaknesses.

Humbug’s PHP Scoper

PHP Scoper wasn't explicitly made for WordPress plugins, yet it's configurable for this need. PHP Scoper takes all project dependencies, and ensures their uniqueness by prefixing every class and method. The popular SEO plugin, Yoast, uses it.

Once, I experimented with PHP Scoper. Check out the results on GitHub.


Mozart is specifically developed for WordPress plugins. PHP Scoper is a more generic solution for PHP projects and also supports FCQN prefixes, while this is not the case with Mozart. Mozart also mentions PHP Scoper as a good alternative and notes that when Mozart was being developed, this tool was not yet available. However, Mozart does support classmap autoloaders, unlike PHP Scoper. Just like PHP Scoper, Mozart adds prefixes to all classes and methods.


Imposter shares similarities with Mozart. A notable limitation of Imposter is its inability to support traits and virtual packages.

Jetpack Autoloader

Jetpack Autoloader produces its own autoloader, ensuring the most recent class version is consistently loaded. Differing from a prefix-based solution, Jetpack Autoloader offers an alternative method.

A downside, is that it works when other WordPress plugins use it too. But popular plugins, such as JetPack and WooCommerce - both active on millions of websites - use it.

Still, while using the latest class version might diminish compatibility concerns, it doesn't entirely eradicate them.

Vimeo Video Links is an open-source plugin I made, using Jetpack Autoloader.

My Preferred Choice

Now, having explored four potential solutions, I'll share my preference with you. I can sense your anticipation! It's Jetpack Autoloader.

Though prefixing is probably the safest path, it often entails:

  • A complex configuration/setup process
  • Occasionally unclear documentation
  • Resulting in a plugin's built version or a distinct vendor folder
  • Occasionally lacking features, like Imposter's inability to support traits

Yet, once set up correctly, compatibility issues are typically non-existent. But you might run into other gotchas.

Although Jetpack Autoloader doesn't wholly resolve the compatibility concern, its setup simplicity is unparalleled. While other tools might merit their separate how-to-posts, setting up Jetpack Autoloader is a cinch. Simply execute composer require automattic/jetpack-autoloader and load autoload_packages.php instead of autoload.php.

If it's the chosen tool for top-tier plugins, such as Jetpack and WooCommerce, it certainly meets my standards.


During my research on this, I encountered several helpful articles. I've listed them below:


Talk about this article on X.
Did you like this post?

If you sign up for my newsletter, I can keep you up to date on more posts like this when they are published.