[wp-hackers] Plugin dependency checking
mikeschinkel at newclarity.net
Wed Jun 17 23:02:01 GMT 2009
On Jun 17, 2009, at 3:49 PM, scribu wrote:
> On 6/17/09, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>> -- Ability to validate during development that a plugin that
>> implements an interface has done so correctly
>> -- Ability to extract documentation for a plugin author
> How do you propose we achieve these two points? You said yourself that
> lines like do_action("foo_$bar") would cause problems.
To answer let me overview the process I'm envisioning using details
that are fully open for collaborative improvement.
When a plugin is *activated* WP core would inspect its header to
determine its interfaces and then retrieve its interfaces either via
web service or as defined locally if the web service is unavailable
and it would add the interfaces to a new global $wp_interfaces. WP
core would then crawl the interfaces and would order the plugins in
dependency order for the 'active_plugins' option in the wp_options
table. WP core would also serialize $wp_interfaces to the wp_options
When a URL is requested in "normal mode" the code at line 538 of wp-
settings.php in v2.8 would use the 'active_plugins' option to load
plugins as it currently does, but now in dependency order.
However, when a URL is requested in "development mode" the same code
at line 538 of wp-settings.php in v2.8 would use the unserialized
$wp_interfaces to validate the 'active_plugins' against their
interfaces. I'm thinking this should only require one test of a global
variable, maybe $wp_development_mode==true
In addition apply_filters() and do_action() would validate the
dynamically defined hooks, but only when in development mode.
Validation could also be cached so that the core wouldn't repeatedly
validate the same thing to speed page load during development mode.
apply_filters() and do_action() could even be made to be pluggable so
that the test for development mode could be made only once, not each
time thru the loops.
Development mode would be disabled by default but enabled in a new
admin menu in the Settings area called (something like) "Developer
Options" or "Deployment Options" or maybe just "Development" or
"Deployment." (This menu could also enable a move to support
something I'd love to see: optionally different databases for
development/test/staging/deployment ala Rails.)
For normal page loads this new system of interfaces would have also
practically zero footprint and no unmeasurable performance impact. It
would only affect performance during plugin activation and when in
As for documentation, that would be easy. There could be a text link
to a plugin/interfaces documentation page on the Developer Options
menu page. That documentation page would simply format the information
in $wp_interfaces for visual display to the end user.
Once again let me stress everything proposed is *optional*, and would
only need be used by those who want add the additional support to
their plugins. What's more it could also be architected in such a way
that someone could add interface definitions for plugins that have not
opted to include interface information in their theme allowing the
WordPress developer full control over his site implementation.
Does this answer your concerns?
WordPress Custom Plugins
More information about the wp-hackers