Yes, I have the "Enable substring search" box checked on the Search > Search Context page. As noted in a separate message I sent you, I think a more precise wording of the bug would be: The system does not find a topic that includes a "search" keyword (multiword keyword or single-word keyword) if: 1) the topic does not include the “search” keyword in the body of the topic (which is the purpose of adding a “search” keyword) and 2) the user puts the "search" keyword in quotation marks when performing the search. ... View more

Since we posted at about the same time and since my findings were different from yours, please see the second part of my reply before posting the bug report.  Thanks! ... View more

My bad. I only tested half of what you asked me to test. I tested multiword "search" keywords. I did not test single-word "search" keywords. I did not get the same results you did.. If I used quotation marks to search for "gray" where "gray" was a "search" keyword and appeared in the text of the topic, a search for "gray" within quotation marks located the topic. If I used quotation marks to search for "purple" where "purple" was a "search" keyword that did not appear in the text of the topic (i.e., did not appear anywhere within the html body tags), a search for "purple" within quotation marks did not locate the topic. The bug is that the system does not find a topic that includes a "search" keyword (multiword keyword or single-word keyword) if the user puts the "search" keyword in quotation marks when performing the search. ... View more

I tested on a different project. I found the same results involving "search" keywords. If I used quotation marks to search for "gray diamond" where "gray diamond" was a "search" keyword and appeared in the text of the topic, a search for "gray diamond" within quotation marks located the topic. If I used quotation marks to search for "purple circle" where "purple circle" was a "search" keyword that did not appear in the text of the topic (i.e., did not appear anywhere within the html body tags), a search for "purple circle" within quotation marks did not locate the topic--and this is the issue/bug. ... View more

If it helps, here is my original post, with the paragraph breaks. I have also put one sentence in bold. I am using RH 2022.5.28 and generating frameless output.  I want a user to be able to find via the Search a topic that contains a search keyword (whether the keyword is one word, such as 'POS', or a multi-word keyword, such as 'point of sale') which appears as part of a comma-delimited list (no quotation marks around the individual keywords) in the content section of the search-keywords meta tag in the header but not in the body of the topic.   Using the generated output, if I search for the topic by placing the keyword within quotation marks (e.g., "POS" or "point of sale") in the Search field, the system does not find the topic. Should it? I was expecting it to.   Using the generated output, if I search for the topic without placing the keyword within quotation marks in the Search field, I get a LOT of matches, which do include the topic, but may bury it so deep I am not likely to find it.   When I search for POS without the quotation marks, for example, I get 426 matches: every topic that includes the whole word 'POS', every topic containing 'PO' (where the system appears to allow PO as a singular form of POS), and every topic containing any word containing 'POS', such as position, posted, deposit, proposal, etc.  In this situation, the topic gets buried so deep a user is not likely to find it. If I search for point of sale without the quotation marks, I get 379 matches: every topic that includes 'point' and/or 'sale'. In this instance, my topic is somehow listed as the first of the 379 matches, possibly because no other topics include 'point' so close to 'sale'.  While I am not disappointed to find the topic this way, it seems counter intuitive to expect a search to find my topic when I don't use quotation marks around a keyword that contains such commonly used words and to not find my topic at all when I use quotation marks around the exact single-word or multi-word keyword, as if doing a consecutive word search.  Is this how searching for a search keyword should work?  Thanks! ... End of original post, with the paragraph marks and the sentence in bold.   Peter, in my online help, I have included information on using quotation marks when searching for a specific multiword string.  That is what I and my users expect to be able to do.  See the sentence above in bold. In every test I performed, putting a search keyword (whether a one-word search keyword or a multiword search keyword) within quotation marks when performing a search via the output did not locate any of the topics containing the search keyword.  That is my main reason for writing this post. Again, I thought this functionality should work. It does not.   Also, just to be clear, I am talking specifically about keywords added to a topic as "search" keywords.  Please see the following image: UI: HTML Results using quotation marks around search keywords:   Again, the search will find the topic containing a "search keyword" (including finding the term in a substring as I indirectly noted in the original post) if I do not use quotation marks when performing the search, but that will make the search virtually useless in scenarios where the system returns 100+ matches and the topics users are trying to find are buried in the list. ... View more

Thanks! ... View more

I am using RH 2202.4.179, and I am also generating frameless help.  I occasionally get search results like that, too, where I see a count of matches but no matching topics are listed.  For me, it does not happen all the time.  I think clearing the cache helps. ... View more

