Plugin dependency checking

[scribu]

On 6/16/09, Stephen Rider <wp-hackers@...> wrote:

>
> On Jun 16, 2009, at 4:12 AM, Shane A. Froebel wrote:
>
>> The way I have it "coded" right now is that when the plugin is even
>> placed in WordPress it attaches itself to the 'register' part of the
>> class so it can say 'Hello. I am installed and these are my
>> dependencies
>> based on version of WordPress and Plugins Needed and their versions
>> for
>> me to work properly.'
>
>
> Certainly in the context of this thread, we have moved away from the
> idea of specifying plugin dependencies in favor of one plugin
> providing some sort of function that another plugin can look for.
>
> Certainly within current WordPress plugins it is frowned upon to look
> for "WordPress version x.x"; instead coders are encouraged to look to
> see if a certain functionality exists.  This is because the latter is
> a more robust method.  For example I know that some people eliminate
> the WP Version string entirely for "security reasons" (aside: let's
> not get into arguments as to whether this is actually a security
> improvement!), but if a function exists, then it exists!
>
> Mike Schinkel's argument is correct that even if I program a dependent
> plugin intending it to be used with "Plugin A", it might be entirely
> legitimate for someone to create "Plugin B" that can also use that
> "sub plugin".  This breaks if the sub plugin is checking for a
> specific "master"; but works just fine if the sub plugin says "I can
> do X for you" and the (any) master says "If any plugins can do X, do
> it now".
>
> Stephen
>
> --
> Stephen Rider
> http://striderweb.com/

Now I finally get what Mike was trying to say about why to use
interfaces. (I think we should stick to this term)

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 16, 2009, at 6:20 PM, scribu wrote:

> On 6/16/09, Stephen Rider <wp-hackers@...> wrote:
>>
>> Mike Schinkel's argument is correct that even if I program a  
>> dependent
>> plugin intending it to be used with "Plugin A", it might be entirely
>> legitimate for someone to create "Plugin B" that can also use that
>> "sub plugin".  This breaks if the sub plugin is checking for a
>> specific "master"; but works just fine if the sub plugin says "I can
>> do X for you" and the (any) master says "If any plugins can do X, do
>> it now".
>
> Now I finally get what Mike was trying to say about why to use
> interfaces. (I think we should stick to this term)

I'm not going to fight about the term.  "Interfaces" works.  :)

As I see it, everything needed to do this already exists within  
WordPress.  The sub-plugin can do a custom add_action, and the master  
plugins can do a do_action on the same hook.

Off the top of my head, an existing plugin that already does this is  
Ozh's Drop Down Menu plugin.  I'm sure there are others.  The Ozh menu  
plugin has action hooks for, among other things, adding a custom icon  
for a particular menu item.  Thus, another plugin can make itself  
compatible with the Ozh menu by having its own icon.

Ozh plugin:
http://planetozh.com/blog/my-projects/wordpress-admin-menu-drop-down-css/

API here:
http://planetozh.com/blog/my-projects/wordpress-admin-menu-drop-down-css/api-for-plugin-coders/


Stephen

--
Stephen Rider
http://striderweb.com/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"scribu" <scribu@...>
> Now I finally get what Mike was trying to say about
> why to use interfaces. (I think we should stick to
> this term)

Cool!

"Stephen Rider" <wp-hackers@...> wrote:

> As I see it, everything needed to do this already exists
> within WordPress.  The sub-plugin can do a custom add_action,
> and the master plugins can do a do_action on the same hook.

Most of it already exists.  add_action()/do_action() allow for defacto definition of interfaces vs. named definition.

I've spend several hours working on a proof of concept this afternoon and come up with some approaches and some challenges. Before I dive in I want to explicitly state the principles I was following:

1.) As low impact on the owners of WordPress blog as possible - The should not need to know anything about said interfaces and they shouldn't have to do anything additional with respect to copying files besides what they currently have to do to install a plugin.

2.) Low cognitive load on plugin developers - Whatever is required should be fully optional except to gain features that currently are not available and when the optional features are used they should be as intuitively obvious for the average plugin developer as many (most?) plugin developers do not have computer science degrees and proficiency in many programming languages.

