Nuke auto updates

[franz-josef-kaiser]

As Twitter did just go wild on that, we should consider adding one additional mu-plugin to the setup (or recommend installing it):

<?php
/**
 * Plugin Name: Updates Disabled
 * Description: Disable all automatic updates (for themes and plugins)
 * Plugin Author: wecodemore
 */

add_filter( 'automatic_updater_disabled', '__return_true' );

add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

add_filter( 'auto_update_core', '__return_false' );
add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_major_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_false' );

Not sure if we should throw in all options and add an explanation, or simply just close everything off.

[gmazzap]

Simply defining DISALLOW_FILE_MODS has the same effect. No need of any filter.

Filters are required only for fine grained control.

I don't think it worth to add that to wpstarter. Not in that form, at least.

Maybe we can add support for a new environment var that allows a more user friendly and centralized setup.

E.g. AUTO_UPDATES_STRATEGY or something like that.

[franz-josef-kaiser]

Let's just say it's not worth it

[franz-josef-kaiser]

Note to whoever reads this ticket in the future: There's this WP.SE question around DISALLOW_FILE_MODS and this years old Trac ticket that clearly explains the UI problems around that topic. Also looking at the code, the constant and the core structure would make adding a new constant pretty much useless. Maybe inspect filter vs. constants and the differences it makes … in case someone has too much time on their table.