403 Error when using Frameless Output Mini-TOC - Part 2

[Timothy386187870sd3]

I reported this same issue in a different post ("403 Error when using Frameless Output Mini-TOC") searlier this month, and I am still experiencing the issue.  Peter, you and Jeff said no one else had reported the issue. You also suggested in that post that it might be a webserver permissions issue.  I still think it is a RoboHelp issue.  One of our IT people looked at this issue with me today. I showed him a copy of the project generated with an older version of RoboHelp, where the miniTOC links work, and a copy generated with RH 2022.4.179, where the miniTOC links do not work. He had me inspect a miniTOC link in the output that works and in the output that does not work.  In the output that does not work, he found an extra set of span tags. See the image below.

He removed the span tags from the link that did not work, and the link worked again.  Does this still sound like a webserver permissions issue?  Is there something I could have done in the project that would have added the span tags to the miniTOC links?  Given the above, does it sound as if this is an RH bug that I should report? Thanks!

Note: As noted in the other post, the miniTOCs links in a frameless project generated with RH 2022.4.179 work if I test them locally, but they do not work after the project is copied to a server.

[Jeff_Coatsworth]

Fixed up your post to point to the other thread.
I think you have a combination of issues going on here -
1. Whenever somebody says "works locally, but not on the webserver" our instant suspicions are aroused that there's either (a) some file(s) missing or not updated on the web server OR (b) some setting on the web server that is causing the issue.
2. If some of these links work and some don't, then you are correct in having a look at both to see what's going on. I can't tell, but are you doing this inspect feature on the output (if so, where is it - local or on the webserver?) or are you looking at the source RH project topics? Is there something different present in the source locations between the working one and the non-working one? 

[Timothy386187870sd3]

I mentioned "works locally" (means the links work if I click them from a topic in the output folder on my PC where I generated the project) just to be clear that the links do work from this location if someone is only testing them from this location.

I have tested all my stage and production web sites.  The mini-TOC links do not work in every set of output files copied to a stage or production server that were updated (generated) using RH 2022.4.179. The mini-TOCS links do work in every set of output files copied to a stage or production server that have not been updated (generated) using RH 2022.4.179. And, to be clear, both the stage server and the production server contain copies of files that work (generated prior to RH 2022.4.179) and that do not work (generated using RH 2022.4.179).

As part of my test today with IT, he had me access a mini-TOC link on a server in a project where the link works. He had me regenerate the same project using RH 2022.4.179. I SFTPd the files to the same server. The mini-TOC links no longer work on that server.  He inspected the links using files on the server, not on my local system.

[Jeff_Coatsworth]

Back to my point #1 - if it works locally & you've replaced all the files on the web server (safest method for that is to delete them all first, then FTP them up again) and they still don't behave, then it's usually a caching issue on the web server. As Peter says, sometimes leaving it alone for a while will clear the cache; sometimes you have to have IT flush the cache manually if it's set particularly persistently. 

[Peter Grainge]

Leave a "broken" output on the server for an hour or two then test it again. I'll explain in the morning. 

________________________________________________________
My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Peter Grainge]

I have found that updating the styles applied to the minitoc can take a while before they show. I have been told that depending on server configuration some files may not work for a while. I don't undertand why but have found it to be true.

Let's now assume you have left it a while and the problem persists. All publishing does is copy the generated files to the server and you say the output works locally. If follows that the problem must be either the server or the publishing.

As @Jeff_Coatsworth has suggested, trash everything in the target folder and then transfer the files by some other process than publishing from RoboHelp..

As I said before the reason I don't think it is a RoboHelp issue is no one else is reporting this. Can you create a small project that has this problem that you can share with me? If you can, I will publish it to my server to see if the same thing occurs. If you can, then see the Contact page on my site and send the project as instructed there. Do make sure you include a link to this thread and please do not email the project direct.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Peter Grainge]

Tests with a sample project @Timothy386187870sd3 sent me did not give the 403 error. That points to the problem being server permissions. I have asked Tim to confirm he sees the issue with the project he sent me.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Timothy386187870sd3]

