WordPress by default enables automatic updates. Why should anybody want to deactivate this? Doing updates manually sounds like a lot of work. Why do something manually, that WordPress can do for us automatically? Because in Ecommerce one cannot afford any surprises. Even if plugin authors do a hell of a job at testing their plugins before releasing a new minor or major version, running into any potential problem, can potentially result in a financial loss. And to avoid this worst-case scenario you should test any plugin or core updates in a development branch.
Deactivate automatic updates
If you have finished tutorial part 2, you already have a .env file in place. Go ahead and uncomment or add the following lines:
defined('AUTOMATIC_UPDATER_DISABLED') or define('AUTOMATIC_UPDATER_DISABLED', $_ENV['AUTOMATIC_UPDATER_DISABLED']);defined('WP_AUTO_UPDATE_CORE') or define('WP_AUTO_UPDATE_CORE', $_ENV['WP_AUTO_UPDATE_CORE']);defined('DISALLOW_FILE_MODS') or define('DISALLOW_FILE_MODS', $_ENV['DISALLOW_FILE_MODS']);defined('DISALLOW_FILE_EDIT') or define('DISALLOW_FILE_EDIT', $_ENV['DISALLOW_FILE_EDIT']);
You now have successfully disabled automatic updates. Read more about these constants in the WordPress documentation. By also disallowing file modifications, you make sure plugins can’t be installed or updated in the backend either. And that’s exactly what we wanted to achieve. Updates and upgrades should be managed in our Git repository.
Manual Update Workflow
An exemplary workflow to update dependencies (WordPress core and plugins) could look like this:
git checkout -b feature/test-branchcomposer update# now test everything still worksgit add –Agit commit –m "Updated dependencies. <list updated plugins here>"git checkout main # (or master)git merge feature/test-branch
Being able to test updated plugins is important. You don’t want to discover potential problems in your production environment.
Continue with part 17 of my tutorial series: WebP Support in WordPress and image conversion.