Deep Breath…

It’s difficult for me, used to a high level of operations management discipline, to look back on our website deployment with anything but shame. Here’s the story of our somewhat moderate accidental success, or horrible failure – depending on your point of view.

Last fall, our web host provider informed us that support for FrontPage extensions, which we used on the previous incarnation of the website, was being dropped. Great! I finally had the motivation to get rid of the cobwebs and move to something modern. We’ve all been there. This started a long internal discussion of what to use for the new improved nexbridge.com. Our hosting provider suggested WordPress.

Moving the content was interesting, and difficult. Import did not work, so we had to move each page. The WordPress editor is not 100% consistent with HTML so that didn’t work out with simple copy&paste functions. But that’s just a side note. We’re currently fixing some of the paste issues that accidentally copied image links from the older site. Paste only text. Do not assume images are preserved.

But the work we did was all on a local server, to try things out. How to get the content up to the hosted environment? That was the question. The website has many moving parts:

• Our ECLIPSE update site,
• the PHP code for WordPress, its plug-ins, our customizations,
• and the website content, which hides inside a MySQL database – and it has to be MySQL. That’s a WordPress requirement.

The ECLIPSE update site and our customizations are no problem. We’re good at that. Standard staging, install, fallback using Git. No worries.

The WordPress code has internal pointers to the root DNS of the website, so those have be changed when you deploy or you can use redirection code, which still needs to be modified. Queue fear here.

Some of the plug-ins have caches and internal pointers that depend on the DNS site root also. Those had to be reset after we deployed. I was not happy about that.

An important lesson we learned was the security inside the PHP code area is crucial, and generally wrong. There are caches, you see. The security and users on the target system are usually different from your build machine. Enter annoyance.

And probably the worst part: The way to deploy website content is through SQL scripts. You basically dump the database to text, upload it, change a bunch of stuff in the scripts, and apply it to the target database, and every table is blown away and recreated. Ok, I can accept that once. But what about our next set of changes?

In any event, we’re still working on it and are not live yet. We’ve made some of the site available for now. More to come on how we solved it…. [followup-post]