Peter, thank you for testing the project I sent you.  I know it included the error I am seeing on our web server.  I clicked the link you sent me, and the mini-TOC links in that topic work as expected.  I am still at a loss to explain how one copy of the project can work fine on our server and a newer copy of the project on the same server gives the error, but I will go back to our IT team with the new information you provided and see what they can figure out. Thanks!

[Peter Grainge]

If what you sent me is what errored on your server but does not error on the server, then it has to be permissions.

If what I have is not the same source project or the output you sent is not the one that errored, then send me what doesn't work for you.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[April38363617si18]

Hello, We are also experiencing issues with the mini toc. I looked through our "output" which is generated to a private server where the users have to have a login to see the information. I looked for the <span><span> and did find it in the output but not in the individual RH development page.  Thanks for this information it has helped us narrow down where to look. As in above not all of the links have the issue and we are not getting the 403 error. It is redirecting to a different link.

[Peter Grainge]

@April38363617si18 Your issue is about going to the wrong topic whereas this thread is about a 403 error. If you haven't solved the issue, then update "your" thread to see if anyone can help further.

________________________________________________________
My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Peter Grainge]

I haven't heard back from @Timothy386187870sd3 so I'm not sure what the outcome is at his end. On my server an output that I understood would produce the error did not. I don't know if @Timothy386187870sd3 found otherwise when retesting.

As far as I can see, it was either a temporary network issue or a permissions issue, not a RoboHelp issue.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Timothy386187870sd3]

I still don't have anything to report. I informed IT that the miniToc links worked as expected on your webserver, Peter, using the frameless output with the miniToc links that do not work on our web servers.  I have not heard back from IT yet.  The issue I am experiencing is not temporary; it is still occurring. The issue @April38363617si18 reported may be the same as mine. @April38363617si18 reported also finding the span tags when inspecting the miniToc links. The span tags create an invalid link. Our web server is interpreting the invalid link as an attempt to access a page the user does not have access to and so displays the 403 forbidden error. @April38363617si18's web browser may be attempting to display the web page using the invalid link, which is why the system does not jump to the miniToc location on the page displayed. That said, I do not know why the span tags show on our two web servers and not on yours, Peter. 

[Peter Grainge]

Can you confirm 100% that what you sent me is the same output that failed on your server? I did email you but didn't hear back.

I haven't checked what you sent for span tags but if they are there and not causing a problem on my server, doesn't that rule them out? 

Point me a topic to that should have them.

________________________________________________________
My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[April38363617si18]

Just an update, our issue has been fixed. It was a conflict in our CSS. We had been adding items like underline to the header that was not in the CSS. When the link was clicked it was reading the linke as blank so it was redirecting to the home page. I agree with Peter I don't believe these are the same issues you are seeing.

[Timothy386187870sd3]

April, glad your issue has been fixed!

Peter and Jeff, I spent another chunk of time with one of our IT people trying to resolve our issue. No resolution at this time related to permissions.  I did some additional testing using one of our sites generated with an older copy of RoboHelp where the miniTOC links still work.  I started replacing files to see if I could determine which file(s) cause the links to stop working.  It is one file: /template/scripts/topicpage.js.  This folder also contains a topicpage.js.gz file.  I do not know when that file is used, but replacing only that file did not cause the links to break.  I restored the old topicpage.js file, and the links started working again. I copied the topicpage.js file to a different set of help output folders, replacing the file of the same name.  The links in that folder started working again.  I checked version history on my system to see if I could restore an earlier version of a project's publish\skins\[skin_name]\topicpage.ejs file (which I suspect is the file on which the output folder's topicpage.js file is based). No earlier versions are available. I am not yet sure what the consequences will be if I replace the problematic file in all help outputs where the problem exists with the file that works.  I have not had any additional time yet to troubleshoot the differences in the file that does work and the file that does not work.

[Timothy386187870sd3]

