Hello,
I have noticed that calls to ajaxReload are cached in the browser, even if the inclure has #CACHE{0} set.
I could probably solve the issue by adding a unix timestamp to all calls to make them unique, but it’s not elegant and I am wondering:
Is there a way to disable browser caching for ajaxReload’s responses?
I am loading a modele that contains forms that toggle things, and the toggles are returned as they were on the first ajaxReload after they were changed.
Kind regards,
Urs
I am sceptical, because in formidable it does not use cache, and I didn’t do anything special.
How do you call it ?
Thank you Maieul,
Using INCLURE:
<INCLURE{fond=modeles/article_with_forms_ajax}{env}{id_article}{ajax} />
And with ajax links inside:
<a class="ajax" href="/spip.php?page=articles&id_article=3961">Link</a>
Kind regards,
Urs
so that is not reload, it is classical. ajax. Very, very strang that you get un problem. But maybe the fact that you insert is modele could be a cause of …
indeed modeles/ have specific behaviour regarding cache
try using an include/ that is not called in a modele/
It may come from a bad configuration of expires header form html files see Expire headers - Documentation technique : Debian & Redirections incorrectes avec Firefox > 5 (#2537) · Tickets · spip / spip · GitLab
Hello,
Thank you for the tips.
The Apache config / htaccess is fine:
ExpiresByType text/html « access plus 0 seconds »
I moved to include, but no change.
The quickfix with the unix timestamp in the get parameter of each ajax link works, but it’s not a good solution. Still I wanted to try it and it works.
You can reproduce the issue when you have e.g. a pagination. When you go back and fourth between two identical requests, ajaxReload seems to return the previous response even if the response had no-cache and expires headers with a past date (should re-fetch from server).
In the browser console (indeed Firefox 
) there is no request to the server!
Very interesting. This makes sense in most cases, as the content of a pagination or similar won’t change, but here I have dynamic content.
Kind regards,
Urs
could we have a url of demonstration ?
Hi Urs,
SPIP natively managed 2 different situations for ajax reloads :
A) ajaxbloc from <INCLURE{fond=inclure/foo}{env}{ajax} /> where any inner links a.ajax, .pagination a will fire a reload with parameters from the [href] attributes.
B) ajaxform from <div class="ajax">#FOMULAIRE_FOO</div>, where any event of submission of the form, will reload it with a new context according to the selected inputs.
I am not sure which case suits your actual state of use.
You sound quite suprised of finding no evidence of any request « switching back and fourth » using the links through a paginated nav, it’s might be explained because requests already hit (and the markup of their response) are conveniently stored (and reused if needed) in a JS Object.
console.log($.spip.preloaded_urls); in the console might help you for debug.
Also, as far as case (A) is concerned, adding .preload or .nocache class on the .ajax link, can alter the default behaviour.
in your file : inclure/article_with_forms_ajax, do you have a <BOUCLE_article> that wraps all your code?
If so, add a simple: <span class=“do_not_delete”></span> at the top of your page.
See `{ajax}` for inclusions - SPIP about .nocache
And Technique Vaudou | Wiki Jujutsu Kaisen | Fandom for do_not_delete ?
if you have an include with <BOUCLE_toto()> </BOUCLE_toto> that surrounds the entire code, this include is not update with ajaxreload.
just add a piece of code outside the loop, that’s why I simply suggest <span class=“do_not_delete”></span>
Hello All,
Thank you all for the great input. Adding the nocache class to the links solved the issue for me (`{ajax}` for inclusions - SPIP).
I wanted to say bravo SPIP and the developers behind it. I find ajaxReload extremely useful for modern site development. I’ve research a bit and I found that SPIP had this feature already in 2006, 6 years before React came to the market with a similar « modern » approach. With ajaxReload we can update dynamically any part of the website, with a single line of JS code. The way it’s implemented seems extremely efficient, only the relevant part is recomputed and sent over the wire. Bravo.
This, combined with a separated channel and priority for security upgrades, and the rock solid code (meaning I spend almost no time re-adapting my code to changing SPIP core features) is a really great developer experience.
Kind regards,
Urs