WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#4048 closed enhancement (wontfix)

some hooks for the plugin management system

Reported by: m0n5t3r Owned by: westi
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch new-hook plugin-management
Focuses: 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 (4)

get_plugin_data.filter.diff (705 bytes) - added by m0n5t3r 7 years ago.
before_activate_$plugin.action.diff (706 bytes) - added by m0n5t3r 7 years ago.
get_plugin_data.pre_activate-hooks.patch (1.3 KB) - added by darkdragon 6 years ago.
Combines get_plugin_data hook and before_activate_ hooks
4048.r6603.diff (831 bytes) - added by darkdragon 6 years ago.
Just the pre_activate_hook based off of r6603

Download all attachments as: .zip

Change History (19)

comment:1 santosj7 years ago

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.

comment:2 ryan7 years ago

  • Milestone changed from 2.3 to 2.4

comment:3 darkdragon6 years ago

  • Keywords plugin-management added

darkdragon6 years ago

Combines get_plugin_data hook and before_activate_ hooks

comment:4 darkdragon6 years ago

  • Keywords new-hook added; 2nd-opinion removed

Added a new patch which implements the above hooks.

comment:5 westi6 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

comment:6 ryan6 years ago

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

comment:7 santosj6 years ago

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.

comment:8 filosofo6 years ago

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

comment:9 santosj6 years ago

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

comment:10 darkdragon6 years ago

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

comment:11 ryan6 years ago

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.

comment:12 darkdragon6 years ago

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.

darkdragon6 years ago

Just the pre_activate_hook based off of r6603

comment:13 darkdragon6 years ago

It is possible to get this in?

comment:14 darkdragon6 years ago

  • Milestone 2.5 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

comment:15 strider725 years ago

Plugin Data mod is duplicate of #8964

Note: See TracTickets for help on using tickets.