Filter for installed plugins in validate_plugin()

[jfarthing84]

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.

[scribu]

Seems like a useful filter to have. +1

[jfarthing84]

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

[dd32]

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)

[jfarthing84]

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

[strider72]

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.

[nacin]

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

[jfarthing84]

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.