WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#12149 closed enhancement (wontfix)

Filter for installed plugins in validate_plugin()

Reported by: jfarthing84 Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9.1
Component: Administration Keywords: dev-feedback has-patch
Focuses: Cc:

Description

I believe that there should be a filter for the installed plugins list generated by the get_plugins() function within the validate_plugin() function.

My reason is that a plugin I am creating uses it's own "modules" that are similar to plugins, or rather, plugins for a plugin. I could almost use the native WP plugin functions with the filters already there, except for getting the list of installed plugins, as my "modules" will be stored in a folder within the plugin folder.

This one function inhibits the use of any of the native WP functions for this situation because it is used by validate_plugin() which is used by activate_plugin(). So, in my situation, I have to clone all these functions, just to add to the list of installed functions.

This could all be avoided with a simple filter.

Attachments (1)

plugin.php.diff (579 bytes) - added by jfarthing84 6 years ago.

Download all attachments as: .zip

Change History (11)

@jfarthing846 years ago

comment:1 @jfarthing846 years ago

  • Keywords has-patch added

comment:2 @scribu6 years ago

  • Keywords changed from dev-feedback, has-patch to dev-feedback has-patch
  • Milestone changed from Unassigned to 3.0

Seems like a useful filter to have. +1

comment:3 @jfarthing846 years ago

  • Cc jeff@… removed

This is obviously a simple thing and will not break anything. Any chance we could get it committed now?

comment:4 @jfarthing846 years ago

  • Cc jeff@… added

comment:5 follow-up: @dd326 years ago

Is there any reason why you could not simply add a plugin header to the file?

Or is the problem that the subdirectory is not being scanned? (In which case, A filter on get_plugins would be more suitable)

comment:6 in reply to: ↑ 5 @jfarthing846 years ago

I actually am using the WP plugin header standard in the files.

It is like you said, the subdirectory is not being scanned. Also, I would not want these files to show up on the regular WP plugins page.

I was thinking about putting a filter in get_plugins(). However, I'm not sure of the best place to put it...

comment:7 @strider726 years ago

In WP 2.9 there is a get_file_data function (used by both get_plugin_data and get_theme_data). You could put headers in your sub-plugins that WP won't recognize as a
Plugin (I think if you simply omit "Name"...), then use a custom wrapper for get_file_data to read the sub-plugin data when you need it.

In other words, this can readily be done right now with WP 2.9.

comment:8 @nacin6 years ago

get_plugins() also performs caching. I also personally think we should generally avoid hooks that can mess too much with the plugin activation process, especially considering the sandbox.

That said, at the very least we can probably abstract out a good portion of get_dropins(), get_plugins(), and get_mu_plugins(), into a new directory-scanning function. If you want to try that, that could work. (I would also look at wp_get_active_and_valid_plugins() and wp_get_mu_plugins() as well.)

comment:9 @jfarthing846 years ago

The point was to be able to use the built-in functions to activate and deactivate my "modules". This can't be done because activate_plugin() uses validate_plugin() which will return false because it only reads the 'wp-plugins' directory. Point blank.

But, there are ways around it, so it doesn't really matter.

comment:10 @nacin6 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.