[wp-hackers] $cache_categories

[Ryan Boren]

On Tue, 2006-01-03 at 22:40 -0500, Kaf Oseo wrote:
> Ryan Boren wrote:
> > Please don't do this.  If someone is using a replacement cache, this
> > won't work.  Plus, these are the sort of things that make plugins so
> > fragile to core changes.
> 
> (Important note: I'm not angry, frustrated or anything of the sort. I
> am just someone in search of answers, and maybe even solutions.)
> 
> What makes plugins fragile is when changes are made to the core with
> no warning. Having $cache_categories available on category queries
> worked. I'm sure there was good reason to pull it, and with other
> methods I'm not arguing for its return, but we're getting to where
> users can plan on any plugins of any complexity to break when a new
> WP release hits. Even if it follows coding guidelines and implements
> nothing but WP calls.
> 
> Is there a resolution to this? With the somewhat free form method of
> coordinating development and disseminating information on core mods
> which could break existing code, I just don't know. Certainly part of
> it involves the participation of those of us working on plugins, but
> it'd sure be nice not to have to test each of my plugins with every
> large, and sometimes even incremental, upgrade. And with no guarantee
> what worked in tonight's build will do so tomorrow, it can be a daily,
> time-consuming effort if one wants to keep up.
> 
> Maybe I just need to vent--no, I'd prefer some slightly easier way of
> managing my harem of plugins to make sure they're ready for WordPress
> version Next. Sitting on my hands until after a release, waiting for
> the flood of bug reports to drop in my inbox isn't a smart way to go
> about it, but it's starting to look attractive...

I have no idea what arbitrary bits of WP plugins are digging into.  Some
dig so far down that just about any change made to WP will break them.
If a plugin is digging into the cache code, it should expect to get
broken.  The cache is off limits, and the abstraction of the caching
code should make that clearer.  In WP, everything is public so plugin
authors treat everything as fair game.  Everything is not fair game.  We
need to do a better job of defining and documenting the boundaries, and
plugin authors need to request API when there is something they need to
get at.  If plugins are accessing global variables and doing lots of
SELECTs, they need to make use of existing API instead or request API
where there is none.

Ryan