some hooks for the plugin management system

[m0n5t3r]

failed to get any feedback on this from wp-hackers, posting anyway:

• filter get_plugin_data: allows plugging functions that handle additional plugin metadata
• action before_activate_$plugin: allows the plugin to do some stuff before being activated, and refuse activation if it doesn't like something

2nd opinion needed on the first point: perhaps a more efficient/extensible rewrite of get_plugin_data would also be appropriate (preg_match is not really needed, neither is reading beyond the end of the first comment block; see, some people have a nasty habit: they put everything about their plugin in one huge file)

[santosj]

before_activate_$plugin.action.diff, have you tested this to make sure it works?

It appears as if you are depending on register globals or globals for the $can_activate.

My guess is that it should be a filter

$can_activate = apply_filters('before_activate'.$plugin, true);

This would be most useful for checking dependencies before the fact. Would have been quite useful in some previous projects.

[darkdragon]

Combines get_plugin_data hook and before_activate_ hooks

[darkdragon]

Added a new patch which implements the above hooks.

[ryan]

I'm pretty ambivalent about these. Any examples of how they would be used?

[santosj]

As for the plugin data info. I have no idea what it would be used for, other than some malicious purpose. It is part of the ticket, so I don't know. It might be useful, in the event a plugin wanted to do something with the urls to check to see if there was an update available based on the author's web site. However, it might just be better to make it an action in that case.

I'm not sure how I feel about allowing a plugin to overwrite the information in the plugin. It isn't like the plugin itself can change that, because it can't, until it is enabled and ran. However, that sort of defeats the purpose. Why would a plugin want to do that? They can just change the info in the file.

For the second, I had a really good reason to need this. I could check whether dependencies have been enabled and if not then I return false and fail the activation.

In the current situation, I would have to wait until the plugin is already activated and the test that information and then deactivate the plugin manually. A painful hack and I would rather keep that logic separate and in a location create purposefully for that situation.

[filosofo]

It might be nice to filter the plugin data to provide l10n of the name and description.

[santosj]

Oh yeah. Well, I don't do very much l10n coding, so you know, I wouldn't have guessed that! Thanks.

[darkdragon]

See #3089 for a reason to commit this patch as a far more simple solution than what is in #3089.

[ryan]

Filtering for l10n purposes means the plugin has to get the source strings in the catalog somehow. It could do this with some dummy () calls within the plugin that duplicate the header information. But then we would have to load catalogs for inactive plugins to get at these translations, which we don't currently do. If we did do this, it would be an integrated feature and not a filter.

[darkdragon]

Okay, I'll work some more on it. Can the before_activate_ hook still go in?

What I was thinking going off your idea, is if there was a file that could be loaded that uses the __() and loads the plugin locale domain. This file could be set by another optional comment field and would be loaded to get the translatable plugin details. It would also remove the problem found in the current patch when the plugin isn't activated, the translations won't load.

I suppose the work above would have to go into the other ticket. If you add the hook, I think you should close this out as fixed and allow the other feature to be done in the other ticket.

[darkdragon]

Just the pre_activate_hook based off of r6603

[darkdragon]

It is possible to get this in?

[darkdragon]

2.5 makes it easier to deactivate your own plugin, if it doesn't meet your requirements. The other one is already an won't fix issue.

[strider72]

Plugin Data mod is duplicate of #8964