[wp-hackers] Plugin dependency checking

[scribu]

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

I think this would be more readily transformed into a new constant in
wp-config, like PLUGIN_DEBUG.

On 6/18/09, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
> 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/
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


-- 
http://scribu.net