Thank you to all who have helped troubleshoot this issue! LT Documentation, I was able to copy my working topicpage.js file to the source file locations and generate frameless output where the mini-TOC links work on our servers.  At least on my system, I see that the topicpage.js file is included in four source file locations.  I replaced it in three of them, not realizing I had missed one, generated the output, and still got the non-working topicpage.js file in the generated output.  The generated output included the working topicpage.js file for me when I copied the working topicpage.js file to the C:\Program Files\Adobe\Adobe RoboHelp\resources\data\frameless\js folder. While it may have still been necessary for other reasons to copy the working topicpage.js file to the other three folder locations, the generated output files did not include the working topicpage.js file if I copied it only to the following three locations: C:\Program Files\Adobe\Adobe RoboHelp\resources\data\template\layouts\preview\en_us\frameless\template\scripts, C:\Program Files\Adobe\Adobe RoboHelp\resources\data\template\layouts\preview\en_us\frameless_homepage\template\scripts, and C:\Program Files\Adobe\Adobe RoboHelp\resources\data\template\layouts\preview\en_us\frameless_topnav\template\scripts. Jeff, thanks for note to save the working topicpage.js file for replacement after applying future patches (provided Adobe does not otherwise resolve the issue and make a correction to include in the next patch). Peter, thanks for doing the testing on your server.  I still wonder what the differences are between our servers, differences that would allow the mini-TOC links to work on your server and not on ours. Glad to now have a workaround that does not require me to copy-and-replace files every time I generate and publish a new set of output files for any of our projects.  Again, thanks! ... View more

I uninstalled RH 2022.4.179. I rebooted.  I downloaded RoboHelp_16_LREFDJ and ran the Set-up.exe file. I checked for updates. The installer installed RH 2022.4.179, so there were no updates to install. I do not have an old copy of my project files to go back to, so I could not update/upgrade my projects from the previous version.  I verified that the source topicpage.ejs file still had the 3/29/2021 11:54 AM date/time stamp.  It does.  I generated the output files from one of my projects. I could tell from the file sizes on the two generated topicpage output files that the system had generatted the larger (non-working) files.  I SFTP'd them to our stage2 server anyway, after removing the entire contents of the existing output folder. I am again getting the 403 error on any mini-TOC link I click.   Jeff, yes, the "good" topicpage output files I sent you were generated from the same topicpage.ejs source file identified above, but were generated using a prior version of RoboHelp. ... View more

I don't see an envelope at the top right of the browser window.  I also have PM enabled, but I did not receive the PM you sent, Jeff. I did receive an email that you sent it. Is it possible for my IT to have locked that feature out? I do see the Notification (bell) icon, but clicking that icon lets me know I have received notifications but does not show me the details of the notifications.     Peter, just to clarify, I see three topicpage files: topicpage.ejs, topicpage.js, and topicpage.js.gz.  The first one, the topicpage.ejs file, resides in the skin folder of the RH project.  This is the file that is identical in the projects from which "working" output files were generated prior to installing the last update and from which, at least on our web servers, "non-working" output files are now being generated after installing the last update.     When output files are generated, I am presuming the system is using the topicpage.ejs file, at least in part, to generate the topicpage.js and topicpage.js.gz files that appear in the template\scripts folder of the output files.  From the same source file, the system is generating these two output files differently after the last update than before the last update.  The files generated before the last update are smaller than the files generated after the last update.   Given what appears to be the limitation of my not being able to see the PM functionality (and please let me know if you see it in the first attached image and I am just missing it), I see a few possible options. Peter, you have my email address. Please feel free to share it with Jeff.  If you want to see the .js files, too, and want me to send a zipped file to you to share with Jeff via your web site, let me know. Thanks!   ... View more

Jeff, again, I will be happy to share the working and non-working files. Let me know how.  If it is reasonably safe to include an email address here, let me know and I will add mine so that you may contact me. It may also be easy enough for you to generate them using the current and previous versions of RH and, in my case, the Orange skin. Peter, I logged a bug report with Adobe quite a while back.  I had less information at the time.  They may have also been ready to conclude the issue was a permissions issue.  I also subsequently contacted Adobe Support by email.  I mentioned several issues (not just this one). So far, no progress (at least that I am aware of) on any of the issues I sent. One Oddity: As reported previously, when removing the span tags, the mini-TOC links worked on our web servers when using the otherwise non-working topicpage files. When using the working topicpage files, the links worked AND the inspect showed that the span tags were still present (definitely not what IT and I expected). ... View more

Jeff, not sure how to send you a PM. ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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.  ... View more

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! ... View more

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. ... View more