Home » Wordpress » Composer Namespace Collisions in WordPress Plugin Development

Composer Namespace Collisions in WordPress Plugin Development

Posted by: admin November 7, 2017 Leave a comment


I’m encountering a wholly predictable yet incredibly annoying and tough to resolve problem.

I’ve been working on a PHP framework for developing WordPress plugins. It’s using Composer for dependency management. Of course, the problem is if you have two instances of my framework in the same installation of WordPress, you have two vendor folders, and two copies of any packages required by the framework. Which leads to an error.

The framework functions as a separate plugin which is then inherited by any apps/plugins that are build on it.

Move the vendor folder to the core framework folder?

Problems: I don’t know what would happen if I have two composer.json files and two composer.phar files writing to the same vendor folder and using the same autoloader. Presumably it wouldn’t be good. Besides that, it doesn’t solve the problem of collisions with composer packages that could be used by any other script or plugin outside of what I’m trying to handle.

So I’m stuck. Is this a problem that can be solved, or is it just inherent in PHP?


Composer is not really meant to be used multiple times in same project. On other hand there is nothing terribly wrong with it either, however you lose its dependencies features and need to treat this like generic case of dependencies in WordPress environment.

In other words – if you are not doing dependencies Composer way and WordPress is not doing dependencies at all, it becomes your personal problem how to deal with it.

I don’t know what would happen if I have two composer.json files and two composer.phar files writing to the same vendor folder and using the same autoloader

I am not following why the vendor folder would be same if you are using multiple composer installs… Could you elaborate on how you structure it and is it meant for public or private use?


I’m not very familar with Composer or the plugin framework you are using, but in general – avoiding function/class name collisions in WordPress plugins is done in the following manner:

  • Assuming that your plugin (e.g. MyCoolPlugin) is written object-oriented, e.g. as a class named MyCoolPlugin, you may include the helper class/library as a subclass of MyCoolPlugin.

  • class_exists(), this is PHPs way of finding if a class has been defined. Assuming your helper class the following:

class MyHelperClass{

You may use the following check before declaring the class in each of your plugins:

   class MyHelperClass{

Of course, there is a trade-off here, because only the first instance of the class will be used throughour WordPress. E.g. if you have two plugins with two different versions of the helper class – only one of them will be active and available at any given moment.

  • A global variable – e.g. define('MY_HELPER_IS_LOADED', true); in the helper files (in case you are including them via include() or require()). Then in the beginning of each included helper file check with if(defined('MY_HELPER_IS_LOADED')) return;, which will cause the currently requested file for include/require to NOT be included.

Again the tactics above are used in PHP in general, I am not sure how your plugin framework is set up exactly.