WordPress Deployment: Here is What We Did

It was a dark and stormy night…

The adventure started by building a local copy of WordPress using basically MAMP (Mac, Apache, MySQL, and PHP) although I configured each on its own rather than using the MAMP product. No real differences there. DNS on a Mac is a bit of a gotcha because it sometimes does not like localhost vs. 127.0.0.1 if the server is not itself a DNS host, but that’s a different problem. The Apache instance had to be on a different port, so at least our URLs were very apparent. This turned out to be a good thing.

We then migrated whatever content we wanted from the old website. Forget Import. It doesn’t do what you’ll want. Probably never. At this point, some of the plug-ins worked, some didn’t. Anything with email was DOA because we are inside our firewall. No problem, we expected that.

So now the fun bits. There is no “deploy” button. FrontPage had one. DreamWeaver has one. Most things do. WordPress? Not so much. Sure, FTP worked to move the PHP code and ECLIPSE update sites. But there was more…

To move the content, we had to take a copy of the database. Oh, there’s nothing like TMF online dumps mind you; dump to text via mysqldump because WordPress requires MySQL. (Yes, that’s in red because of all the blood and pain). Our web host provider then used one of their magic scripts to go through the text image of the database and change all the URLs. Are you afraid yet? They then created our database using that script. This was early last Friday.

Once that was done, we had to check everything. PayPal had to be used once or errors  were displayed to the user. That’s gone now. The Contact plug-in had to be disabled and enabled. The Captcha plug-in had a security problem in its internal directory that we had to set/reset and now it’s happy too. Not bad but very manual.

48 hours later, the DNS caches all flushed and the new site is visible to one and all. We’re breathing a little easier. But only a little. When we make content changes, instead of pushing them up to the host, we have to make in-place changed and then take a backup – that or we lose comments and posts. I can force an on demand backup any time I want (there are plug-ins like BackWPup to do that) There’s still effective way to push wholesale changes from development to production. So what’s the plan?

Well, we’re talking to people. WordPress hasn’t quite figured out this discipline yet; that or they are letting the community handle it. They do not have an official position on deployment. Yet. I know a blogger who is getting comments out there. You might know him. There are plug-ins being built that are starting to take this stuff into account. They aren’t free, and if I’m going to pay for something, it better be rock solid – you know, like we expect in the NonStop community. Maybe it is an opportunity for one of us to do something about it.

 

 

One thought on “WordPress Deployment: Here is What We Did”

Comments are closed.