It was about frickin’ time -- Rob had finally landed himself a promotion. Technically, it was more an “absorption of responsibilities” than anything else, but the important thing was that his new role as “Global Editor” offered an excellent ROR (Return On Résumé). Really, how hard could it be to administer a handful of internal users writing a handful of blogs?

The previous Global Editor had left abruptly, and no one was really sure why. Some say he was fired, others say he just stopped coming in, and still others say he was committed. Fortunately for Rob, the previous editor left behind some extensive process documentation…

Accounts & Passwords
To keep things simple, all users share the same password (“pub887lish”) and password hint (their first name). Although I’ve asked them not to change their password/hint, the blog software does allow it, and they occasionally will.

In the event that they’ve changed their password/hint and forgotten it, the software does not allow administrators to reset the password. Instead, a new blog account must be created, all entries from the old blog must be copy/pasted into the new blog, and the old blog must be deleted.

UPDATE: I discovered that we can reset a lost password. To do this, log on with the administrator account, click “edit account”, and then change the URL in the address bar from editaccount.php?id=1 to editaccount.php?id=XX, where XX is their ID.

Publishing Articles
When a user is ready to publish his blog post, she simply goes to “set post status” and selects “published” from the drop down list. This does not actually publish the post. Instead, it sends an email to the editor notifying him via email that a new post has published (even though it hasn’t been).

Once this email has been received, the editor must log on with the administrator account and locate the blog post. The blog post must then be edited to remove most of the HTML. This is because the CSS on the live site is different from the CSS on the blog server, so everything will look different. If someone used a table, it’s best to take a screenshot of it and replace it with an <IMG>

After the post has been edited, go to the “set post status” page and select “unpublished”, click “save”, go back, then select “published”. Although this is the same thing that users do, when the administrator sets the blog post as published, it will actually be published.

Within an hour or so, the blog post will appear on the live site.

Sometimes blog posts do not appear after an hour. Something probably got “lost” along the way.

When the administrator sets the post status as “published”, the software rebuilds a static, HTML-based version of the user’s blog and saves it in the PUB-HTML directory on the blog server (BLSRV01).

Every fifteen minutes, a script will run that copies the entire contents of the PUB-HTML directory to the caching server (CSSRV2A). If the blog’s HTML files do not appear on CSSRV2A, this means that the job scheduler has probably been disabled. In this case, just restart the job scheduler.

If this does not solve the problem, then this means that the password on the account that the script runs under has expired. In this case, logon as that account (the name/password is in the script), change the password at logon, and then add the new password to the script.

Every half hour, an external server on Akamai’s network will download all of the HTML files from CSSRV2A and distribute them across Akamai’s network. Sometimes, for whatever reason, some files don’t make it too all the Akamai servers, so it’s a good idea to check each server individually after this copy occurs.

And God help Rob if the RSS feed stops working...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!