[wp-hackers] Caching as part of the core

[Mike Schinkel]

On Jul 23, 2012, at 8:13 AM, Ryan Hellyer wrote:
>> Date: Sun, 22 Jul 2012 15:54:33 -0400 From: Mike Schinkel <mike at newclarity.net>
>> 
>> Consider this as a strawman proposal[1]:
>> 
>> 1.) Move the require() in /wp-settings.php for /wp-includes/plugin.php from line 78 to 31 so that it gets loaded before any drop-ins.
>> 2.) On line 32 of /wp-settings.php call a function that looks for a '/wp-content/dropins/' directory; if it exists then include() all the .php files in the directory.
>> 3.) Deprecate existing dropins and implement do_action() hooks to run in place of existing dropins.
>> 4.) Document that any file in dropins directory is responsible to add the actions it needs to support its own drop-in functionality.
>> 
>> Thoughts?  If I don't get someone to explain an obvious reason this won't work I can add to Trac.
> 
> Perhaps a better solution may be to provide an API to allow regular
> plugins to add drop-ins automatically? This can already be done via
> the WordPress file API, but having something specific to dropins might
> make some sense.
> 
> Or perhaps we should encourage existing drop-in plugin developers to
> implement the WordPress file API directly, to copy their files across,
> instead of requiring manual copying?
> 
> The API could also remove the drop-in when the plugin is deactivated.
> This would remove the headaches some users have when they deactivate a
> caching plugin and still have the advanced-caching.php file lingering
> in their system even though the plugin is no longer in use.

That's an orthogonal issue and doesn't address core only supporting one drop-in per site, which the proposal does address.  

Having an API to add dropsins could have value though if combined with the ability to support hook-based dropins as proposed above.

-Mike