Running an update check on all the installed modules on my site takes quite some time, and sometimes even exceeds PHP's runtime limits. Leaving the module enabled makes using the web based administration very difficult, as many different actions cause it to make a full run.

Is there a way to leave the module enabled, but only have full updates triggered by cron instead of every time the status or module pages are visited in admin?

I'm using Drupal 6.26.

3 Answers 3


As far as I can tell there's nothing about visiting the modules admin page (or any other admin page) that would invoke a check for update data.

Drupal 6

For Drupal 6 the work is done by _update_refresh(), which is inadvertently called from several places within the update module itself. Those of note include:

Since none of those are called for every admin page, and Drupal 6 doesn't have auto-cron (you also mentioned in the comments you don't have poormanscron installed), it doesn't seem like any of the core functions will be the culprit.

There's no way to unset hook implementations for specific modules in Drupal 6 (there is in Drupal 7, see below) so short of editing the module file directly I don't think there's anything you can do about that.

Drupal 7

The work is done by update_get_available(), and that function is only called from 4 places by core:

If the update is happening on any other pages than those listed above it's either caused by a contrib/custom module, or (more likely) because you have auto-cron on, and the cron run is being invoked. There might be more to it than that but I can't find anything looking through the core code.

As far as the status page goes, you could remove the update module's implementation of hook_requirements() from the cached list of hook implementations, effectively stopping the check from happening when you go to that page. It means you won't ever get that particular line in the status report, but if you're ok checking for updates manually then this won't be a problem.

The way to do this is to implement hook_module_implements_alter() in a custom module:

function MYMODULE_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'requirements') {

Either version

You can slow the frequency of update-checks down a bit by setting the update_check_frequency variable to something longer than standard. The variable contains the number of days that need to pass before the update data is checked again.

  • I don't see that function getting called in any of the custom modules and I do see it in the four places you mention. Your mention of auto-cron sounds promising, where would I find that? I do not have poormanscron installed and judging from the status page cron doesn't seem to happen unless I have the drush job activated in my system crontab.
    – Caleb
    Commented Sep 8, 2012 at 14:26
  • 1
    D7 has poormanscron built in and if I remember rightly it's on by default...you can turn it off at admin/config/system/cron by setting "Run cron ever" to "Never"
    – Clive
    Commented Sep 8, 2012 at 14:28
  • Ah you're using Drupal 6...give me a few minutes :)
    – Clive
    Commented Sep 8, 2012 at 14:28
  • Yeah there's no auto-cron in D6 core so it's not that. I can't think of any reason the update checks would be running when they're not supposed to, could it be anything else that's slowing down the modules page? I'm afraid there's not a lot you can do without editing core files for the status page, you can't unset a hook implementation in Drupal 6.
    – Clive
    Commented Sep 8, 2012 at 14:37
  • Without update enabled, I can hit up all the admin pages just fine. The second I enable it, they all start hitting a 30 second php execution timeout about 90% of the time. Update checking is clearly the culprit, I can't make out what it thinks it's doing or why anything in it gets triggered on every admin page.
    – Caleb
    Commented Sep 8, 2012 at 14:46

In regard to the Update module, my solution is to never use it on a live website, only in Staging or Devel, but not with the final website.

Also Elysia Cron lets you to choose when you want to run all the hook_crons. I think this is is a "must have" module in all drupal projects.

  • Thanks for the tip on Elysia Cron. I think I have another problem besides cron going on on this site, but esp with drush support that looks like a useful thing to keep in pocket.
    – Caleb
    Commented Sep 8, 2012 at 15:03
  • Cron management is pretty indispensable for any Drupal site, though Elysia Cron not the only module that does this. There's also Ultimate Cron: drupal.org/project/ultimate_cron (which already has a dev version for Drupal 8.)
    – forest
    Commented Sep 8, 2012 at 16:31

Yes. Of course. I don't think it is built-in, so you actually have a pretty cool idea for an easy but useful custom module. I actually made something very close to this not too long ago.

You create a module say updateManager, and in your module file add elysia cron as dependency,

One of the goals of the module could be to have your module add an text field on the update configuration page to easily set the date and time you want update.php to run.

This field supports crontab syntax 0 * * * * syntax,

  • Thanks to elysia cron api, it is easy to set, store and retrieve and play with cron task in your code. If you want you could even just create a cron task here that overides the main cron task and would be listed in elysia cron task panel.

    • In your custom module you can easily add the field to the 'update configuration form' with a form_alter on the form.

    • Another option is to turn off updates, and do it with a cron task that runs update via drush.

  • Drush will also refuse to run the update checker if the module is disabled.
    – Caleb
    Commented Sep 8, 2012 at 15:18
  • Ho! The bummer! :o) one then need's to add a drush call to enable updates, then call update script, then .. drush call to disable updates. I'm surprised drush module update task works like that I'll have to try it out. Commented Sep 8, 2012 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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