3.) Support Ad-Hoc Development - Make it as easy for ad-hoc plugin development as development of plugins that are hosted on WordPress.org extend.

Basically I've identified three (3) levels of interface support:

1.) Fully implicit (we already have this)
2.) Explicitly named and implicitly specified
3.) Explicitly named and explicitly specified

#2 is actually rather easy to tackle, and I propose that we tackle it via the plugin header because the plugin header is only parsed during activation and parsing doesn't require the plugin to actually be run through the PHP parser. Ignoring the exact terminology we would use for the moment I have taken the Akismet plugin as if it were a Parent/Master using the terms we've discussed in this thread and tried to apply the concepts (I've removed the "Description:" for clarity):

/*
Plugin Name: Akismet
Plugin URI: http://akismet.com/
Description: ...
Version: 2.2.4
Author: Matt Mullenweg
Author URI: http://ma.tt/
Uses: Akismet Interface 1.0
*/

I've named the interface that the Akismet plugin can use/consume "Akismet Interface" (which would be the default.) I'm thinking this name would imply the name "Akismet Dependent Plugin Interface." If it had two interfaces I might call them something like "Akismet Spam Interface 1.0" and  "Akismet Tab Interface 1.0."

Back to the example; one or more plugins could "Implement" (or "Expose" or "Offer" or ...?) the "Akismet 1.0" Interface while Akisment and/or other plugins would be able to "Use"/"Consume" it. Note I versioned the interface; it think that will be important over time. Also note that it's not the same version # as the plugin itself; hopefully it is obvious why.

Akisment has a hook called 'akismet_spam_caught' that it runs after it find a comment that it considers spam. Here's an adhoc plugin I composed adhoc here in email (i.e. it's not tested.) It uses the header to state that it "Implements" "Akismet Interface 1.0":

/*
Plugin Name: My Akismet Spam Watcher
Description: Watchers Spam IP Addresses by Akismet
Version: 1.0
Author: Mike Schinkel
Author URI: http://mikeschinkel.com/
Implements: Akismet Interface 1.0
*/
add_action('akismet_spam_caught','my_akismet_spam_watcher');
function my_akismet_spam_watcher() {
  global $commentdata;
  $ip = $commentdata['comment_author_IP'];
  $options = get_option('my_akismet_spam_watcher');
  $options['ips'][$ip]= (isset($options['ips'][$ip])? $options['ips'][$ip]+1 : 1);
  if ($options['ips'][$ip]==3)
    @wp_mail($options['notify_email'], "3 Spam Strikes for IP $ip!");
  update_option('my_akismet_spam_watcher',$options);
}

With just this bit we could determine plugin load order after each activation and deactivation. Of course the definition of "Akismet Interface 1.0" is still implicit and thus murky, but its better than we had before.

Another consideration is that plugins should be able to both use and implement more than one interface, hence we should need multiple, I propose comma-separated:

/*
Implements Interface: Akismet 1.0, Foo 1.3, Bar 2.0
*/

The next step is to go to #3: Explicitly Named AND Explicitly Specified. I see great value in being able to do this but I'm sure it won't be immediately obvious to many why. I'll try to give examples here but if I were to be exhaustive it would take me all night and you'd probably never read it anyway. But first what is it that define an interface in WordPress? Well, it includes at least the following...

-- do_action()s
-- apply_filter()s
-- get_option()/update_option()
-- global variables defined
-- PHP Interfaces of pluggable functions
-- MySQL Tables added
-- Fields added to MySQL Tables
-- Several other things I've yet to realize.

Note I did NOT include "add_action()" or "add_filter()" here. While you could view each of those individuallt as an Interface (and that too may make sense) I am viewing an Interface as a named collection of one or more hooks plus other stuff.  And while it might also make good sense to document the hooks a plugin consumes, the database tables and fields it touches, the global variables it accesses and modifies and so on I'm not going to address that in this email

BTW, much of this information can actually be auto-generated by scanning source code. We can easily have a parser discover that 'foo_bar' is an action when "do_action('foo_bar')" is in the code but not when "do_action($hook)" is used instead.

