Check out the roots.io project for some software development ‘best practices’ as applied to Wordpress for development and deployment.

Thanks! Looks super interesting.

Disable automatic updates on production. You don't want automatic updates on a production site anyway, they could bring your site down without you knowing. Instead, install updates and plugins locally, test locally, then push to live. That's really true for any code versioned software.

The most common approach is to store everything but the wp-content folder in git, including plugins. A way to save space there is by using composer so your Repo only needs to include custom plugins that your team wrote.

It can be a hassle on shared hosts, but most managed hosts have a git workflow that their agency partners utilize so it’s not too bad if you’re doing anything on a professional level.

The problem is the only thing I really care about is the stuff in wp-content! I've inherited a few sites with custom themes and it's the changes in plugins that I'm most interested in so I can track issues. Almost anything else that comes from latest.zip I am not concerned with.

I just haven't found a good workflow I guess. I'm gradually trying to strip all the plugins which are not required (there are so many) so I can just focus on the core ones that are hard requirements but even one or two decent -sized plugins is a huge responsibility to manage if you're trying to pretend you're tracking all the changes to any level of detail.

I keep things really simple to be honest, normally I exclude wp-content/uploads and wp-config.php in .gitignore. And set the perms so WP can't write to the filesystem on production, except for the uploads directory. We install and test updates on a dev environment first then commit everything and pull it in on production.

If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?

> If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?

The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.

I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.

Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.

If your using a versioned codebase you likely don't want that anyway. Otherwise you'll have untested code on production, and you'll have to commit it to the project repository from production.

Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.

It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.