Strategies To Future Proof WordPress

Future Proof WordPress

You’ve gotta be prepared for the future, just in case you end up there.

For those of you who have read this blog long enough, you know that I’m a big advocate for using WordPress for web application development.

No, I don’t think it’s the end all, be all of foundations for web applications, but it’s one that shouldn’t be overlooked depending on the nature of your requirements.

Anyway, a friend of mine recently contacted me asking what I do to future proof WordPress when I begin to use it build applications on top of it. Specifically, he asked what steps I take when working on projects that may end up breaking with the next WordPress upgrade.

Since I don’t recall ever sharing the steps and tools that I use, thought it would be good to cover here.

Note that these aren’t all the things that I do or that can be done (and I’m sure you guys have some great suggestions, too), but these are the things that came to mind that I’ve found to be absolutely critical.

Future Proof WordPress

First, you’ve got to make sure that you’ve got environments for both Development and Staging. Remember that Staging should mimic a Production environment as much as possible; however, it’s where you’re fine to break stuff (or delete stuff or whatever other fun things :).

Development

As far as the Development Environment is concerned, there are a handful of plugins that I absolutely recommend having installed:

Secondly, depending on the nature of your project (as in how long it will take you build it), it may be worth working with a copy of the latest copy of WordPress from the public trunk.

Make sure that you also have error logging and notices setup for PHP in your local environment, as well.

This will ensure that you’re not only running error logs, debugging, and catching notices as your work begins to use deprecated functions, or triggers notices that should be caught and/or resolved given the version of WordPress on which its installed.

Staging

Again, Staging should mimic Production – this includes whatever themes, plugins, and tooling you have setup on Production (but not necessarily Development, though having a logging mechanism is never a bad idea).

It should also be running the version of WordPress that you’re going to be running in Production (which would also likely be the most recent tagged version available at WordPress.org.).

Remember: The primary purpose of Staging is to deploy the work you have in Development as if it was going to be running in Production with the ability to muck up the database and associated files without having to worry about bringing down Production.

Production

This is the simplest environment of all:

  • WordPress
  • Your application
  • Any logging mechanisms necessary
  • …and that’s it

Of course, you could have a few more tools setup beyond what’s here, but Production should be largely off limits for development or tweaks. It’s up only for deployments.

Finally, I’d be remissed if I didn’t mention that it is possible to disable notifications and/or automatic upgrades to that you can manage that.

I know that disabling automatic upgrades is a bit of a no-no in the WordPress development community; however, if you’re the person that’s going to be managing the site moving forward and are technically savvy enough to take care of the details as they roll out, then I think it’s an example of an acceptable exception.

There is More

As I mentioned at the beginning of the article, there is certainly more that can be done, but when others ask me what are the basics that I recommend, this is what I offer.

That said, I’m interested in what you have to share, as well so if there’s more to add to this list, then please do!

8 Comments

I totally agree about updates. Ideally, they should never break a site. But the WordPress ecosystem is far too unstable for that, and I’ve rarely had a client that wasn’t using at least one plugin that made me nervous. Leave them for me, I say!

Also, whenever possible I use git at every stage of the process, including production. It just feels so much better knowing that if something goes wrong I can immediately roll back to any other version I want. Git won’t catch the database, so it’s not a backup solution by any means. But there is peace of mind that comes from knowing most human-error screw-ups can be rolled back quickly. And the commit log is a great tool for tracking down problems that emerge on the production site that you can’t replicate in the other stages.

I’m sure SVN would work just as well. I don’t have much experience with it, though.

    I’ve rarely had a client that wasn’t using at least one plugin that made me nervous. Leave them for me, I say!

    This brings up an idea that I’ve chatted about with a few other developers around vetting certain plugins to know if they’re compatible with the latest version of WordPress.

    Sure, there are tags for this in the repository, and there is information that should help us filter it out, but users may not read the notes, may automatically click update, or may not pay attention to some of the changes in the plugin and ultimately negatively impact their site.

    All that to say, agreed. I think that if you have the time and they have the budget, leave that to people managing the site.

    Also, whenever possible I use git at every stage of the process, including production. It just feels so much better knowing that if something goes wrong I can immediately roll back to any other version I want. Git won’t catch the database, so it’s not a backup solution by any means. But there is peace of mind that comes from knowing most human-error screw-ups can be rolled back quickly.

    Exactly. Tag every staged release, IMHO.

I’d also like to submit Debug Bar and Debug Bar Extender to the list of must use plugins. Incredibly helpful. Will show you what query string was used to get this page, shows you how long each query took to execute, amongst other things!

Trackbacks and Pingbacks

[…] Strategies To Future Proof WordPress […]

[…] Strategies To Future Proof WordPress […]

[…] methods to future proof WordPress – an enchanting speak on future proof WordPress with assistance from Tom McFarlin […]

[…] Strategies to future proof WordPress – an interesting discussion on how to future proof WordPress by Tom McFarlin […]

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>