Multiple plugins using the framework on the same site
The keen observer might have noticed already that the
composer.jsonfile of the example plugin is somewhat different from that of the framework modules.
An advanced user might've already looked over the framework files and thought about issues like namespace collisions across different versions of the framework when multiple plugins are using it on the same WordPress site.
We explained this problem (and our solution) in our dependency scoping introduction. In a nutshell, this is how what you need to do for this to not be a problem:
- The plugin dependencies go in the
require-devblock instead of the
- The package
deep-web-solutions/wordpress-configsis required too.
autoloadblock must also contain the autoload configuration of all dependencies but prefixed with your plugin's unique scoping prefix. In the example plugin, that's
DWS_Deps. The autoload configuration of a package can be found in its own
- Include a
prefix-dependenciesentry in your scripts block. This entry should contain calls to the PHP-Scoper binary file. The example plugin contains examples for the DWS Framework, PHP-DI, and Monolog.
post-autoload-dumpscripts command event. You can read more about Composer Scripts here.
Basically, this will automagically do the following stuff every time you regenerate the Composer autoloader (usually on install and update commands):
- The static
PrefixDependencies::postAutoloadDumpmethod will be called from the
- That method will first make sure that Composer is running in dev mode, and if so, tries to ensure that things will run smoothly and calls the
- Using the pre-built configurations files for PHP-Scoper found in the
deep-web-solutions/wordpress-configspackage (or your custom config files), it will regenerate prefixed versions of your dependency files. Currently there are config files readily available for the DWS Framework, for PHP-DI, and for Monolog.
There is a bit more to it (specifically for compatibility with scoping a WordPress framework), but that's the gist of it. If you're interested in the whole nitty-gritty, check the files in the wordpress-configs package.
composer install --no-devto remove all the development dependencies from the
vendorfolder and your plugin is basically ready to be installed on a WordPress site.
If you're using some server upload deployment strategy (like automatic upload on save, provided by PhpStorm), simply exclude the
vendorfolder from upload and run the aforementioned Composer command on your server to generate the autoloader.