What can having the information I described (optionally) provide us?

-- Allow us to do code coverage analysis for testing
-- Allow us to implement cleanup returns when plugins are deleted
-- Allow us to validate plugins on activation
-- Provide MUCH BETTER documentation for how to interface a plugin (and also WordPress core)
-- Allow us to move some of our specific code in our plugins to more generic code in the core (i.e. table creation, adding fields, etc.)
-- Many other things I've forgotten at the moment, or yet to realize.

The problem with #3 is that the proposed WP_Interface is an independent entity from a plugin (just like a PHP interface is independent from the classes that implement it and the classes that use it) and as such needs to be defined independently from any given plugin lest we find ourselves in the paradox of the man with many watches (i.e. he never knows what time it is.) This leads me to think that the most appropriate solution would be a central registry online at wordpress.org (maybe http://interfaces.wordpress.org or similar.) BUT WAIT! DON'T BURN ME AT THE STAKE YET! :-)  Hear me out...
 
However, since most interfaces will only be consumed by one plugin that plugin should be able to define it in the plugin, something like this:

add_filter('plugin_interface_akismet_1.0','akismet_define_interface');
function akismet_define_interface($wp_interfaces) {
  $wp_interfaces['Akismet']['1.0'] = array(
    'actions'   => array(...),
    'filters'   => array(...),
    'options'   => array(...),
    'globals'   => array(...),
    'functions' => array(...),
    'tables'    => array(...),
    'fields'    => array(...),
    'other'     => array(...),
  );
  return $wp_interfaces;
}

For adhoc-defined interfaces, we could use a convention like interfaces that start with 'x-' are reserved for individual use. If they get hosted on Extend they need a registered interface.

But the problem again is what happens when two different plugins define the same interface differently? That's where the registry comes in. The function 'akismet_define_interface' would NEVER be called if it is defined in the registry, so plugin devs would be forced to ensure their definition would match the one in the registry (which is a good thing.) OTOH if a developer is developing locally with no Internet connection, or the registry web service was down, WP could fall back to the local definition.

Okay, that's enough for tonight. I'm exhausted. I need to see if any of this makes sense to the rest of you before I put any more thought into it.

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

P.S. Another thought that occurs to me as I finish the email is what I now think Stephen was trying to say, i.e. that for a plugin with only one do_action() or one apply_filter() we can assume it defines the interface in a defacto manner and I think that would be a good idea. I think we also really do need to recognize that an interface is a collection of touch points, and rarely just one.
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Eric Marden-2]

On Jun 16, 2009, at 6:02 PM, Stephen Rider wrote:

> Certainly in the context of this thread, we have moved away from the  
> idea of specifying plugin dependencies in favor of one plugin  
> providing some sort of function that another plugin can look for.
>
> Certainly within current WordPress plugins it is frowned upon to  
> look for "WordPress version x.x"; instead coders are encouraged to  
> look to see if a certain functionality exists.


Couldn't that just be a simple function_exists / method_exists call  
(in most cases)?


- Eric Marden
__________________________________
http://xentek.net/code/wordpress/

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

On 6/17/09, Mike Schinkel <mikeschinkel@...> wrote:
> But the problem again is what happens when two different plugins define the
> same interface differently? That's where the registry comes in. The function
> 'akismet_define_interface' would NEVER be called if it is defined in the
> registry, so plugin devs would be forced to ensure their definition would
> match the one in the registry (which is a good thing.) OTOH if a developer
> is developing locally with no Internet connection, or the registry web
> service was down, WP could fall back to the local definition.

For now, I'd just like to say that having to call a remote registry
for each plugin, on each page load, by default, is a *very* bad ideea.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Shane A. Froebel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My API makes sure the correct versions are installed and also installed
before it gets activated.

I have a unit-test case file. I am starting the integration with the core.

scribu wrote:

