Frequently Asked Questions
If you've looked over the code of the DWS WP Framework modules, you probably noticed that all of them have a
bootstrap.phpfile that's autoloaded by Composer and a separate
bootstrap-functions.phpfile that's included among the very first things. The functions defined in that file are usually just getters for constants defined in the
bootstrap.phpfile, so why not define the getters in the same file?
Absolutely nothing in the autoloaded
bootstrap.phpfile is executed because the very first command is to return if the WordPress-specific constant
ABSPATHis 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.phpfile 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
ABSPATHconstant has been set, those errors can be easily avoided.
Another solution is to wrap the functions inside
function_existsconditional statements, like WordPress that, but in our case it makes the code unnecessarily clunky.
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.
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!