3

Recently i've noticed a lot of posts from users, complaining about their website running into problem after updating the WordPress to the latest version.

Let's say i have a website with a lot of custom functions and codes, which depends on the current core to run. The functions are too many to watch, maybe 30 or more, and WordPress is releasing update every once in a while.

So, how can i leave the auto update to ON and be sure that this feature won't break my Blog? I know i can make backups regularly, but this is not an actual salvation.

The path notes may be helpful, but still, on custom templates it's a pain to check it every time an update is release.

Now what are my choices? Do i have to turn the auto update OFF and backup / update manually? Or is there a way / plugin / etc. to prevent such things from happening?

  • 1
    You should be running a staging or development copy of your site, keeping plenty of backups or using version control to be the most prepared to handle problems. Watching logs and keeping dev/staging in debug mode will give you the best advanced warning of upcoming problems. If the theme and plugin code is following best practices, you will see deprecation warnings and PHP notices before anything breaks... usually. Watching WP core team posts is also a very good idea as there is plenty of public discussion available before releases. – jdm2112 Feb 17 '17 at 17:46
  • @jdm2112 Thanks. I already signed up for their newsletter. but sometimes i'm away from my blog for so like a week, and imagine what happens to my visitors, seo and reputation if the blog is broken while i'm away and i can't do anything about it in until next week. – Jack Johansson Feb 17 '17 at 17:54
  • Also i planned on backing up the website regularly, but it's a media website with more than 40GB of contents. Regular backups of this blog will demand huge disk spaces and resources. – Jack Johansson Feb 17 '17 at 17:55
  • @JackJohansson You could just skip regularly backing up the uploads folder :) Nothing is going to change in there in an update. Of course, you should have a less-frequently updated backup of it somewhere too. – Tim Malone Feb 17 '17 at 20:46
2

A website is just like any other software product, any change need to go through QA stage first, no matter how trivial it might seem. This is why you should always test all updates on a staging/dev server before pushing it to production.

As always it comes down to a question of ROI. Simple blogs can suffer down time for days while a fix is being work on, while sites that generate 1000$/hour probably less tolerant to hiccups, and the time invested in proper QA to avoid it is totally worth it.

So it is your judgment call in the end of how bad will it be for you if an update will break you site. If you value your time in lets say 40$/hr and the site generates 5$/hr, it is just not worth it for you to have a 3 hours QA cycle on the bi-monthly update release (not official but this is the real life rate), especially if you don't have any bad hacks in your code and it should in theory be "future prof"

2

I think you need the website installed in test and production environments. All of updating code (WP core or plugins) you run first at environment test. If works well, do the same in production environment.

That's it, when your business need grow, you need new strategies actions to grantee website updated!

2

Note: Before I go into the details, please note that, live server is not recommended to have fully automated background updates enabled. Only recommended auto update for the live server is the core minor updates. So even if you follow the procedure below, it's best to enable only the following in wp-config.php file for automatic minor updates of WordPress core:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

All other updates should be attended updates (not automated). Best (if possible) is to test the updates in the development or staging environment first and then apply it to the live server.

Since your question is not about turning auto update off, rather as you've put it:

How can I leave the auto update to ON and be sure that this feature won't break my Blog

Here is a concept on how you can accomplish that:

Step-1: Keep a staging server that will always auto update.

Step-2: On a update related action hook, for example, upgrader_process_complete action hook, check if it's on staging (identify by Server IP, installation location etc.) server. If it is, then check error log, cross reference with the live server etc. after the update process is complete. That is check multiple ways to determine if the update is breaking your site or not. If it's successful, then keep a note somewhere so that the live server can check it. It can be an API call to the live server, can be a file with the latest version number, DB entry - anything that'll determine that you have an updated version of core, plugin, theme etc. on the staging server.

Step-3: Mean while, auto update is not completely disabled on the live server, but filtered using hooks such as automatic_updater_disabled, auto_update_core, auto_update_plugin, auto_update_theme - i.e. whatever you need. And the filter function for these filter hooks must be able to check if the staging server succeeded in step-2. If succeeded, then allow the update to proceed through the return value (true | false as appropriate) of these filter functions.

Step-4 Additionally, in staging you can use the auto_core_update_send_email hook to let yourself know if an auto update process failed in the staging server.

Now obviously, all of the above steps will work together to accomplish the task. I just explained them in steps so that it's easy to understand. Also, to make sure staging server is running Cron, set a cron job at the staging server after 10 minutes or so. Otherwise, since people are not visiting the staging server, staging will never auto update.

Note: Live & staging server can have the exact same CODE, however, within the CODE you'll have to determine, on which server CODE is currently running - so that you can make different choices in step 2, 3 & 4 on staging & live server.

Read more on WordPress auto updates Here.

  • Mmmm nice idea! – Tim Malone Feb 17 '17 at 20:48
  • Thanks, I have 2 blogs, once with totally disabled updates ( i update manually ) and one without changing this option at all. and i'm receiving email every once in a while about my website being upgraded to the latest version of WordPress! And i have no idea how much the core has changed, and how many of my codes need to be rewrote... – Jack Johansson Feb 18 '17 at 8:39
  • minor WP CORE updates are basically security and bug fix updates, these shouldn't break your custom CODE at all, especially if you are following WP recommendations. For example, update from 4.7.1 to 4.7.2. Updates like 4.6 to 4.7 are not very likely to break your site as well, if you follow the recommendations, but you should be careful. However, you should really give specific attention on major version updates, like 3.x.x to 4.x.x. – Fayaz Feb 18 '17 at 9:39
1

Leverage your IDE (e.g. PhpStorm), run your webserver (e.g. Apache) and PHP locally so you have a test environment with a debugger hooked to the IDE -- let auto-updates happen there and do a full regression test.

Once you are convinced that your test suite is successful, sync to the production server. As a bonus, think about putting your site under VCS which is also nicely integrated with PhpStorm; this way you can revert any changes that break the site (if needed).

-1

You can do this within that tool -> https://wordpress.org/plugins/stops-core-theme-and-plugin-updates or editing wp-config.php file and changeing that line:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

If You would like to keep some important updates You should also edit that line:

define( 'WP_AUTO_UPDATE_CORE', true );

But remember - disabling updates in Your WordPress is a serious security breach and could cause more serious damage ! ! !

  • Thank you but my question wasn't about disabling the auto update, since i already mentioned that i know i can disable it. – Jack Johansson Feb 17 '17 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.