Squarespace - Beware of the Broken Links

This web site (at the moment of writing) is hosted on Squarespace - really nice web commercial publishing platform that provides good editing and hosting experience. Other Lokad blogs are hosted there as well: Joannes, Christoph and Lokad News.

So far so good. Yet there are cases, when glitches get quite disappointing. We'll start with the advice, then dive into the problem and try to learn some lessons.

Dear Squarespace user: beware, that changing time zone setting or publish time might break your blog post links across the Journal. Customer Support will not be able to help here.

Let's talk about it.

One issue just popped up yesterday, when I've discovered that some of my journal posts were relocated, breaking the links. Their URL, that contains something like journal/2009/6/3/post-name was changed to journal/2009/6/4/post-name. Presumably this is related to the Locale change in the settings, customer support is unsure. Although this looks like a valid thought, since a few relocated articles that I'm aware of, have such a time, that could be affected by the time-zone change at some point.

This actually explains, why I was getting these "your article link on this URL is broken" from readers from time to time, blaming myself for the problems.

After communicating with support, I was suggested to go through the posts, finding and fixing the links manually. Given the amount of published materials, that's going to be a waste of time. However, it still will require less time, than migrating to the other blogging platform.

NB: Changing time zone back to the default setting, obviously, is not the solution, as it would break some of the posts published after the change.

Ok, that was a frustrating encounter, but let's try to learn some lessons from it. What could've been done to prevent this?

One way to handle this is to save post URL as string in the database, once the post is published. This way there will be no way to accidentally break some parts by changing some global settings. As I recall, WordPress used to employ this strategy (any other changes to the URLs are to be explicit). Alternatively we could put alert messages by all the relevant editing panels saying: "Warning, changing this setting might break links of some of your posts".

Actually, that's a similar strategy that is advised to apply, when you are keeping references to something in your solution (i.e.: blob names in Windows Azure, externally accessible url links, download urls). This way, changing naming strategy or merely refactoring ASP.NET MVC application would not accidentally break existing references in live system (unfortunately, ReSharper's Rename does not affect the Internet). Actual relocation turns into an explicit step, that is not coupled with the code: we move the referenced item and update the reference.

I'm in no position to criticize the attitude here, but customer support is something else I would've done differently here as well. Message "the problem could be ours, but you are to fix it yourself" is not the best one to be sent out. One of the reasons for it could be caused by the "black-box" behavior of the system being supported, where there is not enough information available for the support team. This uncertainty is another reason for employing CQRS architecture principles in solutions.

If there were an event log of all the changes in the past, usable by the customer support (in a time machine way, while filtering it from all billing and confidential events, by default), then there would've been no room for "maybe" and "could". Every event has cause and effect; and querying this log for all events related to post 416552 would've revealed the reasons why the URL was changed, ultimately allowing to understand and explain situation to the paying customer (and avoiding it in the future). Additionally such log could serve as an excellent way to discover other journal posts, affected by the same change, instead of leaving me with task of scanning the entire web site for broken links.

Needless to say, that in scalable systems (with high ratio of reads vs. writes) such log is perfect replication point that allows to distribute published information around the globe.