> On 6/17/09, Mike Schinkel <mikeschinkel@...> wrote:
>> But the problem again is what happens when two different plugins define the
>> same interface differently? That's where the registry comes in. The function
>> 'akismet_define_interface' would NEVER be called if it is defined in the
>> registry, so plugin devs would be forced to ensure their definition would
>> match the one in the registry (which is a good thing.) OTOH if a developer
>> is developing locally with no Internet connection, or the registry web
>> service was down, WP could fall back to the local definition.
>
> For now, I'd just like to say that having to call a remote registry
> for each plugin, on each page load, by default, is a *very* bad ideea.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKOSOyAAoJEChMcQvNqPqmezIQAJwJGctjX3lX5UqED1kleQnW
w/7xsURQvC7AtZdmOvy9qJX829qltT2+UYqtcEveZwui1aKLJ/SKABPJ9Hb8Z3NR
QknF9KcG3BiOGqOxn1uvm9+h7xm8FQ+VANvsZ6j9nP9QYSPJIlkcVKcg4nqr5tc7
rk07i81jqWXXTEQT+dPIZ0YMEVQxt3EuqlNhXDipF4B9xo+QvJ0WlzV160iDkkE3
yZWNP1VXxZhJMB1rJO9tgimYMpUtTU8X4IQ/qSvzoBmSdHSeH5tF+CXc504aSYxA
BBEXSgZ8w4Fi4mD5PmEK+ZZz3dSgyq6/OWrhEOe/O5QqRknE126c9KrCB5whJCiv
vmiDZfhLTGU8QoMBEsHHBlB+uxXIpes4PqyVHLbe3cSHsFfLS6NS5q9CIpD+XAPq
3bu2Xy0ncFipvVzcj7vtVGDwudJq2Au758vWzhzZz5LXf6F9BYWluTCFwyxQUqWC
d1zjRhWgBPeNGm91rDzk0Cdi+n+AmYeuk2chzgeWiatpQSs0t2i9j6u8Ex1ZoDc2
lXW1ui2LomhommKJaONSXCxQiFcHgDAJtWXv30DkIb3YdlSgYaepyVxcOA5r19i+
XwaRgA6d5AGD5WTFylM7ejKwqB1J1j35UNPMnhmFXsA0uCxbqV6B/qaXDXV85Nm+
kJECarIsS8NWZNalfIja
=c8Ed
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 17, 2009, at 12:39 AM, Eric Marden wrote:

> On Jun 16, 2009, at 6:02 PM, Stephen Rider wrote:
>
>> Certainly within current WordPress plugins it is frowned upon to  
>> look for "WordPress version x.x"; instead coders are encouraged to  
>> look to see if a certain functionality exists.
>
> Couldn't that just be a simple function_exists / method_exists call  
> (in most cases)?

Yes, that is what I was referring to. :)  It's common practice in  
WordPress, but sometimes coders do still check against WP version....
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

On Jun 17, 2009, at 9:07 AM, scribu wrote:

> On 6/17/09, Mike Schinkel <mikeschinkel@...> wrote:
>> But the problem again is what happens when two different plugins  
>> define the
>> same interface differently? That's where the registry comes in. The  
>> function
>> 'akismet_define_interface' would NEVER be called if it is defined  
>> in the
>> registry, so plugin devs would be forced to ensure their definition  
>> would
>> match the one in the registry (which is a good thing.) OTOH if a  
>> developer
>> is developing locally with no Internet connection, or the registry  
>> web
>> service was down, WP could fall back to the local definition.
>
> For now, I'd just like to say that having to call a remote registry
> for each plugin, on each page load, by default, is a *very* bad idea.

Agreed. But I was not proposing that. I was only proposing a call to a  
registry once upon plugin activation.

One call to a web service with a list of of plugins on activation that  
returns a list of registered interfaces is certainly not a legitimate  
performance concern for clients or for the server, right?

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



_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

On Jun 17, 2009, at 1:11 PM, Shane A. Froebel wrote:
> My API makes sure the correct versions are installed and also  
> installed
> before it gets activated.
>
> I have a unit-test case file. I am starting the integration with the  
> core.

I didn't look at your WP_Dependency stuff at first because of comments  
from others that it wasn't the right way to do it.  I just looked at  
your PHP code and am confused by it as it seems you've got some  
generic code in there and also some plugin specific stuff for Contact  
Form 7?  Why the hardcoded info in something you wanted to integrate  
into core?  If it was an example it should have been external to your  
WP_Dependency code.

