Ticket #4048 (closed enhancement: wontfix)

Opened 1 year ago

Last modified 6 months ago

some hooks for the plugin management system

Reported by: m0n5t3r Assigned to: westi
Priority: normal Milestone:
Component: Administration Version:
Severity: normal Keywords: has-patch new-hook plugin-management
Cc:

Description

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)

Attachments

get_plugin_data.filter.diff (0.7 kB) - added by m0n5t3r on 03/30/07 11:08:39.
before_activate_$plugin.action.diff (0.7 kB) - added by m0n5t3r on 03/30/07 11:09:04.
get_plugin_data.pre_activate-hooks.patch (1.3 kB) - added by darkdragon on 12/16/07 22:37:13.
Combines get_plugin_data hook and before_activate_ hooks
4048.r6603.diff (0.8 kB) - added by darkdragon on 01/12/08 22:11:08.
Just the pre_activate_hook based off of r6603

Change History

03/30/07 11:08:39 changed by m0n5t3r

  • attachment get_plugin_data.filter.diff added.

03/30/07 11:09:04 changed by m0n5t3r

  • attachment before_activate_$plugin.action.diff added.

08/21/07 18:11:24 changed by 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.

09/13/07 21:19:56 changed by ryan

  • milestone changed from 2.3 to 2.4.

12/14/07 05:14:20 changed by darkdragon

  • keywords changed from has-patch, 2nd-opinion to has-patch 2nd-opinion plugin-management.

12/16/07 22:37:13 changed by darkdragon

  • attachment get_plugin_data.pre_activate-hooks.patch added.

Combines get_plugin_data hook and before_activate_ hooks

12/16/07 22:38:06 changed by darkdragon

  • keywords changed from has-patch 2nd-opinion plugin-management to has-patch new-hook plugin-management.

Added a new patch which implements the above hooks.

12/19/07 08:43:54 changed by westi

  • owner changed from anonymous to westi.
  • status changed from new to assigned.

12/19/07 19:16:54 changed by ryan

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

12/19/07 19:29:29 changed by 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.

12/19/07 19:37:37 changed by filosofo

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

12/19/07 19:40:38 changed by santosj

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

12/20/07 06:41:49 changed by darkdragon

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

01/04/08 03:47:23 changed by 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.

01/04/08 03:58:17 changed by 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.

01/12/08 22:11:08 changed by darkdragon

  • attachment 4048.r6603.diff added.

Just the pre_activate_hook based off of r6603

01/12/08 22:17:28 changed by darkdragon

It is possible to get this in?

01/27/08 06:41:41 changed by darkdragon

  • status changed from assigned to closed.
  • resolution set to wontfix.
  • milestone deleted.

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.