Experiences that force the user to think about the browser cache are sub-par :). Anything that changes the URL will interrupt caching so just adding a query parameter &_v=8.1.1 (or whatever) to every request would probably do the trick, there's no need to mess with file names or file locations IF the UI can easily do such a thing. One could write javascript to find all the src/href etc on the page and append... as for whether that's easy in our actual UI, I don't know. haven't tried to work with it yet.
On Wed, Jun 5, 2019 at 4:22 PM Jan Høydahl <jan....@cominvent.com> wrote: > Could perhaps the UI have a version hard coded, and when the dashboard > fetches /admin/info/system it compares the version, and if newer than what > is in the JS, it will pop up a dialogue to ask user to reload and clear > caches for the site in browser? > > Jan Høydahl > > > 5. jun. 2019 kl. 20:47 skrev Shawn Heisey <apa...@elyograg.org>: > > > >> On 6/5/2019 11:10 AM, Colvin Cowie wrote: > >> Upon opening the Admin UI I got some nasty behaviour, which appears to > be a > >> result of some the Solr 6 Admin UI pages being cached. > > > > In general I would consider this a bug, and a good reason to raise an > issue in Jira. > > > > The admin UI should tell the browser not to EVER cache items that could > change. > > > > We could probably go with "don't cache anything" ... but some of the > files the admin UI uses are quite large, so I don't think it's a bad idea > to let the browser go ahead and cache things that are not likely to change, > especially if they have a version number in the filename. Maybe for large > things that don't have version numbers, which includes files like > "angular.js", we could tell the browser to only cache it for a short time, > say 5 to 15 minutes. > > > > An alternate idea for discussion ... we could modify the URLs so that > everything that can be cached has a version number. Maybe by putting it in > a subdirectory that contains the release version, like "v8.1.1" or > "v8.1.2-SNAPSHOT". It would make the build process a little more > complicated, but I think it would also make sure that problems like this > never happen again. > > > > Thanks, > > Shawn > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
