9 Replies Latest reply on Aug 23, 2007 3:32 PM by Gravenstein

    Link checker for webhelp output

    Gravenstein Level 2
      Our webhelp has a lot of files (thousands) and a lot of links (even more). If possible, I'd like to automate testing of those links. Does anyone have any recommendations for automated link testing tools? I did see a reference in another post to Xenu, and I liked the price!

      Our security policy restricts us from simply downloading any old thing from the internet, so I'd like to find out as much as I can about these tools before spending time on the administrative effort it'll take to try them out.

      Thanks for any recommendations (or warnings!).

      Cheers,
      G
        • 1. Re: Link checker for webhelp output
          MergeThis Level 4
          Xenu is terrific; I've been using it for almost three years, now. Just point it at your main start page, and let 'er rip!

          I save the results into an .html file, then open that file in Notepad to strip the irrelevant stuff. You might find it duplicating the occasional result because of case differences. I also get links not found to external web sites to be erroneous.

          Between this product, FAR, and ExamDiff Pro, I can't imagine maintaining our 40-project, 2.5K-topic merged WebHelp without them (maintaining two concurrent major versions). Especially now that I've incorporated Zoom search as well. As to FAR and Zoom, their original designers often are the ones to answer your requests for assistance. Although I haven't had to contact the other two, I wouldn't be surprised if their responses were similar.


          Good luck,
          Leon
          • 2. Re: Link checker for webhelp output
            msiano
            You've also got the built-in checker for internal links, Tools > Report > Broken links.
            • 3. Re: Link checker for webhelp output
              Gravenstein Level 2
              Thanks, Leon. That sounds like a ringing endorsement to me! I think I'll look into Xenu. I'm also intrigued by your comment about incorporating Zoom Search, as we're looking at it as well. Did you incorporate it directly into your help project, or are you using it as more of a development tool? Any further insight in that area would be appreciated, too.

              msiano, thanks for the reminder about broken links. We do indeed use the broken links list.

              Cheers,
              G
              • 4. Re: Link checker for webhelp output
                MergeThis Level 4
                If your topics begin with an H1 title heading that matches the topic's html title (in the head section), you need to wrap it inside ZOOMSTOP/ZOOMRESTART Zoom tags. Otherwise, the "Meta description" would include that repeated title at the start of the first few lines of topic content. We also needed to wrap, in the same manner, a right-aligned DIV for InThisTopic and RelatedTopics links (a sort of "topic site map"), as well as "Return to Top" and mailto "Feedback on this topic" links at the bottom of each topic.

                However, RH completely ignores those Zoom tags in the generation process (it just leaves them behind). Adding these to the output after each generate/publish, in a 40-project merged WebHelp product, would have simply been impossible.

                Our solution here is to run Zoom agaainst the source files, instead. Options abound, such as Zoom delivering its output files to a different directory (the output file directory). I have to run some FAR batch files aginst the zoom_pageinfo.js file to:

                1. Do some lowercase stuff (which our release Engineers already do to all the htm files with some Perl scripting)
                2. Change all path names from /projects to /mergedProjects (obviously unnecessary if you don't have a merged project).
                3. Remove the additional space that Zoom mysteriosly adds before punctuation (commas, periods, etc.), which they've said should be taken care of in a future build.

                Their help is very clear, and the User Forum postings are almost exclusively responded to by two Zoom staff (Ray and David, the owner). We're using the "offline JavaScript" mode, using a separate search.html page for search entries and results (hooked up by disabling the default Search toolbar button and replacing it with a custom Search button. The JavaScript mode doesn't provide as advanced a search as the other modes (php, cgi, etc.), but we're delivering the help to customers with the application for use on their servers, not hosting it ourselves. This mode, we decided, was the simplest way to go, and still offers much better results than with RH alone. Other great Zoom features are Synonyms, Recommended Links, etc., etc., etc.

                Great product, especially when used in concert with the ones I mentioned previously! Managing a help output of this size and complexity (all the while trying to cater to management's evolving wish list of help features) would be impossible without my "best friends."


                Good luck,
                Leon




                • 5. Re: Link checker for webhelp output
                  Peter Grainge Adobe Community Professional (Moderator)
                  I'll happily endorse what Leon has said about ZoomSearch. There's a tutorial on my site but note I implemented ZoomSearch in a different way to Leon. I first encountered it based on a recommendation here and implemented it working with the output files. My logic being that they contained the words to be searched for whereas the source might contain additional wording excluded from the output by a build expression.

                  If I recall correctly, Leon started to use ZoomSearch when I said what a great tool it was and his own tests made him a convert. However, he needed to use ZoomSearch in a different way to meet his needs.

                  Between my topic and Leon's posts here, you should be able to decide what works for you. If you do need to contact ZoomSearch, do mention hearing about the product on this forum. The more RH users they know are using their product, the greater their incentive to make changes that suit us, as I know they did for Leon.

                  In one implementation, the javascript wasn't up to the job for me. I followed their help that allows php scripting to run on a server not set up for php and it worked well. That method also allows the php method to work on a CD/DVD if you need it for demo purposes.

                  • 6. Re: Link checker for webhelp output
                    Gravenstein Level 2
                    Wow, that's terrific info, you guys! I see I am going to have to do a little homework on how well our headings match up with what Zoom wants.

                    Leon, you mentioned your large merged webhelp project with beaucoup component projects. Do you ever deliver different configurations of that project to your clients? What I'm trying to get at is how one would configure ZoomSearch to manage a configurable set of help projects, rather than an unchanging monolithic set. For example, Client 1 has help projects A, B, and C installed, while Client 2 has help projects A, C, and D installed. The same Zoom Search index would not be appropriate to both client installations. Have you managed to surmount this problem as well? (Sorry - perhaps this ought to be posted separately.)

                    Thanks again Peter and Leon. I sure appreciate the feedback from the trenches. And if I get the chance, I'll certainly mention to ZoomSearch where I got the recommendation.

                    Cheers
                    G
                    • 7. Re: Link checker for webhelp output
                      Peter Grainge Adobe Community Professional (Moderator)
                      One thing you can do with ZoomSearch is have the Search button you create call a topic with a number of buttons that access a filtered search. So Buttons 1 is Search in Product A, another button is Search in Product B and so on.

                      You then tag those buttons to suit a particular build.

                      Doesn't address the problem of the all help search across a configurable set of projects. Not sure how you could do that without multiple searches being created. Any ideas Leon?



                      • 8. Re: Link checker for webhelp output
                        MergeThis Level 4
                        No, G, we only deliver the entire help system; the consensus here is that the help modules for portions of the app that the customer didn't buy will serve as free advertising.

                        To expand on Peter's last post, I think you'd probably need to think about how you could get your developers to create some privileging controls and/or create separate Zoom indexing passes for multiple project configurations, which would then be placed into separate folders. You and your developers could then set up some simple alias files that would call the Zoom results from the appropriate folder.

                        If you could get that worked out, the same format could be expanded to encompass any number of future combinations. The downside is that you and your folks need to put in some design time to get this working in an easily maintainable structure that will suit your needs.


                        Good luck,
                        Leon
                        • 9. Re: Link checker for webhelp output
                          Gravenstein Level 2
                          I thought it might end up being something like that...Sounds like we'll have a future enhancement to implement sometime.

                          Thanks so much for your input on this - it sure helps!

                          Cheers
                          G