Correcting and updating URLs

'Me' putting the plug in the sink

I've been circling the plughole this morning, trying to figure out why 3 of the ISO27k standards detailed pages had different URL structures to the other 97. Specifically, the URLs for the pages on ISO/IEC 27000, 27001 and 27002 contained something like 'title- here'.

Wix offers a function to define the 'URL slugs' for the pages constructed dynamically from the CMS content, using one or more fields from the CMS to generate the last part of the URLs. For example:

The URL slug editing function

According to this setting, the individual standards page URLs should end with the content of the CMS Title field, and 97 did ... but those first 3 pages did not ... and that's a clue: they were the first 3 pages I added to the CMS when I migrated (cut-and-pasted) content from the original Net Objects Fusion version of this website into Wix. I didn't originally have a Title field in the CMS, so the URLs picked up the "title-here" Wix default, appended with an incrementing counter.

I soon noticed this and somehow (I can't recall exactly how) I figured out a way to change the URL for specifically the ISO/IEC 27002 page, resulting in a URL ending in "27002" ... but the earlier part of the URL was still not to my liking, as I had hoped to replicate the URLs from the NoF version - such as "https://www.ISO27001security.com/html/27002".

Evidently, I added the Title field to the CMS when migrating the detailed info for ISO/IEC 27004, and adjsuted the URL slug to include the Title field as shown above. Therefore, 27004 and later pages had the standards' names in their URLs. Unfortunately, though, the names included "ISO/IEC", so Wix discreetly encoded the embedded slash character, making the URLs work fine in browsers but look odd to the human eye.

Anyway, I checked the Wix help, searched the Wix community forum and Googled for a solution, and came up empty-handed. According to what I read, changing the URL slug was supposed to change the URLs for all the dynamic standards detail pages on the live website, which indeed it did for most ... but Wix stubbornly refused to update the first 3 pages.

Grrrrrr. Looks to me like a bug caused by the particular sequence in which I built the CMS, adding the Title field after publishing the first 3 pages.

In desperation, I decided to delete those first 3 pages from the CMS and recreate them - cutting and pasting the content as before. No big deal really, just an annoyance.

So far so good, the fix worked: now when I change the URL slug for the dynamic pages, all the detailed standards URLs are updated accordingly.

Spurred on by my success, I decided to address the issue of getting Wix to replicate the URLs for the standards pages from the NoF site. That turned out to be pretty straightforward: I added yet another field to the CMS to contain the number part of the standard's title e.g. "27001" for ISO/IEC 27001. Then I could use that CMS field in the URL slug, and Bob's yer uncle.

Even here lurked a little wrinkle in that multipart standards have a dash in their titles, and a dash is not a number, so the field had to be a text type, not numeric. Thinking forward, single-part standards are sometimes broken into multi-parters, so I decided to use the first part of the number in the URL for the first part of multi-part standards - so, for example, ISO/IEC 27036-1 would have the number "27036" not "27036-1" in its URL. That approach would hopefully avoid breaking the URLs in future ... although I'm still not sure how Wix handles redirections, a loose end to tie off another day.

Meanwhile, I have published the updated pages, so now anyone chasing hyperlinks from the old website pointing to the detailed pages about any ISO27k standard should - hopefully - arrive at the corresponding pages on the refreshed website.

And with that, I'm putting the plug in the plughole and carrying on with my day, some 4 hours older and wiser than when I started this morning's mission.

PS The old URLs ended with ".html", so now give 404 errors since I missed the suffix from the page names. Oh bugger. I've changed the 404 error page to advise visitors to delete the .html suffix and try again, or start over. Not an elegant fix, just a kludge, but it will have to do.