[wp-hackers] Best Practices for Caching Plugin WidgetOutput?

[Mike Schinkel]

Jeremy;

Thanks for the suggestions.  Sounds like the get_option() really is a great
general purpose caching mechanism.  I think that's what I'll use.

-Mike
On Tue, Dec 23, 2008 at 9:46 PM, Jeremy Clarke <
jer-wphackers at simianuprising.com> wrote:

> I like to use the options route because it works no matter what and
> its a pretty stable api at this point. When I played with the wp_cache
> mechanism in the past I found that various things would stop it from
> working (wp-config.php constant? I think that was removed), and it was
> pretty confusing. The documentation was also pretty much non-existent
> at that point, might be better now.
>
> Its worth noting that the RSS aggregation/fetching system used by the
> Dashboard in WP uses the options table to store  full feed content,
> implying its not such a bad idea to use it for text blocks. If its
> truly humonguous it might be better to avoid the IO to the db, but
> since you're already fetching everything from the wp_options table it
> won't be a slow/complex query at all, its only the raw size of the
> result that could potentially be a problem.
>
> In terms of updating it semi regularly I use a separate option for
> each cached value that just has the timestamp of the expiry for that
> value, on pageload I autoload all those expirations and update the
> option if its the right time. Hooking into the relevant actions
> (category update, post save) would also be a good idea if those
> actions are likely to make a big difference on performance (I haven't
> gotten around to it, and my users are perpetually confused about why
> the new category isn't showing etc.)
>
>
> --
> Jeremy Clarke | http://simianuprising.com
> Code and Design | http://globalvoicesonline.org
>  _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>