[wp-hackers] Caching as part of the core

[Michael Van Winkle]

In my experience caching is done best when it's done by the site developer.
One-size fits all solutions tend to fail or create more issues than then
they solve. There are a few places in WP where'd I would like to be able to
filter the output so I can deliver a cached version. For example in the
load_template() function it would be nice to have the ability to return a
"fragment" from the object cache rather than reloading the template file.

However, I'm not sure I understand why the existing object cache is
insufficient for delivering that fragment. Can we get more specific about
what the failure of the current object caching api is? I think a MUCH
bigger issue is theme/plugin developers generally lack of awareness and/or
concern for caching and performance.

Cheers,

Mike

On Mon, Jul 23, 2012 at 5:13 AM, Ryan Hellyer <ryan at pixopoint.com> wrote:

> 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.
>
>
> > Date: Sun, 22 Jul 2012 15:54:33 -0400
> > From: Mike Schinkel <mike at newclarity.net>
> > Subject: Re: [wp-hackers] Caching as part of the core
> > To: wp-hackers at lists.automattic.com
> > Message-ID: <66806DEC-16A6-43A3-993C-BF9371932991 at newclarity.net>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Jul 22, 2012, at 1:31 PM, Brian Layman wrote:
> >> Drop in plugins are what they are because they must be loaded early on,
> or at least at very specific times in the initiation process, to do their
> job.
> >> They are so specific in function, that the list of file names is hard
> coded into the core.
> >
> > But clearly the method $dropins use to find and load files could be
> improved, no?
> >
> > 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.
> >
> > -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Mike Van Winkle
708-289-3136
mike at mikevanwinkle.com
http://www.mikevanwinkle.com
http://www.twitter.com/mpvanwinkle
http://www.facebook.com/mpvanwinkle


"All excellent things are as difficult as they are rare." -Spinoza