Grav cache is not working using modular templates and parameters

[saxinte]

Hi,

I need to use the cache of Grav as I have more than 200 modular pages in my app. If I don't have cache, the page response time from the server is higher than 1500ms. (https://www.busuu.com)

Grav is not working with the cache enabled ( cache:enabled:true in system.yaml ) when having multiple languages variations like /es, /fr, etc...
The issue is mostly related to modular templates.

Here is how to replicate:

• Download the last version of grav core from /downloads
• Add multi languages support for 3 different lang (for testing)
• Add 3 languages .yaml files with 1 string to test
• Create a modular page that include a modular template with the string inside using Twig |t.

When switching from language, the string is always the first loaded string. If you have lang variations then the language displayed between two lang variations is hard cached. Basically a given String will be displayed in Spanish on both /es and /fr versions. Example: http://imgur.com/a/Koehd

The second issue is regarding parameters query and it's not related to modular:

• Also if I fetch: /en/register?learning=es the learning param will be es
• then if I fetch /en/register?learning=fr the learning param will remain es
  Even if the page is not modular, the issue is visible with a normal page.

Here is a small GIF to show the issue: http://imgur.com/a/Koehd
Here is a Grav Instance to replicate the issue: https://www.dropbox.com/s/y4pxfyuirjsio0n/grav.zip?dl=0
Here is the thread in the forum: https://getgrav.org/forum#!/general:cache-is-too-strong-lang

And I can't add cache_enable: false on my modular. I have more than 200 pages that are modular with inside 5 to 8 modulars ( so more than 1200 modulars ). So it will end up finally to have the same as not having any cache at all.

Thanks,
Seb

[rhukster]

Ok, so this took me a while to track down and I had a lot of trouble recreating this on my own, but it turns out I was doing things one way, and you were doing things another.

Basically this all worked fine with my setup because I created a separate .md file for each language in the modular page. This worked because Grav caches the page based on the path to the file. So each language had a unique page, and therefore a unique cached copy for each language.

However, your example site had the clue. You had multilang on, but were only using a single non-language specific .md file. Therefore this was cached based on it's path, and was 'shared' among all languages.

I fixed this by ensuring the cache id for all pages takes into account the current language. This means that each page will be cached independently for each language even if it's the same actual .md file. This I think is the best approach as it is possible that the output is unique per the language purely based on the twig template (as was the case with your twig-level lang translation).

So that should fix your translation in modular content issue. In action:

https://gfycat.com/EqualSimpleArcherfish

Regarding the second issue you mentioned about the query parameter. This is just a caveat of how modular pages work. To summarize. A modular page is built from various modular sub-pages. For each subpage, the content is processed against the corresponding modular twig, and the result of this rendered output, it saved as the content of that subpage. This is then cached. Therefore any 'logic' you put in that modular subpage's twig template, is going to only be processed the first time through, after that the content is already rendered and cached. This is the point of modular pages. If you want a particular modular sub-page to process the Twig each time, then you must disable the cache on that particular modular sub-page. That means the content will be reprocessed against the twig each time.

If you put your query param check in the top-level modular page's twig, it will run each time and work correctly. This is beacause for a non-modular page (ie one that is not prefixed by _) The twig is not processed when calling content() and therefore not cached.

That all said, you say you are seeing this on regular pages also, not just modular pages. But i am not seeing it that way. It works for me when i put the logic in a regular twig file:

{% extends 'partials/base.html.twig' %}

{% block content %}
	<p>{{ "MY_LANG_STRING"|t }}</p>

    {{ page.content }}

    <ul>
        <li>Learning QueryString: <b>{{ uri.query('learning') }}</b></li>
        <li>Learning Param: <b>{{ uri.param('learning') }}</b></li>
    </ul>

{% endblock %}

Then i can request http://localhost/page?learning=foo or http://localhost/page/learning:foo

in action:

https://gfycat.com/ScientificZanyAtlanticblackgoby

[rhukster]

Reopen if you continue to have issues.. But should be good now.

[rhukster]

BTW, I have a Pull Request that provides the ability for modular pages to cache content but not the twig. This will allow you to have real logic in modular pages.

#1244

This has long been asked about as it comes up quite frequently when doing more dynamic stuff. If you want give it a try. You can keep it disabled, and just enable it on modular sub-pages that need it.

[saxinte]

@rhukster Huge thanks, it look like it's working properly. Thanks a lot for taking the time to answer properly. I removed the cache_enable:false from the modular and it seems ok now.

For the query parameters, because of your explanations, I realise I wasn't using Grav properly:

• I was always using for each page the template default.html.twig, and then, from the markdown file, I was including via twig the given layout for the page from a /layout folder I've created before.

Since I'm now using for each page, a different template, the query issue is gone.

Thanks,
Sebastien

[rhukster]

with the new never_cache_twig option I've added in develop branch (and will be in upcoming release), you would actually be able to put logic like this even in a modular twig template. It's going to make Grav even more flexible!

[saxinte]

Yes but it means this sub-modular will not be cached and I would like to avoid that so I will also avoid parameters as much as possible :) Thanks anyway! 👍