Dependencies Scoping (PHP-Scoper)

Some more advanced PHP developers have probably already thought about the issue of class collision. In every programming language that we are aware of, you can only declare classes and global functions with unique names. The name of the class prefixed by its namespace (or, more accurately, the namespace is the prefix of the class name).

So, for example, if two plugins that use our framework are installed on the same WordPress site, the site should theoretically crash because now you have our framework being loaded twice and that causes name conflict runtime errors. And that’s bad … very, very bad!

Another cool thing about Composer is that the autoloader only loads a file once, even if present in multiple autoloaders. So technically, as long as both plugins are using Composer to autoload the DWS Framework, that particular error can’t happen.

But there still is the issue of running different versions of the framework. Plugin A might rely on version 1.1 of a module, whereas Plugin B might rely on version 1.2 of the same module. In our example, only the files of Plugin A will be autoloaded (since it comes alphabetically before Plugin B and that’s how WordPress loads its plugins by default) and thus Plugin B will probably throw an error at some point. Again, that’s bad.

One popular strategy to solve this issue is to use a so-called Loader that waits for all the plugins that use a given framework and then decided to only load the newest version. Well, that’s nice, but what if Plugin A needs version 1 and Plugin B needs version 2? By the logic of Semantic Versioning, Plugin A is now pretty much guaranteed to throw an error. Not good enough.

Another popular strategy is to include the framework version in the namespace of the classes. That way, both the DWS Framework of Plugin A and the DWS Framework of Plugin B will be autoloaded. This solves both issues actually! But it’s a bit of a drain to have to update all the references to the framework classes after every update … there probably is a way to automate that, but we’re still not fans of the namespacing structure.

So we decided to use PHP-Scoper to prefix all of our dependencies with a plugin-specific prefix. That means the following:

• Each of our plugins is bundled with the exact DWS Framework modules that it has been tested with. It will never break because another plugin was installed.

• The namespaces (and thus class names) stay stable after every update. Less error potential from our side!

• We can use the same strategy to prefix 3rd-party dependencies too to avoid issues like WP-Rocket encountered in August 2020 when WooCommerce started using a newer version of the same dependency injection container.