Moving to HTTPS from HTTP for Madcap Flare 8 project

[jbrock]

We're planning on moving our whole website from HTTP to HTTPS. Of course, this means we'll need to do the same with our Flare project. I wanted to see whether anyone had done this and what problems may have arisen.

I'm particularly concerned about internal links. I want to change all

Code: Select all

http://www.mysite.com

links to

Code: Select all

//www.mysite.com

.

But I don't know how Flare will handle this. Links to stylesheets and js files in the masterpages should be fine, but how will cross references and other links be handled?

Other than that, Cyrus Shepherd's "The Big List of SEO Tips and Tricks for Using HTTPS on Your Website" article has been particularly helpful. The Flare pieces just worry me some.

[jbrock]

Ok, I guess I'll just document my own answers as I find them and post here for posterity.

Protocol Relative Urls Don't Work In Flare

The easiest way to move to HTTPS from HTTP in most web publishing tools is to use protocol relative urls, thereby allowing the server to serve the content with the scheme we define. If we could go this route, we'd be able to make all the changes early and just let the web team switch over the rest of the site whenever they're ready.

Naturally, I wanted to modify all links in our webhelp target that point to

Code: Select all

http://www.mysite.com

so that they point to the protocol relative url instead:

Code: Select all

//www.mysite.com

It doesn't work, folks.

Well, technically, it does. However, Flare views each protocol relative url as a link to file:// on the local file system. Therefore, it issues a "link to a file outside the project" warning when you build the target for every protocol relative link it finds. These warnings slow the target build time dramatically, making what was a 5-10 minute build take hours. So yeah, it doesn't work.

Stay Tuned for the Next Post, in Which We Test the Find/Replace Function
The next step is to do sitewide find/replace to turn http://www.mysite.com into https://www.mysite.com

[NorthEast]

Presumably this only applies to external links outside the project; i.e. those with a http prefix in the href?
All internal links and cross-reference inside the project would have a relative path (i.e. no http prefix).

Anyway, I can't offer any help, but thanks for the info - I'll bookmark this one for the future.

[ruthhoward]

However, Flare views each protocol relative url as a link to file:// on the local file system. Therefore, it issues a "link to a file outside the project" warning when you build the target for every protocol relative link it finds.

I put in a bug/feature request with Flare to be able to tag links somehow as "I promise this will work, don't check it". I have links from help sets to other HTML files that are available in a product installer but which aren't part of the Flare project and aren't there at build time. So at the moment these get reported as bad links - but they aren't when the whole product is put together. I want a way to indicate to Flare that this is not a relative link for the source but for the final output in combination with other things.

This situation also applies to trying to link between PDFs generated from the same project - if I generate 3 PDFs and want to link between them Flare complains because PDFA isn't next to HTML source file at compilation time, but it IS when I've run my build and moved the two files next to each other. I asked Mike Hamilton about this at a conference and he didn't have a solution.

[jbrock]

I put in a bug/feature request with Flare to be able to tag links somehow as "I promise this will work, don't check it".

Rather than having a setting like that for individual links, I'd like a setting like that at the target level. Just build it - Don't validate it! That would be a splendid option to have for what we're doing.

[ruthhoward]

I think Flare 10 provides that. On the target Warnings tab there's a checkbox for "Use target build warnings instead of global settings" or you can set it for all projects on the current computer in File | Options | Build.

I want to be able to flag individual links to be ignored for validation - I have about 0.0001% of all links that fall into this category. But it only takes one in 10000 links to be "external and it will work in the product" for Flare to throw an error - those are the ones I want to be able to ignore. I wouldn't want to not validate all links.

[jbrock]

I think Flare 10 provides that. On the target Warnings tab there's a checkbox for "Use target build warnings instead of global settings" or you can set it for all projects on the current computer in File | Options | Build.

I'll have to look into that ... still on Flare 8. When it comes to webhelp, we approach Flare more like Dreamweaver than Robohelp. I'd like it to trust me to test my own project.

[jbrock]

Stay Tuned for the Next Post, in Which We Test the Find/Replace Function
The next step is to do sitewide find/replace to turn http://www.mysite.com into https://www.mysite.com

So this is the next post. After quite a few slow builds, I decided to "hard code" HTTPS into the urls. Turns out, the Find/Replace utility in Flare - at least in Flare 8 - doesn't work like I needed it to for this.

flare-find-replace.png

When I ran the Find/Replace utility, Flare missed a lot of snippets and masterpages. What's up with that?

As a solution, I opened the project in Dreamweaver ... yes, it will open .flmsp and .flsnp files, surprisingly! Dreamweaver searched the code the way I needed it to.
Here are all the places I had to search

• /content/topics

• /content/resources/snippets

• /content/resources/masterpages

• /content/resources/*custom styles and javascript*

I also needed to change other settings:

• Variables that include the URL

• Site URL in the Target > Advanced panel under "Search Engine Optimization"

flare-change-url.png

That about covered it. The only problem now is that I have to time the switch to HTTPS with the rest of the site switch. If the protocol relative url path had worked, we would have been able to make the switch for our webhelp right now. As it stands, we just have a bit of coordinating to do. Still, it's good to know that the process of moving to HTTPS - at least the Flare part of the process - is not terribly difficult.

I may have an update to give when we finally do pull the trigger. But things look hopeful for now.

[ruthhoward]

Flare search/replace is notoriously terrible in 8 and 9. Much nicer experience in 10 though I'm not sure whether it properly works from non *.HTM files. I use Notepad++ for all that sort of thing.

I would definitely recommend an upgrade to 10 though if you can persuade your company to invest. Its a lot better in so many way - faster build times, less flakey UI, more reliable link fixing when you rename things, project DB smaller and faster to build - so things like link checking in the Link Viewer are faster.

Glad you got HTTPS working, wish I could get links between PDFs to be as well behaved!

[NorthEast]

When I ran the Find/Replace utility, Flare missed a lot of snippets and masterpages. What's up with that?

In that screenshot, you've got File Types set to Topics - so it'll only search topics.
Also Find in Source code needs to be ticked.

Just to ask, why do you have absolute links with a http:// prefix in the first place?
If you used relative links, these would have no prefix, so presumably wouldn't need fixing for https.

[jbrock]

In that screenshot, you've got File Types set to Topics - so it'll only search topics.
Also Find in Source code needs to be ticked.

True, but in Flare 8 my only two options are "Topics" and "CSS". No way to select snippets, masterpages, or other items.

Just to ask, why do you have absolute links with a http:// prefix in the first place?
If you used relative links, these would have no prefix, so presumably wouldn't need fixing for https.

Great question. It's because we're doing this with our webhelp. If I recall correctly, there was some trouble getting cross references and bookmarks to work properly in masterpages or templates, so some of the navigational paths needed to be fully qualified links.

bomgarwebhelp.png

The SEO benefits of doing Flare this way have well outweighed the work we put into making it. Customers have been finding and using our content way more than they were when it was all buried in PDFs. You can see a sample of the framework I made for this over at Flarestrap.com. It's still quite the work-in-progress, but I'm taking feature requests.

[kathryngz]

I think Flare 10 provides that. On the target Warnings tab there's a checkbox for "Use target build warnings instead of global settings" or you can set it for all projects on the current computer in File | Options | Build.

I tried this in Flare 11 to solve the problem with Flare changing protocol-relative links to file://blahblahblah.com

But it didn't seem to work. Has anyone found another solution, or a way to make this one work?