Automatic updates should not be silently disabled if I have .hg in file system root

[jgehrcke]

My WordPress does not apply updates automatically, although it is told to via define('WP_AUTO_UPDATE_CORE', 'minor');. WordPress did not send any mail with an error report, so I had no idea how to debug that issue. I then found ​http://wordpress.org/plugins/background-update-tester/ which told me that all conditions pass except for

FAIL: The folder / was detected as being under version control (.hg).

What? Yes, indeed, I am managing system configuration files via Mercurial. The repo is placed in the root of my file system. This is *completely* unrelated to my WordPress installation.

I see the rational (​http://make.wordpress.org/core/2013/09/24/automatic-core-updates/):

If the install is running as a SVN or GIT checkout, automatic updates are disabled

But the way it is currently detected is in my opinion strongly over-generalized:

It looks for .svn, .git, .hg, and .bzr folders in ABSPATH, and every directory above that up to /

It is fine if WordPress makes assumptions about its own eco system. However, the current implementation assumes that any DVCS placed in any directory when going up the file system hierarchy up to the root is controlling WordPress. What is this assumption based on? That WordPress should be the only thing running on a Linux box? :-) Seriously, this is not a good way to detect if the current "install is running as a SVN or GIT checkout".

I think everybody agrees that I should not be forced to get rid of my system configuration repository in order to make automatic updates work again. I think WordPress should change this behavior.

What are other good ways of determining "if the install is running as a SVN or GIT checkout"? One could also question the rational behind this: If it is a SVN/GIT/... checkout then *most likely* it is a development version and the developer *most likely* does not want automatic updates to be enabled? Too many assumptions in this for my taste, even if we could reliably determine whether the current WP installation is a DVCS checkout.

Could that whole thing be done more explicitly?

What would be a quick workaround for me, if I really want to have automatic updates without getting rid of /.hg?

[nacin]

Hi jgehrcke, thanks for the ticket.

When we did auto updates, we wanted to be super careful about stepping on toes. We turned on automatic updates by default for everyone and that was pretty scary for a lot of folks. To rationalize this, we coded it up for it to be as safe as possible, and that included assuming that if you were using any form of version control, then you knew better than us. It's possible that you have a website repository one, two, or more levels higher than WordPress core (which could easily be a subversion external or git submodule in this case).

Here, you trust the feature and don't want it to be so skittish about deciding whether to update your install. This is one of the best bug reports for a developer to receive. The automatic updater class is flattered.

There was a follow-up blog post on the same blog: ​http://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/. There, it explains the rationale with a bit more depth. And it also describes a simple filter you can use as a permanent workaround.

I think one thing we could do here is let WP_AUTO_UPDATE_CORE = 'minor' explicitly override certain things, since that's the default and it would only be specified if someone really wanted it.

[jgehrcke]

Thanks for providing some background info to an ignorant user :-). Okay, so I have added the following code to my theme's functions.php:

--- a/functions.php	Mon Mar 24 17:59:47 2014 +0100
+++ b/functions.php	Tue Apr 15 14:19:08 2014 +0200
@@ -1,4 +1,12 @@
 <?php
+// Enable automatic update even if .hg or other VCS is detected.
+// http://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/
+function update_anyway($checkout, $context) {
+    return false;
+}
+add_filter('automatic_updates_is_vcs_checkout', 'update_anyway', 10, 2);

Correspondingly, the update check plugin now states:

INFO: The folder / was detected as being under version control (.hg), but the automatic_updates_is_vcs_checkout filter is allowing updates.

Is there a way to trigger the automatic update, or do I have to wait for WP cron to perform it?

You wrote

[...] since that's the default and it would only be specified if someone really wanted it.

Should that have been "since that's not the default"? In that case, I agree that setting WP_AUTO_UPDATE_CORE to 'minor' should either perform the backup or be verbose about the update progress/errors. Silent deactivation is not good.

Thanks for consideration!

[SergeyBiryukov]

Replying to jgehrcke:

[...] since that's the default and it would only be specified if someone really wanted it.

Should that have been "since that's not the default"?

Well, the constant is not set by default, but updating to minor versions only is the default for the logic in Core_Upgrader::should_update_to_version()​.

[johnbillion]

One thing we could do is display more information on the Updates screen when automatic updates are disabled. This wasn't done in 3.7 when the auto updater was introduced because the feature is intended to be as silent as possible.

In this case, though, it would definitely save some head scratching if a message was added to this screen which states automatic updates have been disabled when a VCS is detected (and a link to more information).

[chriscct7]

@johnbillion did you want to write a patch for comment:4?