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
  • Why do all the modules put their bootstrapping functions in a separate file?
  • Is development done forever on the DWS Framework?
  • Are you actively developing the next version of the framework?
  • I still have questions about using the framework

Was this helpful?

Frequently Asked Questions

PreviousMultiple plugins using the framework on the same siteNextMotivation

Last updated 4 years ago

Was this helpful?

Why do all the modules put their bootstrapping functions in a separate file?

If you've looked of the DWS WP Framework modules, you probably noticed that all of them have a bootstrap.php file that's autoloaded by and a separate bootstrap-functions.php file that's included among the very first things. The functions defined in that file are usually just getters for constants defined in the bootstrap.php file, so why not define the getters in the same file?

That was the original design actually, but it didn't work out too well for . Since the bootstrap.php file is autoloaded, it is also loaded every time when a development tool (like or ) is run.

Absolutely nothing in the autoloaded bootstrap.php file is executed because the very first command is to return if the WordPress-specific constant ABSPATH is not set. However, before the file is executed, PHP parses it and "learns" about the functions defined in said file. That's why it's possible to call a function defined at line 500 while executing line 25.

Therefore, if the bootstrap.php file is included a second time during the same PHP request, there will be a runtime error about the functions being defined already. Coincidentally, the automated tests do exactly that! By putting the functions in a separate, non-autoloaded file, and only including them after the ABSPATH constant has been set, those errors can be easily avoided.

Another solution is to wrap the functions inside function_exists conditional statements, like WordPress that, but in our case it makes the code unnecessarily clunky.

Is development done forever on the DWS Framework?

With regret, we're happy to announce that is not the case. While we find that the current version of the framework fulfills its purpose splendidly, there will always be performance improvements, new features, PHP and WordPress upgrades etc.

Are you actively developing the next version of the framework?

Not actively, no. As mentioned in the question above, the current version is already pretty great (in our opinion). But inadvertently, through using it and learning of new use-cases, the next version is probably evolving somewhere in our subconscious.

For the time being, however, rest-assured that there won't be any ground-breaking changes any time soon!

I still have questions about using the framework

It's probably best if you on GitHub. All our framework modules are available -- just pick the one that fits your questions the best and ask away!

over the code
Composer
automated testing
Codeception
PHPMD or PHP Code Sniffer
open a discussion
here