Routing - On Live Website - implementation and caching

Wappler General
#1

Hi.
I had a use case for the new routing functionality in 1.9.0, so I tested it and then deployed on my live application.
But, it turns out there is some issue with caching due to which re-written URLs do not work.
The issue can be fixed by clearing the cache & similar options, but this is not feasible for end user.

Don’t have exact steps to reproduce the issue, but try deploying a website built on previous version of Wappler, then add routing and deploy from a newer version.

I don’t think I am missing anything, but could it be that I have missed some configuration to be done on server with regards to routing? The app works fine after clearing cache, so code is ok.

1 Like
#2

I tested on a few different systems where the website had not been accessed before, and everything works fine.
So it has definitely something to do with caching.

#3

that’s not an issue to fix by wappler
this goes for anything that have caching on the web.

#4

That’s correct - Wappler is not responsible for caching.
But I’m just looking for suggestions on how to resolve this. Routes is a great addition, but if it can’t be deployed without breaking existing functionality, then what’s the point?

#5

to be honest. i don’t see any benefit to implementing routes to an existing working website. users will use your page not look at how long or short the address is. and if they need to send the link they will just copy/paste

for a new SPA webapp its a must. but other than that 99% of the users will not even look at the address bar. so no point to waste your time redoing things.

#6

It’s agreed that Wappler isn’t responsible for caching, but it would still be useful to find out if there is a solution. Eg if there were a problem with an image or a css file being cached, then there are solutions to resolve this - eg renaming the files or giving them version numbers. Is there a similar solution to resolve the problem with routes (which is probably a rather more serious problem)?

That’s fine, but I suspect the many people who requested this feature might disagree with this view. Whether or not users look at the address bar is probably not the only consideration (or even the most important one).

#7

There is no way to clear the client browser cache programmatically.
either the users clear it themselves or as @TomD suggested by renaming the file

if the file you want to force to be changed is js file then there is some workarounds.

#8

I think this is the question - what is the solution/workaround (if there is one)?

I haven’t experimented with the router feature - but shall soon do so. Perhaps something will be clearer then, but it would be useful to have an answer beforehand. I wouldn’t have thought there would be any out of date js files which would be cached and which would cause the problem. Perhaps renaming the target files is a solution, but it would be good if there were a more convenient one.

#9

you could use this to load the file you need to force to refresh
<script src="myfile.js?version=1.0.0"></script>

and you can try to use this in your HTML

<meta http-equiv='cache-control' content='no-cache'>
<meta http-equiv='expires' content='0'>
<meta http-equiv='pragma' content='no-cache'>
#10

I appreciate that version numbers can be added to css and js files etc. to get round caching issues, but I still don’t know how this applies to the current issue. I wouldn’t have thought any js files would store information about new or out of dates paths or routes. If there is a file to which a version number could be given, and which solve the problem, do you know what it is?

Your second suggestion might be a solution, but it would be a pity to disable all caching if it’s not necessary.

#11

Guys, that’s not a bug, nor it’s related to Wappler in any way …
It’s a normal browser caching behavior, as for any other thing on any other website.

#12

I don’t think anybody is suggesting that the browser caching behaviour is abnormal or is a problem with Wappler. However, if you’re familiar with the nature of the caching problem you can consider a solution - eg if there are particular css, js or image files which shouldn’t be cached.

In this case, it doesn’t seem to be clear where the issue lies exactly, so there’s not an obvious solution. Do you have any suggestions?

#13

Well the topic was posted in Bugs category - that’s the reason for me to clarify it’s not a bug and that it’s not related with Wappler.

No there is no an “universal solution” for browser caching … this could be any of the files which were changed - the page HTML which is missing the base tag, app connect js that doesn’t parse the URL correctly etc. Just a normal browser behavior.

#14

The topic was originally posted in the Bugs category, but I saw it was moved. In any case, it wasn’t at any point suggested that browser caching is a problem witih Wappler.

I don’t think anyone was interested in a “universal solution” for browser caching - just a very specific solution for caching in relation to the new routing feature.

From this, it would seem there isn’t an isssue at all, and, if there seems to be, it’s because of an error which can be corrected. If I’ve understood you correctly, this is reassuring. My concern from the original post is that an existing site which is updated to use the new routing feature could become unuseable (at least, impossible to navigate) if the user had previously visited the site and had the relevant data cached (the data causing the out of date routes/paths to conflict with the new ones).

#15

Just to add my 2cents - there is actually NO caching problems when switching to URL rewrites (routing) for your web site.

Because you are actually switching to new url structure - so you have a complete different urls (well accept your web site root of course)

So once the visitor comes to your site all the new urls will be picker up. Browser caching is url based so if the urls are different - nothing will be cached.

#16

Thanks George. This is what I would have thought - so if there were a problem, I wouldn’t know where to look. I wanted to be prepared before I start using the feature on an existing site.

Having said that, I would be interested if @nshkrsh finds a solution to the issue he had - and what caused it. He is clearly an expert developer and I wouldn’t have thought he would have overlooked anything obvious.

#17

George is correct about the html, but the javascript urls didn’t change and can still be retrieved from cache. How long it is being kept in cache depends on your server config.

If you want to prevent caching you can edit your htaccess, but normally the browser doesn’t cache that long.

2 Likes
#18

@mrbdrm This is one use case. But depending on the projects, there might be different uses of this. Eg: In my project, I have an option to send email & WhatsApp which contains the link. Using the new routing I can clean up the URL to be more readable.
Its not about whether the user will care or not, its about the UX.

I didn’t think some JS would be affecting the routing either. But since I did experience the issue, I came here looking for answers. I still haven’t been able to pin down the issue.

That was because it bugged me. :sweat_smile:
But seriously, I did actually thought there could be a bug. Its good to know that there isn’t.

The issue I am facing might be because the user already has cached JS, and even though the URL is completely new, JS/CSS links have same old path.

@patrick to the rescue. I have made the change that was breaking my application on one page, and have set these cache preventive measures too (just for .js). Will see for a few days if any issues are reported by users. :crossed_fingers:

Thanks you all for the input & help. :+1: :slight_smile:

#19

Actually even if js/css files are cached their paths aren’t changed in the new routing, nor their contents in any way. So it’s all fine

The only thing I could think of is that if your pages report not found js/css files is that the base tag we auto generate based on your site settings is not right or missing ( it’s a project option)

But then you will see this problem immediately as the routed pages just won’t work with you as well

#20

Upon more testing, I could replicate the issue and informed @George of the same.
There is NO bug with routing, but he did discover a bug with browser.goto action, which is confused while redirection and requires a small fix.
@TomD if you have browser.goto in your application, it would be better to wait till next update.
Other than that, I have not encountered any other issues with routing.
Thanks everyone for contributing. :slight_smile:

3 Likes