Hello my tests seems that authcache does not support multilingual pages? Is there a possibility to add the language as a differentiation of the cache? I can't use the path prefix so the path is the same.

CommentFileSizeAuthor
#8 2333605-authcache-builtin-multilingual-8.patch7.58 KBznerol
#5 2333605-authcache-builtin-multilingual.patch1.89 KBznerol
#4 Screenshot from 2014-09-06 21:58:55.png78.77 KBznerol
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fox_01’s picture

fox_01 CreditAttribution: fox_01 commented

Now i found a hook and added this

mymodule_authcache_key_properties(){
  global $language;
  return array(
    'lang' => $language->language,
  );
}

This adds an language property but there is a problem. So i tried switching to a language subdomain to ensure the base path is different for each language. This does seem to have a bug

I visit a de page (http://de.domain.de) and it gets written to the cache. So far so good. But if i now switch the base_root to en (http://en.domain.de) then the language is switched on non cached pages but if i visit a cached page that was earlier cache under different language (in this case de) then the de language will show up. The debug shows me this for a visit on the en page:

Cache Class: "MemcacheStorage"
Cache CID: "dd028c4/<pagename>"
Debug Users: ["myusername"]
Cache User: "1"
Cache Backends: "authcache_builtin"
Active Backend: "authcache_builtin"
Authcache Key: "dd028c4"
Key props: {"base_root":"http://en.domain.de","roles":[3],"ajax":true,"lang":"de"}
P13n Clients: "Ajax"
Active P13n Clients: "Ajax"

The lang property is not change so authcache think i am de but the base_root was detected and so the key should be different and presented another cache version and not the de version.

I really need help here

znerol’s picture

znerol CreditAttribution: znerol commented

There is a cache-bin (cache_authcache_key) which is used to maintain the mapping from the session-id to the authcache-key. I suspect that this cache is not updated when switching the language.

In order to verify whether this is the case, please do the following:

  • For preparation, prime your cache for both languages: Open a new private browser window, switch to the desired language, log in, finally access the test-page and close the private browser window. Do this for both languages, such that there are cache-entries for both pages.
  • Close your browser, open a new private window, log in, then access the test-page and verify that it is delivered from the cache
  • Clear the cache_authcache_key cache bin (e.g. drush ev 'cache_clear_all("*", "cache_authcache_key", TRUE);'
  • Access the same page from the other domain and examine whether the correct language has been delivered

In order to solve the issue, try to figure out whether you can implement language-switching using post-requests or exclude the language-switching links from authcache using cache-rules.

fox_01’s picture

fox_01 CreditAttribution: fox_01 commented

Thanks for your response.

First i cleared all caches. Then i've done the preparation you advice but even at this step i see the problem. I've started with en and primed this page. After that i opened a new private window with another user and another language. I visit the same page (only difference is the active language and the base_root url) and i get the en version presented from the cache.
I've also tried it with other languages.

I've also tried to remove the additional "lang" key because i think the different subdomain for each language should be enough but this is the same behaviour. Why is the cache delivered from the from language even if the base_root url is different. My understanding is that all the key properties together + the page arguments have to be the same to get a cache hit.

znerol’s picture

znerol CreditAttribution: znerol commented
FileSize
Screenshot from 2014-09-06 21:58:55.png78.77 KB

Ok, I'm trying to figure out what is going wrong on a test-setup. The first thing jumping into my mind is Language detection and selection (admin/config/regional/language/configure). Please deselect all detection methods except URL. Especially the User method seems to interfere with authcache in my case.

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Active » Needs review
FileSize
2333605-authcache-builtin-multilingual.patch1.89 KB

Ok, I see it is indeed the key-cache of the Authcache Builtin Storage Backend. Lets include the base-root in the cache id. Patch attached.

Status: Needs review » Needs work

The last submitted patch, 5: 2333605-authcache-builtin-multilingual.patch, failed testing.

fox_01’s picture

fox_01 CreditAttribution: fox_01 commented

The patch seems to work for now. I will give you more information about my tests later

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs work » Needs review
FileSize
2333605-authcache-builtin-multilingual-8.patch7.58 KB

This patch includes fixes for the automated test code, no functional changes.

  • znerol committed 3a9542e on 7.x-2.x 
    Issue #2333605 by fox_01: Include base_root into key cache id to better...
znerol’s picture

znerol CreditAttribution: znerol commented
Status: Needs review » Fixed

Thanks for the report, fixed in dev, will be part of the next release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

joro78’s picture

joro78 CreditAttribution: joro78 commented

We have a similar situation with a site with Drupal7. The main language is Bulgarian. When browsing the site as not authenticated user or registering in Bulgarian (the primary system language) the site works fast enough. The problem emerges when switching on English and authenticating the user. The speed after user login when requesting a page degrades significantly. Is there some way to improve the speed or patch the module in order to have similar results as in the main language?

znerol’s picture

znerol CreditAttribution: znerol commented

Please do not comment on closed issues. Instead open a new support request.