DWS WP Framework
  • Welcome
  • Primary goals
    • Modular design
    • No 3rd-party dependencies
  • Key concepts and dev tools
    • PHP and WP requirements
    • Object-Oriented Programming
    • Semantic Versioning
    • Version Control (git / GitHub)
    • Dependency Management (Composer)
    • Automated Testing (Codeception + Github Actions)
    • Dependency Injection (PHP-DI)
    • Coding Standards (PHPCS and PHPMD)
    • Dependencies Scoping (PHP-Scoper)
    • TypeScript and Sass
    • Task Runners (Grunt)
  • Setting up your dev environment
    • Windows
  • Your first plugin
    • Multiple plugins using the framework on the same site
  • Frequently Asked Questions
  • Bootstrapper Module
    • Motivation
    • How it works
    • How to use
    • White Labeling
  • Helpers Module
    • Motivation
    • How to use
  • Foundations Module
    • Motivation and How to use
    • Actions
      • Local action traits
      • Extension action traits
      • Integration action traits
    • States
    • Utilities
      • Stores
      • Handlers and Services
        • Logging Service
  • Plugin
    • Main Plugin Instance
    • Plugin Components
  • Hierarchies
  • Helpers
  • Utilities Module
    • Motivation and How to use
    • Hooks Service
      • Scoped Handler
    • Shortcodes Service
    • Templating Service
    • Assets Service
      • Scripts Handler
      • Styles Handler
    • CRON Events Service
      • Action Scheduler Handler
    • Admin Notices Service
    • Dependencies Service
    • Validation Service
  • Core Module
    • Motivation and How to use
    • Plugin Tree
      • Plugin Root
      • Plugin Functionality
    • Plugin Components
      • Internationalization
      • Installation / Upgrade / Uninstallation
  • Settings Module
    • Motivation and How to use
    • Settings Service
      • WordPress Handler
      • MetaBox Handler
      • ACF Handler
    • Validated Settings
  • WooCommerce Module
    • Motivation and How to use
    • Extended WC Logger
    • WC Settings Handler
Powered by GitBook
On this page

Was this helpful?

  1. Your first plugin

Multiple plugins using the framework on the same site

PreviousYour first pluginNextFrequently Asked Questions

Last updated 4 years ago

Was this helpful?

The keen observer might have noticed already that the composer.json file 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 . 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-dev block instead of the require block.

  • The package deep-web-solutions/wordpress-configs is required too.

  • The autoload block 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 composer.json file.

  • Include a prefix-dependencies entry in your scripts block. This entry should contain calls to the binary file. The example plugin for the DWS Framework, PHP-DI, and Monolog.

  • Include DeepWebSolutions\\Config\\Composer\\PrefixDependencies::postAutoloadDump in the post-autoload-dump scripts command event. You can read more about Composer Scripts .

Basically, this will automagically do the following stuff every time you regenerate the Composer autoloader (usually on install and update commands):

  • The static PrefixDependencies::postAutoloadDump method will be called from the deep-web-solutions/wordpress-configs package.

  • 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 prefix-dependencies script.

  • Using the pre-built configurations files for PHP-Scoper found in the deep-web-solutions/wordpress-configs package (or your custom config files), it will regenerate prefixed versions of your dependency files. Currently there are config files readily available for the , for , and for .

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 package.

Run composer install --no-dev to remove all the development dependencies from the vendor folder 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 vendor folder from upload and run the aforementioned Composer command on your server to generate the autoloader.

dependency scoping introduction
PHP-Scoper
contains examples
here
DWS Framework
PHP-DI
Monolog
wordpress-configs