6 ms·

> You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and inst

by trog 6y ago

> You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server. Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?

yurishimo 6y ago
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.
- trog 6y ago
  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.
splatzone 6y ago
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.
- ellyagg 6y ago
  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?
  - trog 6y ago
    > 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.
  - ehnto 6y ago
    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.
daniellarusso 6y ago
Check out the roots.io project for some software development ‘best practices’ as applied to Wordpress for development and deployment.
- trog 6y ago
  Thanks! Looks super interesting.
ehnto 6y ago
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.

by trog 6y ago

yurishimo 6y ago

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.

trog 6y ago
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.

splatzone 6y ago

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.

ellyagg 6y ago
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?
- trog 6y ago
  > 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.
- ehnto 6y ago
  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.

daniellarusso 6y ago

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

trog 6y ago
Thanks! Looks super interesting.

ehnto 6y ago

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.