We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.
HTML5 Responsive out with Azure_Blue skin
Merged output (1 parent, 11 children)
Output resides on an IIS internal web server for access by internal staff (either onsite or VPN)
If 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.
It's not something I have seen reported so given you have asked your own IT to look at the problem, in this case I suggest that unless anyone else does now respond, you wait for IT's response.
One thing you could try meantime is regenerating the parent as well. It shouldn't be necessary to the best of my knowledge but it's easy enough so worth a try.
See www.grainge.org for free Authoring and RoboHelp Information
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.
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...
My particular experience was with an IIS webserver, but this general solution should apply for others.