I compared the topicpage.ejs in my main RoboHelp project folder (where the output links do not work) with the topicpage.ejs file in a different RoboHelp project folder (where the output links do work using output files generated before upgrading RH to the latest version).  The files are identical, and the "Date Modified" listed for both files is: "3/29/2021 at 11:54 AM." If I generate new files from the project where the links in the output worked prior to upgrading RoboHelp, the links in the output (copied to the same webserver where the working copy of the output resides) do not work.

[Peter Grainge]

When you say "compared", do you mean just the dates or did you compare the content. I am wondering if it is possible for something to corrupt in the file without changing the dates? I don't know if that is possible.

The GZ files are to speed up searches. I believe, but am not sure, that it is possible to run the help without them. Whether or not the difference in speed is noticeable is something you would have to test.

Thanks for coming back. 

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Timothy386187870sd3]

I don't think I mentioned this previously, Peter, but I did verify that I sent you the output files that do not work on our web server. They did work on yours.  When I mentioned "compare" in reference to the files, I also mentioned "identical." The files, including their contents, were exactly the same.  I have now replaced the non-working topicpage.js and topicpage.js.gz files in all frameless output folders on our stage environment with working topicpage.js and topicpage.js.gz files, and all the mini-TOC links now work on that web server.  As a short-term solution, I can continue copying these files each time I regenerate a new set of help output files.  Our IT team is looking at the working and non-working .js output files. Again, I do not know if the system uses any files other than the topicpage.ejs file to generate the output folder's topicpage.js file. What I do know is that topicpage.js files generated for frameless output prior to the last RoboHelp update worked on our web servers.  The topicpage.js files generated for frameless output after the last RoboHelp update, using the topicpage.ejs file that hasn't been updated since 2021, do not work on our web servers.  I am still at a loss to explain why.

[Peter Grainge]

If a new generation of a project is creating these files that don't work for you, my first thought was to uninstall RoboHelp and reinstall it. The thinking was something screwed in your installation. However, against that is the your generation worked on my server.

Still worth a try?

You may have tried these things before and it may be mentioned in the thread, my apologies if they are.

1. @Jeff_Coatsworth suggested deleting all the contents on the server and publishing again. Did you try that?
2. Have you tried publishing to a different folder?
3. When you test after publishing, have you tried leaving the output there for several hours and testing again? JS files can kick in later. Don't ask why but I have seen it.
4. How are you publishing? What Server Type are you selecting?
5. Have you tried publishing some other way, a third party tool such as FileZilla or giving IT a zip file to unzip on the server?

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[LT Documentation]

We are experiencing this same issue since upgrading to RoboHelp 2022.4.179.  We deleted all output folders and re-generated all RoboHelp projects locally and then copied over to the server.  We receive a Forbidden error when any "In This Topic" link is clicked, if that link is associated with a drop-down that is assigned to a Heading 2 style.  This was working prior to installing RoboHelp 2022.4.179.  If the link is NOT associated with a drop-down, then the In This Topic link works. Any ideas?  And we even waited to test today after applying files on Friday and that did not solve the issue.  

[Jeff_Coatsworth]

@LT Documentation  Is the output behaving when you generate it locally? If not, can you revert back to Patch 3 (watch out for variable damage) and check with that version?

[LT Documentation]

The output works when generated locally.  We only see the issue when accessed online from the server. 

[Timothy386187870sd3]

All my mini-TOC links go to drop-downs that have the heading 2 style applied.

I am not using RH to publish. I am using FileZilla.

Except in rare circumstances, when copying a newly generated set of output files, I delete all existing folders/files and copy new folders/files in their place.

So far, while inconvenient, overwriting the non-working topicpage.js and topicpage.js.gz files in the generated output folders with the working topicpage.js and topicpage.js.gz files generated prior to installing the 2022.4.179 RH update is allowing all the mini-TOC links to work as expected on our stage and production servers.

No feedback yet from IT on the differences between the working and non-working versions of these files, and it may be a low priority for them since I have a workaround.

[Jeff_Coatsworth]

@Timothy386187870sd3 can you zip both the older working and newer non-working copies of those files and send them to me? Send me a PM & I'll give you an email address to ship them to. I want to dig inside them to see if there's any differences.