[wp-hackers] WP_Cache and contents filtering
mywebadmin at gmail.com
Fri Jul 20 23:41:23 GMT 2007
I also use Gengo, and understand what your problems are. One solution
would be to change Gengo plugin as follows:
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
This is not ideal because basically the pages got cached twice (first
in the wp_get_pages function and then in Gengo plugin). So, in the
long run, making the cache system locale aware is the best solution.
On 7/17/07, FUJINAKA Tohru <tohru at nakarika.com> wrote:
> WP_Cache might be incompatible with contents filtering in some
> I'm seeking any ideas to solve this problem.
> I've installed Gengo, a plugin for make a wp site multilingual.
> Visitors will see not all posts of the site but ones written in their
> preferred language. That's one of Gengo's feature, site contents
> With WP_Cache, contents delivering flow could go wrong.
> Let's look in how `wp_list_pages()' works.
> These are 2 pages
> Id 1: About(en)
> Id 2: About(ja)
> When the first visitor visits in en_US locale context, wp_list_pages()
> begin fetching pages for output, calls get_pages().
> Inside of get_pages() it once get all pages Id 1 and 2 but passes them
> to filter handlers and Gengo will filter to leave only the Page [PageId:1].
> Then get_pages() caches the result [PageId:1] into the storage.
> As the result wp_list_pages() outputs a link of [PageId:1].
> Next visitor comes, seems from ja_JP locale region.
> wp_list_pages() calls get_pages().
> get_pages() peeks cache and finds the subject, the previous call's
> result [PageId:1]. Then dispatch filters and Gengo eliminates it because
> [PageId:1] is not for the locale `ja' but for `en'.
> As the result wp_list_pages() gets no page from get_pages(), so it
> outputs no page link.
> Similar behavior will be shown with categories and maybe others.
> How can it be solved?
> My ideas:
> a. let plugins to implement functions alike get_pages and others just for
> manage caches.
> -> bad for maintenance: anti-patten `Copy and paste programming'.
> b. make cache be structured.
> How about to setup cache storages for each locale, for example?
> The current cache implementation supports grouping. But its group
> name is hard-coded in general, you can see how get_pages() calls:
> wp_cache_get('get_pages', 'page').
> But with a bit of modification, you would be able to store a kind of
> information for each context.
> I got 2 ways in my mind:
> i) make cache directory structured.
> Add a variable $subdir or something to WP_Object_Cache and
> add ways to set the value somehow.
> Directories `cache/en/', `cache/foo/bar/ja' would be made.
> ii) provide filters to manipulate a group name.
> Change some WP_Object_Cache's methods like get/set methods to
> call that filters.
> Group name `page' would be changed to 'page_en'.
> -> Caches can be retrieved anytime - not only after initialization of
> plugins but also before or middle of it.
> In this case cache structure could change gradually. It could be
> happened that fetching cache A from the directory 'cache/' then
> fetching cache A again but from 'cache/en/' then storing cache A
> into 'cache/en/foo/'.
> -> In addition, some variables are cached as global variables.
> One of them is `$alloptions', used by get_option() family.
> It will be hard to manage.
> c. modify core code where manage caches to be locale aware.
> For instance, get_pages() will call wp_cache_get() like:
> $locale = get_locale();
> if ($cache = wp_cache_get('get_pages', "page_$locale"))
> -> It seems the best of the three to me if there is no other
> issue on cache.
> But is it true? Only for locale? Does it make sense?
> Any opinions and/or ideas?
> FUJINAKA Tohru aka reedom <tohru at nakarika.com>
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers