Allowing Updates on Production Site

bedrock
, ,
1

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:

<?php
/** Production */
ini_set('display_errors', 0);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);
/** 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… :grin:

4 Likes
2

Concerning the automated updates, I also think about turning them back on in production.
However, I would still use composer and run composer update on dev/staging and test there, too. This allows me to roll back to known well working versions of core + plugin versions/sources even if the site suddenly breaks on production (the downside of automated updates).

2 Likes
3

Good point on using composer update to give you working rollbacks… we haven’t found the need, but I can see the purpose.

Also good call on the image strings, but I will say that if the production database is the one being copied down to staging/local (and as long as you’re on a working internet connection) the images will pull from the production environment and still display correctly in your local/staging environments.

So yes, while updating the media URLs in the database is definitely something to consider, we haven’t found the need to constantly search and replace all the references as it doesn’t affect what we see on the local/staging site.

4

I might add that if you are allowing themes/plugins/updates to be managed via WP Admin by commenting out define('DISALLOW_FILE_MODS', true);, you may want to consider moving themes and plugins to the ‘shared/’ directory in order to prevent them from being overwritten the next time you run a Trellis deploy… See: Does bedrock/trellis disable the ability to add/install plugins via admin? for instructions.

1 Like
5

Follow up to my last post, I have become much wiser in my bedrock usage and no longer use this option. At that time I didn’t understand the power of using composer to install my plugins. Now, it’s all I do and now I love the fact that the updates are hidden to my end users.

I also wish bedrock would include in the default config hiding the “nag” notifications as well by using something like this for WordPress Updates:

add_action('after_setup_theme','remove_core_updates');
function remove_core_updates() {
    if(! current_user_can('update_core')){
        return;
    }
    add_action('init', create_function('$a',"remove_action( 'init', 'wp_version_check' );"),2);
    add_filter('pre_option_update_core','__return_null');
    add_filter('pre_site_transient_update_core','__return_null');
}

and this for WordPress Plugin Nags:

remove_action('load-update-core.php','wp_update_plugins');
add_filter('pre_site_transient_update_plugins','__return_null');

(code from this link)

But you’ve come up with an interesting alternative to my first solution, for sure.

4 Likes