WordPress Lessons Learned – The Hard Way

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]

4 thoughts on “WordPress Lessons Learned – The Hard Way”

  1. The next post will discuss what we actually did to deploy the website, what are plans are for the next deployment, and what are plans are to get there. Oh yeah, and trying to deal with the inevitable spambots.

  2. First of all on security – depending on what your environment in capable of. I run my blogs (>1) on an OpenVMS system, using one (1) WP-codebase. Simply because I can.
    But in general, this applies to ANY:
    First of all: Install WP on a different location than your server’s docroot, and DO NOT name that location “WordPress”. This is the default and your blogs will be targeted on that location. Rename the directory and you limit the possibility of corruption (WP allows you to). It’s neither a good idea to map yout homepage on WP, for the same reason.
    1. Make your PHP environment READONLY. There is no need (except for _some_ content) to allow the webserver write acces. Same applies to any user. If someone needs to (system admin, for updates, for instance) het can easily switch write access on.
    The only exception might be uploads, but whoe needs them if you have other means?
    2. Get your database credentials out of the way. WP allows it one level up, but you’d better locate it elsewhere and change wp-config.php accoringly.
    3. If you allow users to register themselves (like you do now), be prepared to clean up the mess on a regular basis. I disabled new users on my blog for that reason. there were simply too many.
    4. Require login for commenting. Scan your comments before having them posted (use Askimet for a first screening – it’s free) and remove users that are notorious spammers.
    5. Use an external firewall that allows you to block addresses, subnets and domains before they enter your server.

    That WP requires MySQL has a reason in the past: it’s the ‘built-in’ database and it was the first that was embedded into the language; you could use any other of choice but you would need to rewrite virtually EVERY SQL-statement. You’ll encounter another problem here: there is no proper description of the database – I haven’t found it anyway.
    The advantage however is that your content is read in by PHP code and transferred into the database by that code.
    To copy content from one database to another has always been a problem. I’ve done that a number of times adn it always requires some form of dump or unload from one and a load into another. No difference here.

    1. Thank you for your insights, Willem. We’re very close to that. our current mess is #3 (registration). I just went through a mess of 40 fake users who registered over the weekend. Glad to have you aboard legitimately.

      There are some database tools for building diagrams. I’m going to look into that is see whether I can get you the description (no promises on when, but I’ll post my progress).

      Cheers!
      Randall

  3. As of the 3.8 (or nearly) version of WordPress, searching by spiders is disabled by default. So we got dumped from Google and Bing. The robots.txt file was not compatible, so that was a miss. We should be all good now, including our sitemap.xml. What wasn’t fun was the it takes moments to drop a website from Google, and weeks to get back. Weird.

Comments are closed.