Item4413: TwistyPlugin needs a way to work correctly with PageCache

While I am working on the PageCache I just found out that the current twisties as they are produced by the TwistyPlugin & TwistyContrib, can't be cached as part of the complete html page. That's because the TwistyPlugin reads the browsers cookies and then generates specific html for it ... which is fine for the first hit on a page. But the markup produced by the plugin is then stored to the PageCache and reused on further calls on the same page by the same user. After loading the page, the user just changed the state of some twisties in his browser and reloads the same page again and thus gets the cached page...which has got the former classes inside the twisty controls based on the first call to that page. The TwistyPlugin will not see this second request and the changed cookies as the rendering engine is avoided on subsequent calls on the same page.

I know the PageCache is not coming out for 4.2, but I still would like to discuss this issue in time. Arthur, any ideas?

-- MichaelDaum - 25 Jul 2007

Is there any way javascript can find out the page is cached? Or TwistyPlugin at the time of writing the js?

-- ArthurClemens - 26 Jul 2007

Every page is cached. You can exclude sections of a page from being cached and rendered on request time. But that's not what you want for twisties, do you.

-- MichaelDaum - 27 Jul 2007

I am looking for a way to let the plugin write the initial state only when the page is not cached.

-- ArthurClemens - 27 Jul 2007

What about pages that are cached and have twisties on them? All of my pages have twisties.

-- MichaelDaum - 28 Jul 2007

The problem with VarCachePlugin appears to be missing head files Item5414.

-- ArthurClemens - 03 Mar 2008

Can't see that this is related to PageCache as it caches all of the page as it was send to the browser the first time.

The problem - described above - is a fundamental one: the user changes a cookie state via javascript, but gets the same page again with the old twisty states, and these don't match the cookie states anymore. That's because the TwistyPlugin does not get a chance to read them anew on perl level.

-- MichaelDaum - 04 Mar 2008

Would it be better if the cookie is optionally read with js only?

-- ArthurClemens - 04 Mar 2008

Yes, I think so. TwistyPlugin did so once, didn't it?

-- MichaelDaum - 05 Mar 2008

Yes, we added reading cookies by perl to prevent having "init" js tags right after the twisty html (to prevent visually disturbing opening/closing of twisties). Problem is that twisties are default open as no-js fallback. Perhaps we can find another mechanism for that.

-- ArthurClemens - 05 Mar 2008

How about storing/maintaining the twisty states in the session object? PageCache is respecting different session states in there.

-- MichaelDaum - 08 Dec 2008

Why not try it?

How do we do this, using the session object? And how can we test it?

-- ArthurClemens - 23 Jan 2009

I believe that this task is resolved. Doesn't the current Twisty implementation does everything client side?

-- GeorgeClark - 30 May 2014

Unfortunately not. The server will generate a closed or open twisty based on cookie values. However when a page comes from the cache it will return the markup as generated at the time it was first stored into the cache.

One possible solution would be to init the twisties on the client side. However that would result in a well perceivable change of the page when loaded, something that Arthur has tried to avoid so far.

Another solution would be not to store twisty states in cookies but in the server-side session object. That way the page cache would take their value into account while creating a variation key. This however means that any click on a twisty needs to inform the backend about the state change, a rest call.

-- MichaelDaum - 30 May 2014

No actions.

-- MichaelDaum - 06 Nov 2018

Commenting is disabled while not logged in