[wp-hackers] WP_Cache and contents filtering

[Liang Jin]

HI, Tohru

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
pages.

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.

Best,

-Liang


On 7/17/07, FUJINAKA Tohru <tohru at nakarika.com> wrote:
> Hi,
>
> WP_Cache might be incompatible with contents filtering in some
> situations.
> 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
> filtering.
>
> 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?
>
> Regards,
>
> --
>  FUJINAKA Tohru aka reedom <tohru at nakarika.com>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>