Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm beginning to work on my first WordPress blog, however I've noticed most tutorials just have you do modifications (such as theme changes, installing plugins) on the production site. This worries me for a few reasons:

  • No backups
  • No version control
  • If you make a mistake, your production site is affected
  • Developing remotely is slower than local development, especially when tweaking css files.

I understand why WordPress works like this - it allows people with no development experience to manage their WordPress installation (or the one provided by their service provider). It also allows you to work on the WordPress installation without having ssh access to the server. However as I am confortable working with tools like git and ssh, and am using a virtual server for the blog, this isn't very important to me.

So I was wondering what techniques experienced developers use when working on a WordPress blog. For example:

  • Do you develop locally, then push the changes to the live site? How do you do this?
  • How do you manage database changes and backups?
  • What do you store under version control (if anything)?
  • If a plugin changes the database, do you somehow track the changes it does in version control, so you can rollback the changes done by the plugin if you need to?

Or maybe I'm just overcomplicating everything if working on the production site isn't as risky as I am thinking it would be. I would appreciate any answers either way.

share|improve this question

4 Answers 4

up vote 3 down vote accepted

I always develop locally (in my intranet), the way I publish in a new server is:

Let's assume you have a few pages and posts.

  1. Get the theme ready, all plugins used and a copy of the database (mysqldump);
  2. Create new database where the blog will be published (yourblog.com/blog), open your database file (mysqldump) and then replace the intranet address (blog.intranet/blog) with (yourblog.com/blog), and import this database using let's say phpmyadmin;
  3. Upload your local wordpress installation to your server, set the permissions for file upload.

Keep in mind that a few plugins may not work, so take a look if everything is ok, if not you will have to install/configure these plugins on the production blog.

Backups: I have a script that once a day backup the database, and another one that checks if a user uploaded a new file if so it downloads the new file from /wp-content/uploads/2011/07 (current month).

Version control: Except for wordpress itself, I keep almost everything under version control, theme, plugins and the database.

When a plugin changes the database:

  1. Install the plugin locally, for tests and/or tweaks;
  2. Backup database (yourblog.com/blog);
  3. Install the plugin.
share|improve this answer

You are right to respect a production site. In the ideal world you should also have a development and testing/staging environments where you can test your changes and updates. But since this is a blog site you might make some trade offs to save costs. At the very least it's a good idea to zip up the installation and backup the database before pushing changes so you can back it out in case of problems.

For the blog I don't use version control but do keep a local copies of the latest files that are backed up and also have it set to do automatic daily backups of the MySQL database that are rotated weekly.

share|improve this answer

Great question. WordPress makes it hard to implement the best programming practices you describe- I've wrestled with this myself.

You can work through the manual SQL dump procedures as Murilo describes, but if you're looking for a much easier way then check out the Automatic WordPress Backup plugin. It requires an Amazon S3 account (easy and cheap) but makes it trivial to do backups, ports, and pushes from your local dev machine to your prod server. In essence it's a backup and restore plugin, and it takes care of the database and files in one step.

This is how I work:

  1. I do all my work on a MAMP setup on my Mac, using git for my codebase.
  2. When I'm ready to publish, I backup the local version to S3 using the plugin.
  3. If it's a new site, I'll install a vanilla WordPress site on the prod server, and install the same plugin.
  4. I do a restore on the production site, pointing to the backup of the local version.
  5. For future updates, just repeat steps 2 and 4.

So far it's been foolproof. I've used this process for many sites without a single fail. And the plugin does an automatic backup before every restore, just in case.

share|improve this answer

I've been working with Wordpress for 5 years. My short answer to "What is the best way for an experienced developer to work on a Wordpress blog?" is to change the approach depending on the project.

If your dealing with your own sites I recommend taking them offline for a short period. Install the plugin straight to the live site and give it a checkup. Ensure there are no conflicts or unusual behavior. Obviously you do this with plugins that can be trusted. Local testing is only worth doing if everything is duplicated and that is time consuming.

I've known developers to download a clients entire website, files and data. Just to do a small amount of work. What is worse, they don't ask for permission to backup the entire site locally. Freelancers do this a lot the moment the customer gives FTP access. It's habit and some would say it is procedure.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.