Ignoring my confusion it looks like WP_Dependency requires defining  
dependency relationships for plugin versions rather than defining  
explicitly named interfaces and determining dependencies based on  
those interfaces.  While in some cases the former may still be  
necessary I think we'd be adding to the problem by making things more  
fragile going the route of WP_Dependency.

JMTCW anyway.

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


_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

On 6/17/09, Mike Schinkel <mikeschinkel@...> wrote:
>> For now, I'd just like to say that having to call a remote registry
>> for each plugin, on each page load, by default, is a *very* bad idea.
>
> Agreed. But I was not proposing that. I was only proposing a call to a
> registry once upon plugin activation.
>
> One call to a web service with a list of of plugins on activation that
> returns a list of registered interfaces is certainly not a legitimate
> performance concern for clients or for the server, right?

Sorry, didn't catch the part about "once upon plugin activation".

About option nr. 3, I don't see the real benefit of explicitly
defining the interface.

I can already envision me defining an explicit interface, then I
update the plugin and subsequently forget to update the interface.

Also, we shouldn't put our hopes up for interfaces.wordpress.org.


--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

On Jun 17, 2009, at 3:12 PM, scribu wrote:
>
> About option nr. 3, I don't see the real benefit of explicitly
> defining the interface.

Including, but not limited to:

-- Ability to validate during development that a plugin that  
implements an interface has done so correctly  
-- Ability to extract documentation for a plugin author (WordPress  
itself could define its interfaces)
-- Ability for a developer to know explicitly what the other developer  
meant when he defined the interface
-- Ability to do explicit rather than implicit coupling [1]
-- Ability to do code coverage testing [2]
-- Ability to do (semi-)automated unit testing [3]
-- Ability for plugin developers to see, at-a-glance in a well-defined  
way, what the touch-points are for a plugin.

For example I'm currently using Thesis theme and it has 50+ hooks,  
numerous global variables, several options, etc.  If it defined those  
as interfaces I could easily see all that, and the documentation would  
be maintained during development, not created after.

Also, much (but not all) of the interface could be auto-generated via  
a tool the developer could use.

And I'm thinking the ability to do semi-automated unit testing should  
alone make for a reason to do this.

> I can already envision me defining an explicit interface, then I
> update the plugin and subsequently forget to update the interface.

That would only happen if you tested the site in deployment vs.  
development mode. If you tested in development mode it would tell you  
that you have a problem.

> Also, we shouldn't put our hopes up for interfaces.wordpress.org.


Agreed, but first things first.  We can do proof of concept at  
interfaces.yourormysite.com and then the benefits are likely to be  
obvious enough to get agreement.

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

[1] http://en.wikipedia.org/wiki/Coupling_(computer_science)
[2] http://en.wikipedia.org/wiki/Code_coverage
[3] http://en.wikipedia.org/wiki/Unit_testing

On Jun 17, 2009, at 3:12 PM, scribu wrote:

> On 6/17/09, Mike Schinkel <mikeschinkel@...> wrote:
>>> For now, I'd just like to say that having to call a remote registry
>>> for each plugin, on each page load, by default, is a *very* bad  
>>> idea.
>>
>> Agreed. But I was not proposing that. I was only proposing a call  
>> to a
>> registry once upon plugin activation.
>>
>> One call to a web service with a list of of plugins on activation  
>> that
>> returns a list of registered interfaces is certainly not a legitimate
>> performance concern for clients or for the server, right?
>
> Sorry, didn't catch the part about "once upon plugin activation".
>
> About option nr. 3, I don't see the real benefit of explicitly
> defining the interface.
>
> I can already envision me defining an explicit interface, then I
> update the plugin and subsequently forget to update the interface.
>
> Also, we shouldn't put our hopes up for interfaces.wordpress.org.
>
>
> --
> http://scribu.net
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

On 6/17/09, Mike Schinkel <mikeschinkel@...> 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.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

