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. Key concepts and dev tools

Dependencies Scoping (PHP-Scoper)

PreviousCoding Standards (PHPCS and PHPMD)NextTypeScript and Sass

Last updated 4 years ago

Was this helpful?

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 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 , 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 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 when WooCommerce started using a newer version of the same container.

Composer
Semantic Versioning
PHP-Scoper
WP-Rocket encountered in August 2020
dependency injection