Allow change of dropins folder

[bungeshea]

Dropins are stored in the wp-content directory. Currently there is no way to alter this (short of editing core code).

The get_dropins() function does not utilize filters or predefined constants in any way.

Probably the best method here would be to define WP_DROPINS_DIR constant in /wp-includes/default-constants.php that can be overridden in wp-config.php.

[bungeshea]

For example, you may want the dropins directory to be wp-content/dropins

[bungeshea]

Use WP_DROPINS_DIR constant instead of WP_CONTENT_DIR

[jeremyfelt]

Thanks for the ticket and patch @bugeshea!

I'm personally a fan of this. It would be great to have a directory to separate out things that exist in a different frame of mind from plugins and themes.

I do wonder about backward compatibility. I know there are several plugins—some very popular—that create dropins for database connections or object caching when installed and place them automatically. Without looking, my guess is that they toss these to WP_CONTENT_DIR because that's how it has been.

Would it be safe to make a change like this in core?

[knutsp]

Not safe, unless both WP_CONTENT_DIR and WP_DROPINS_DIR are checked for dropin files across some major versions. WP_DROPINS_DIR must have precedence (for the same dropin file). If a dropin is found in WP_CONTENT_DIR then a deprecated warning should be issued, at least in the major version following the version this is implemented. Two versions or more later the backwards compatibility may be removed.

Occasionally, like when (just before) plugins activated, a cleanup routine may check for dropin files that exist in both folders and delete the one in WP_CONTENT_DIR (which is then unused).

When WP_DROPINS_DIR is undefined it should be set to WP_CONTENT_DIR . '/dropins' at load time.

[bungeshea]

It looks like implementing the changes suggested by @knutsp would require the introduction of at least two new functions:

load_dropin(), which would take a dropin name (or filename) as a parameter and look for the file in the WP_DROPINS_DIR followed by the WP_CONTENT_DIR, and then load it if found. A deprecated notice would be issued if the dropin is loaded from WP_CONTENT_DIR.

cleanup_dropins(), which would be hooked to the appropriate actions such as activate_plugin and clean up unused dropins from WP_CONTENT_DIR.

In which file would it be appropriate to introduce these functions?

[dd32]

I'm quite okay with dropins living in WP_CONTENT_DIR for now.

I can see reasons for allowing it to be loaded from elsewhere (for example, being able to define a host-wide dropins folder), however utilising the early filters in WordPress + a pre_append_file and early inclusion of filters seems like a far more robust mechanism for that.
I suspect that we'd probably change to a different mechanism of detecting/enabling dropins before we added a custom directory for them.

I'm marking this as maybelater for now, discussion can continue, and a committer can re-open it in the future if we see the need to go in this direction.