Turn off automated update status checking

new features should probably be patched against Drupal 7.x-dev and back ported from there to Drupal 6.x. Drupal 6.x is feature frozen.

Here is a port of durist's patch to D7.

Patch has some code style issues. Also, I'm not sure this patch makes sense. People will not 'guess' that this removes a dependency on drupal.org that might cause their admin page to hang a bit. It seems like we're fixing this problem the wrong way. We should probably do asynchronous checking only.

I'd really call this a bug rather than a feature which is why Dan is using a string that already exists in the update status module.

See http://www.tmsnetwork.org/blog/content/2008/08/22/drupal-6-slow-administ... for more evidence that this dependency on network connectivity to drupal.org can cause problems for site administration.

Attached are versions for 7x and 6x (the 6x is only different by being re-rolled from the root of the Drupal directory).

oops.

Note, all this chatter about "dependency on d.o for the admin screens" is compounded 1000 fold by #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc, which is at long last fixed and committed to HEAD and D6. I think once people upgrade to 6.11 (whenever that goes out), they'll see much less need for work-arounds and hacks like this. I'm tempted to just "won't fix", in fact, but I'll leave it open for a bit more comment before I do.

@durist: In 6.11, if d.o or your network is down, and you need to refresh your cache, fetching will still hang, yes. However:

A) in 6.10 and previous "you need to refresh your cache" was every time cron ran (regardless of your setting), and basically every page load in admin/* if you had a "minimum" cache lifetime set, used memcache, etc. In 6.11, you'll only try to re-fetch based on your setting, "check manually", or if you invalidate your cache by installing new modules, etc.

B) Please see #359171-4: Avoid cases where update data is refreshed on admin pageloads and ensure update notifications are always sent as configured and #209242: update.module reports bogus results when .info files are newer than the cached available update data. I don't know how to reconcile "asynchronous checking only" with "don't display stale results when the local data is invalid". I suppose we could massively break the string freeze and in the cases that trigger #209242 update status could just print some generic warning message like "Things have changed and I don't know what's going on until you [check for available updates] again." If that's the proposal, we should reopen #359171 and discuss this there.

@earnie: I don't care much about what you've done in the past -- I know it's been terribly broken until 6.11 with certain configurations. Tell us what you do with 6.11 and beyond and I'll be more interested in what you have to say. ;)

@earnie: I know. I'm saying that all these issues, lists, and forums are fueled by how broken update.module was up through 6.10. I'm not sure how to get people to give it another try in 6.11 -- the 6.11 release notes don't really indicate what a big deal the 6.11 release is for update.module... But, anyway, I don't think that experience is a good one to justify adding this feature to D7.

If sites don't want to regularly check for updates, and would "consider it a security risk not worth taking" ("privacy risk" would be much more accurate), they're not going to be any happier about only checking manually.

To summarize:
- The primary motivation for this feature is how broken a now-obsolete version of core was.
- The secondary motivation for this feature should be discussed at #359171: Avoid cases where update data is refreshed on admin pageloads and ensure update notifications are always sent as configured not here.
- Other motivations (e.g. "privacy") are orthogonal to this feature.
- The feature has the potential to make sites less secure by not alerting admins in a timely fashion if they're missing security updates.
- The feature has the potential to confuse end users.

Therefore, I'm going to call this "won't fix" after all...

@durist: I certainly have been working towards making Drupal viable for "enterprise environments". Among other things, I'm the one who pushed for, wrote, and maintain the Drupal release system, an absolute prerequisite for Drupal's expansion into this space. ;)

That said, if you don't want to check updates, you can disable update.module. That's how to turn off this feature.

I agree that checking for updates while d.o is down causing things to hang is a problem, but that's a discussion for separate issues:

#243253: Update status module can cause white screen if the check for updates takes too long
#359171: Avoid cases where update data is refreshed on admin pageloads and ensure update notifications are always sent as configured

We need to fix those, regardless. A "only check when I press the button" feature isn't an viable solution to the underlying problem, and is likely to be forgotten leading to sites that will be out of date and missing information about potential security updates...

drupal_UpdateStatus.patch queued for re-testing.

@sahilcool: Please don't re-open an old issue like this to retest a patch that's definitely not viable. If you read the comments here, it's obvious that we don't want this change as proposed. Requesting a re-test of the patch like this just drains resources of our automated testing infrastructure, and those of maintainers like myself who have to come in and clean up the issue again.

Thanks,
-Derek

drupal_UpdateStatus.patch queued for re-testing.

See above.

In drupal7 go to modules and disable update manager