Forcing New/Modified Topics on End-Users in IIS-Hosted HTML5 Output

Question

RoboHelp 2020.1HTML5 Responsive out with Azure_Blue skinMerged output (1 parent, 11 children)Output resides on an IIS internal web server for access by internal staff (either onsite or VPN) ISSUEIf we add a new topic in a child project, generate new HTML5 Responsive output, and then copy the entire project over to our IIS internal web server, the new topic doesn't show up in search or the index until/unless a user clears their browser cache - via the clear "Cached images and files" option in Chrome or Edge Chromium (depends on which they're using). Once you do that, the new topic will appear in search results and the index. Also note that prior to clearing the cache, the new topic IS available in the table of contents and from any hyperlink in another existing topic; so that's interesting. I don't know much about web servers - I have a request into our IT team who admins the ISS web server on whether HTTP caching might address this issue. While I wait to hear back from them, my question to the community is whether anyone else has ever dealt with and resolved this type of issue, as well as whether there are specific RoboHelp index and search scripts or files in the OUTPUT that might specifically need to be HTTP cached (terminology?) or otherwise handled on the webserver side. The ultimate goal is that staff/end-users should be able to access new and updated content as soon as we post it/make it available via TOC, search, and the index. Note: We have instructed staff that Incognito/InPrivate modes are NOT supported - we don't want them to get in the habit of using those because we hope to deploy the cookie-dependent favorities function in the future. Finally, the IIS internal webserver is a temporary hosting platform. We hope to move to a cloud-based hosting and more standard web server platform within the next 12 mos. In the meantime, we'd like to be able to push out weekly updates without asking staff to clear their browser cache every time.  Thanks!

RoboFan · Accepted Answer

Update.

Our IIS webserver admin set the entire site to Expire Web Content Immediately, which should force all files (including JS files, which I believe are the backbone to search and index functionality - among many other things) to update every time a request is made. Note: Alternatively, it can be configured to expire after a certain amount of time (15 seconds, 1 minute, 10 minutes, etc.).

I created a test topic in one of my child projects, specifically so I could test the search and index functions. It worked. The new topic appeared in search results and the index immediately after I updated the project on the webserver – no clearing local browser history, cache, etc. for Chrome or Edge required. Prior to this, I had to clear my browser's cache to get a new topic to appear in search results and the index.

A couple notes...

I closed our knowledge base website in my browser before I updated the project on the webserver. Once the files finished copying over, I opened it, and the new topic appeared in my search results and the index.
I noticed after I rolled back the update (copied a backup of the project back over top of the files on the webserver to remove the test topic I created), I had to use the browser's "reload this page" function to get the new topic to no longer appear in search results or the index. I imagine closing + re-opening the browser/tab for the site would have had the same result. Regardless, I did NOT have to clear my browser's cache - or any other browsing history. I think this is acceptable.

My particular experience was with an IIS webserver, but this general solution should apply for others.

Amebr · Answer

For years I've had problems with out of sync toc content for staff. It seems to be related to the toc js files, which I understand are normally cached longer as they are "scripts" that don't change frequently. From general googling, I think the server needs to be changed to not cache js as long, but for various reasons I haven't been able to have that happen. So there's just a standing rule for staff to clear their cache after a new release and come back in 5 min. (not ideal, but sometimes, you just have to roll with it.)

Alternatively, because what seem to be the problematic files all begin with "gXMLBuffer", maybe the script that controls gXMLBuffer has issues and needs a fix.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded