Cache is too strong, /lang variations are not updated

Archive
1

Hi,

It looks like that the number of the pages inside the /pages folder act on the response time of a given page.
The current response time is about 1500ms, it’s huge. But I wasn’t using the cache: enabled: true parameter inside the system.yaml before.

Since I used it, it turns from 1500ms to 250ms. Which is great.
The issue I have (in local and staging), is:

This is one of the issue I have, but I have multiple example where the HTML is not updated depending on the URL parameters or the language variation.

Any ideas why the number of pages act on the response time of a given page?
Any ideas why I have those cache issues?

Thanks

2

Cache should work well also with multilanguage enabled. I just tested, there seems to be no problem generally, so it should work.

As for response time, yes increasing the number of pages (by a large number) will increase the response time.

A good SSD storage with a good amount of RAM / processor will speed up without the need for caching, but at some point cache must be enabled.

3

Thanks Flavio.

Actually I found when the problem occurs, here is how to replicate:

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

When switching from language, the string is always the first loaded string. If the include is inside the modular markdown file, it’s working. It looks like there is an issue with modular.
It’s also the same issue with query parameters, please see the example in my attached Archive.

Here is a fresh zip with this scenario from a clean grav repo: https://www.dropbox.com/s/y4pxfyuirjsio0n/grav.zip?dl=0

Thanks :slight_smile:
Seb

4

Here is a GIF with the issue as well: Grav-cache

Thanks!

5

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 works with a standard include.

Thanks

6

The GIF wasn’t uploaded properly: http://imgur.com/a/Koehd here is the right version.

Thanks

7

It’s a problem related to getting values from twig/php processing inside the modular child page. They are cached aggressively unless you put cache_enable: false in the markdown page header. So, if you put cache_enable: false in your modular-header.md page, which twig contains the parameter/translation processing, the problem goes away.

Same issue with having forms in modular pages.

8

Thanks! I’ve just tested - it’s working for both situations: In a modular and in the non-modular with query parameters.
But I don’t understand why my non-modular page is now rendering fast EVEN if I add cache_enable: false ?

I exactly what I wanted : A fast response time + no aggressive cache when using query parameters. So why my page is still rendering fast with the cache_enable parameter to false?

9

If the global cache is disabled, Grav will perform some costly operations every page load. If instead you just exclude that specific page, it’s going to skip a lot of work.

10

I tried it but as I have more than 200 modular pages in the app (for SEO content), the result is the same, it’s like having cache:enabled:false in the system.yaml.

Anyone has this issue before or fixed it using another Cache System than File ? Like APC for example? Thanks!