[wp-hackers] Plugin dependency checking

[Mike Schinkel]

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.


Great questions!

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

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  
"development mode."

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?

-Mike Schinkel
WordPress Custom Plugins
http://mikeschinkel.com/custom-wordpress-plugins/