I thought I had fixed the problem of blank archive pages, which I reported here on Wednesday, but I'm sorry to say the problem continued to recur throughout the day, long after I'd thought it fixed. I apologize if you were inconvenienced by the temporary absence of a large portion of the Loosely Coupled weblog archive throughout yesterday. The pages were restored this morning.
What I didn't realize on Wednesday after I had restored the original archive pages was that Blogger was still attempting to complete the 'republish archives' command from earlier on. So although I restored all the missing pages at 2:22am Pacific time, Blogger was soon back again wiping them clean. According to the timestamps on my directory listing, Blogger was busy republishing pages all day, not ceasing until more than twelve hours later, by which time it had erased the contents of practically every archive page. Evidently, eating my archives just the once was not enough for Blogger. Its insatiable hunger kept on driving it back for seconds until it had virtually scraped the blog clean.
Naturally, this has thoroughly shaken my faith in Blogger's archive republishing function. Although I'll report the problem, I can't see myself using the function on my live pages again the risks are too great. In the short term, I can use my workaround. Later on, I'll substitute an alternative that I can trust.
Visitors trying to access archive pages for the Loosely Coupled weblog last night were mostly greeted by a blank screen after Blogger deleted their contents during a routine republishing exercise. The purpose of the exercise was to amend the copyright notice at the footer of each page, redating it for the new year and at the same time updating the company name. That meant amending the page template stored in the Blogger system and then using the "republish all" function to recreate each weekly archive page using the updated template.
But instead of replacing the old version of each page with the updated contents, Blogger's publishing process only got halfway through the task, with disastrous consequences. It successfully opened the old file and deleted the contents, but never got around to writing the new contents, leaving the files as empty shells. So any visitor clicking on a URL for one of those pages saw just an empty, white space in their browser.
Having seen that this was happening, I naturally attempted to rerun the publishing process to correct it. But with each fresh attempt, Blogger wiped out a further batch of archive pages. My blog was being eaten alive before my very eyes, and there seemed to be nothing I could do about it.
Although this is the first time I've experienced this problem when republishing archive pages, it has come up before when posting new entries using Blogger. Since several months have passed since then and it still hasn't been fixed, which tells me that it's not a universal problem with all Blogger users, and therefore it must be specific to the way Blogger interacts with my hosted server. I decided to put that theory to the test, by attempting to republish the archives to an alternative server hosted with a different provider. All I had to do was go into Blogger's setup console and change the server IP address, the server path for the blog and archive files, and the server username and password. Then I republished again, and it worked first time. After copying the resulting files back to my main server, I've restored the missing pages.
While doing so, I noticed that the FTP process is much faster on my alternative server, hosted at Hostcentric, than at my main server, hosted at Jumpline. This pretty much confirms my suspicion that the publishing glitch is caused by a timing problem between Blogger's publishing engine and Jumpline's FTP program. But of course that in turn means that the chances of getting it fixed any time soon may be quite slim. With a claimed 30,000 domains hosted, Jumpline hardly represents a big slice of Blogger's customers, and vice-versa. So neither support team has a big incentive for getting in touch with the other and resolving this issue. On balance, I imagine that Blogger has the greater incentive, since Jumpline is likely to be using the same tools as other hosting providers, and so fixing the problem here may also help resolve it in other instances. I'll report it to both helpdesks, anyway. But there are a couple of other options I should be considering as well.
Moving to a new hosting provider is one possibility. I'm reluctant to do so after all the effort I've spent educating Jumpline about DNS hosting a topic that Jumpline at least is more understanding of than Hostcentric. But I should at least research alternatives, as it's always a good idea to have a fallback waiting in the wings.
The second possibility is to decouple Blogger's weblog publishing functionality from the final page publishing process. I'll need to think through how this could be done in a way that doesn't mess up the URLs and permalinks, but in principle it should be possible to set up Blogger to publish the raw weblog content to a set of staging files, and then have a separate process that reads the content from those staging files and writes out the published pages. Decoupling Blogger from the final publishing act would mean I could make changes to the page 'skins' without having to use Blogger to republish the results, and would also allow me to add features that Blogger doesn't support (for example, varying the skins according to the archive date, or adding a page-specific contents index at the top of each page).
I seem to be moving more and more towards using Blogger purely for editing and ordering my blog entries, while using a dedicated publishing system to do everything else (such as generating RSS feeds, contents pages, a commenting system and now the blog pages themselves). I may reach a point where I discover that there's a better platform than Blogger for this type of approach. In the meantime, grappling with these problems and fixes is helping me to figure out more and more about what it really means to be loosely coupled.