Per a question asked on the Advanced WP group on Facebook, wanted to put my answer here for reference by the rest of the Roots community if needed.
Chris’ question basically boiled down to “How do I allow for admin users on the production site to manage their updates when using Bedrock?”
Out of the box with Bedrock, the ability to update your plugins and core WordPress files is not allowed. This is 100% intentional because in a true development environment every plugin or core update should be thoroughly tested before being released into the wild. We definitely agree with that strategy… BUT…
WordPress can be a different beast, and with SOO many updates, and with SOOOO many users used to being able to add and remove plugins willy nilly, forcing all of those to go through a developer just doesn’t seem realistic.
So when we rebuilt our new site at neonbrand.com using bedrock we decided to disable this feature. It’s basically just one line of code in the environment files.
In the bedrock framework, go to config/environments/production.php, comment out line 7:
/** Production */
/** Disable all file modifications including updates and update notifications */
// define('DISALLOW_FILE_MODS', true); <----COMMENT THIS LINE
That will allow you to manage updates via the WordPress Updater.
We do rely heavily on the mu-plugins folder to keep special plugins out of the reach of the updater.
Because we’re now not relying on composer to manage the plugins, we rely on rsync to bring down the plugins and uploads folders back to our local or staging environment. We also use ssh alias’ to make it even easier…
From within the app directory on our local file structure we enter the following commands:
rsync -avz sitealias.com:neonbrand.com/site/web/app/plugins ./
rsync -avz sitealias.com:neonbrand.com/site/web/app/uploads ./
Can also be done on the production site to sync back up any changes as well.
The last issue is keeping the database synced between environments. Through building our site we learned that for next time we’ll be maintaining two databases (instead of 3+). A local/staging database and a production database.
The local/staging database will be on the staging server and local will connect remotely to that, so that we don’t have to maintain a third db.
Then obviously the production db.
Then using navicat or mysqlpro we do a full sql dump of the production database to the desktop.
Open up the staging database and delete all the tables in the database (of course we have regular backups) and then using the exported production database sql file we rebuild the staging database.
We try not to make any edits to the staging/local database that will ever need to be pushed back up to live. We can test settings and plugins locally, but we know those settings will need to be redone when we go live with whatever it is we’re working on.
Hope this helps, Chris! If anyone has any suggested improvements to what we’re doing, let us know as well. We think trellis may help with some of this but haven’t fully dove into that solution yet…