[wp-hackers] WP_Cache and contents filtering
FUJINAKA Tohru
tohru at nakarika.com
Sat Jul 21 05:12:31 GMT 2007
Hi Liang,
I'm grad to have a reply from you. :)
Well, actually plugins developers could solve problems relate to the
cache feature in their way, one by one.
But should each developer face such problems?
Should each developer spend time to think and solve such problems?
That's, in other words, making plugins to have patches against the
core code.
It doesn't make a sense to me.
Making the core to be right will save the total of code lines and
total time of writing code belong to the WordPress.
> So, in the
> long run, making the cache system locale aware is the best solution.
Yes, it should be. :)
Where do the core developers go? I haven't gotten any words from them
about this. :p
# Also my plugin registration request haven't be approved over a month.
# Who has responsibility to do it?
# I hate the way it goes. Only what I've had is silence.
BTW, Liang,
> In your case, Gengo could actually call the wp_cache_add() function to
> cache the locale-related page details, so that when the next visitor
> comes with ja_JP locale, Gengo would be able to pull out the correct
> pages.
An another idea come to me.
Since the cache which get_pages() sets is associated with a page query
condition, injecting a locale related value into that query condition
makes the cache to be unique by each locale.
With WP2.21 and Gengo 0.9.1-alpha-4, the following works:
if (!function_exists('gengo_list_pages')) {
function gengo_list_pages($args = '') {
if (is_array($args)) {
$r = &$args;
} else {
parse_str($args, $r);
}
$r = array_merge(array('language' => the_language(true)), $r);
return wp_list_pages($r);
}
}
However, there is a bug inside of get_pages(). So the first time
calling results good but the later callings result not.
I made a ticket about it. http://trac.wordpress.org/ticket/4660
The cache feature seems not tested well.
--
FUJINAKA Tohru aka reedom <tohru at nakarika.com>
More information about the wp-hackers
mailing list