On Jun 17, 2009, at 3:49 PM, scribu wrote:
> On 6/17/09, Mike Schinkel <mikeschinkel@...> 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@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[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@...> wrote:

> On Jun 17, 2009, at 3:49 PM, scribu wrote:
>> On 6/17/09, Mike Schinkel <mikeschinkel@...> 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@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 17, 2009, at 6:02 PM, Mike Schinkel wrote:

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

If this only happens when plugins are activated, how do you keep up  
with plugins being updated? Auto-update doesn't run the activate  
hooks, and plugins are also frequently updated via good ol' FTP,  
without being deactivated at all.  Thus, the plugins need to check  
their own interface versions and requirements on **each  
load** ...unless I'm missing something.

> Development mode would be[...] enabled in a new admin menu in the  
> Settings area[...].

Heh.  You must be new here. ;-p  As for a new setting in Admin:  
fuggedaboudit.

This will have to work with a new Constant placed in wp-config.php or  
something.

Stephen

--
Stephen Rider
http://striderweb.com/

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

About validating interfaces, it dawned on me that the simples way
would be to simply act like a consumer of that interface. For example:

define_interface('My Interface', '1.0', array(
  'constants' => array('FOO_CONST'),
  'classes' => array('foo_class', 'bar_class')
);

----------
// validating interface 'My Interface':

foreach ( $interface('classes') as $class )



On 6/18/09, scribu <scribu@...> wrote:

>> 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@...> wrote:
>> On Jun 17, 2009, at 3:49 PM, scribu wrote:
>>> On 6/17/09, Mike Schinkel <mikeschinkel@...> 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@...
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>
> --
> http://scribu.net
>

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

[--Don't know what happend to my message above--]

About validating interfaces, it just dawned on me that the safest way
would be to simply act like a consumer of that interface. For example:

define_interface('My Interface', '1.0', array(
 'constants' => array('FOO_CONST'),
 'classes' => array('foo_class', 'bar_class')
);

----------

// validating interface 'My Interface':

foreach ( $interface('classes') as $class )
  if ( ! class_exisits($class) )
    return;  // interface not implemented properly

and so on for globals, functions etc.

Not sure about dynamic actions and hooks. Maybe defining them with
wildcards? 'my_filter_*'.


Another benefit of using interfaces would be that name collisions
would be easier to identify.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Shane A. Froebel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I see a few problems with a few of examples given here and I will revise
on how my Class API works. (I have a hard-coded array right now... but I
will explain that in this email.)

1) function_exists or extension_loaded is fine and all, but I see if the
function exists in two different versions and it does TWO different
things, it would be important for the author of the plugin/theme to
define the plugin version that it was tested on. That way the result
would be the exactly the way it was.

2) Using wordpress.org would only be usefull for the current version on
the site that could be downloaded.

My code doesn't have this in yet. This is just a first draft of it
posted. I plan on posting the newest version on Saturday.

Installed
- ---------
Plugin A v1.0 - Requires Plugin C v2.0+
Theme A v0.4 - Recommended Optionial Plugin B v2.5.2+, Optional B v2.3.4+
Theme B v0.5.2 - No requirements.
Plugin B v2.3.4 - No requirements. (Upgrade v2.5.2 exists)
Plugin C v1.0 - No requirements. (Upgrade v2.0 exists)


For plugin A to work, the class in theroy would not allow plugin A to be
activated. Instead it would say "under the plugin" Plugin C needs to be
upgraded to the current version. *This could be where the check on
WP.org comes in handy. Plugin A also requires Plugin C to be activated
for it to work. Current moment Plugin C is activated because it has no
requirements.

New Status
- -----------
Plugin A - Not Active
Plugin C - Active (Upgrade v2.0 Exists)

***

Theme A can be activated due to the fact it says it doesn't need Plugin
B. If it's needed for full use it asks that it be at least 2.3.4 but
recommended that it use 2.5.2+.

New Status
- -----------
Theme A can be turned on.

Now Theme A has an update and it now has in it's settings (put into a
serialized array inside the options/meta table that it requires Plugin B
AND Plugin C at their most current versions.


That's just a sample example of what we can do. Theme's could have a
check inside their code checks to see if a version exists. But I don't
think that would be needed. The class could even activate plugins
forcefully if they are required to run, though a setting could override
this.


Off to bed....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKOdGNAAoJEChMcQvNqPqmiGIQAMieDPKKaWm1GSpOApgoPlXr
TD70saLYsvSOm1ne4vMiAv4lYVHXsG1zDy+laea4A3nZTKhzoiwdyvl+tPu9Pg/t
3wuqBubaVserNoILPH8pJ1Tg+5kboMFHJ68Coat41wIbWjmNqQawFfgJkl+D27Hj
B1aZhgbYNVh11d3eGqQnLcBe3NADZm4fZg5iLKIssm2NaAivwWA2HWukxDvNQBct
hDOYOd4TwzDSJUvMbVykAjmM8w88fkJlbu/iGTz7/f2o4MTBSF7sLPvDl8FNY1OP
EutWFmnoV+3mxNoFG6GHawfWYRGGQYj7q90ajkQBNEx1L0tb0FCPg7paCq37EJUu
xwEYmO+P3edAaoKr9A3qnpBzQEg84Jbw+I2DYw3rQ6+kb7jjSJ34wzW57WKzJq5G
rc90B4wbWfdfBpvfPBvOQYyyZOmcLFHdpxnzl5CnC/DcOmbGO+qQCCijPzJrPszY
tCDUwkuIBVt7abTM0cKbJjiuN06eH/Tid7h/JDUUV7H+isPtgGG5Fd9VvzlBgMFc
Zn74WLgh1x6f3I6feXoLM5pcaOGQRltYcMo8Uq5e6/ggIhR4CEbcj5lJvLsuBaY6
JLiVx5oFi3MHCMV2gohKqHtaQzpQyt0f++chK+/2cErIjvZqmaSc6b02XuqsQrFR
C5od2m8wc8zDgf4iOQ9d
=NrDQ
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"Shane A. Froebel" <shane@...> wrote:
> 1) function_exists or extension_loaded is fine and all, but I see
> if the function exists in two different versions and it does TWO
> different things, it would be important for the author of the
> plugin/theme to define the plugin version that it was tested on.
> That way the result would be the exactly the way it was.

Agreed, which is where the concept of "interfaces" come in. Interfaces are more granular than plugins and their existence will result in greater reuse of plugins and their lower level functionality, if experience from other languages and platforms holds true which I see no evidence to believe it won't.

If you are not familiar with interfaces think of them as I've proposed for WordPress as "named hook sets" that would encompass not only functions but also actions, filters, constants, globals, tables, fields, and probably more.  

By default and w/o an explicit definition a plugin's interface & version would be equal to the plugin's name & version. OTOH, if explicitly defined a plugin could maintain a versioned interface across many plugin versions but more importantly if could both use and implement more than one interface. =

> 2) Using wordpress.org would only be useful for the current
> version on the site that could be downloaded.

