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 :).
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.
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.
This is the simplest environment of all:
- 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!