In earlier emails on this thread we discussed how interfaces could be managed on wordpress.org with a fallback to interfaces defined locally in a plugin which fully addresses this issue. If you read back through this entire thread you can to see the direction we were headed. Without speaking for them I believe scribu and Stephen were appreciating this direction.

All in all I think the concepts you are working on are mostly a subset of the interfaces proposal and value would come from merging to two efforts.

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 18, 2009, at 1:22 AM, Mike Schinkel wrote:

> In earlier emails on this thread we discussed how interfaces could  
> be managed on wordpress.org with a fallback to interfaces defined  
> locally in a plugin which fully addresses this issue. If you read  
> back through this entire thread you can to see the direction we were  
> headed. Without speaking for them I believe scribu and Stephen were  
> appreciating this direction.

Just for the record, I am not a fan of plugins depending on some  
service from a web site -- wordpress.org or otherwise.*  (If it's  
specific to the plugin -- e.g. Akismet -- fine, but not in a sense  
general to all plugins.)

So long as plugins can register interfaces locally, I'm okay with the  
site registration being a possibility....

Stephen


* This is already an issue for me with plugins and the auto-update: My  
plugins are not hosted on Extend, and as a result they are not checked  
for updates -- but the WP update check implicitly says "there are no  
updates for this plugin" by way of complete silence.

--
Stephen Rider
http://striderweb.com/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers