Remaining tasks

User interface changes

API changes

I have a Drupal 7.7 installation that sends no notifications when updates are available to modules or Drupal core, despite the fact that:

Cron is running correctly every hour.

The site successfully sends emails for other purposes, so drupal_mail is fine.

Update notifications appear in the administration pages when updates are available.

The settings in 'Available updates' include:

Check for updates daily

Check for updates of disabled modules and themes

Correct working email addresses are given for notifications

Email notification threshold is 'All newer versions'

The expected behaviour from the above configuration is that the listed email addresses receive notifications when new updates are available. The actual behaviour is that no notifications are sent. There are similar reports at http://drupal.org/node/1039812

FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1263040-no-notifications-sent-when-updates-are-available-40-D7_x_0.patch. Unable to apply patch. See the log in the details link for more information.

FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1263040-no-notifications-sent-when-updates-are-available-40-D7_x.patch. Unable to apply patch. See the log in the details link for more information.

I'm experiencing this issue too on all my D7 sites so I've made a quick research.

This is a hook_cron of update module:

<?phpfunction update_cron() {$frequency = variable_get('update_check_frequency', 1);$interval = 60 * 60 * 24 * $frequency; if ((REQUEST_TIME - variable_get('update_last_check', 0)) > $interval) {// If the configured update interval has elapsed, we want to invalidate // the cached data for all projects, attempt to re-fetch, and trigger any // configured notifications about the new status.update_refresh();_update_cron_notify(); } else {// Otherwise, see if any individual projects are now stale or still // missing data, and if so, try to fetch the data.update_get_available(TRUE); }

// Clear garbage from disk.update_clear_update_disk_cache();}?>

The first check for updates always goes through the first branch, as update_last_check variable is non-existent.

But update_refresh() only enqueues the fetching task and _update_cron_notify only analyzes the cached results. So look like the fetching procedure isn't called at all. I tried adding a call to update_fetch_data in between and I immediately received an email notification.

On subsequent cron runs data seem to be fetched, at least _update_process_fetch_task is called. But what puzzles me is how the email notification is supposed to be sent. If cron runs more often than update_check_frequency, we never get to the first branch. But it's the only place in the module, where _update_cron_notify is called.

Hope someone, who better understands how all this is supposed to work, will give some hints.

@akamaus: Given your pointer that update_fetch_data() is what is needed to actually call the fetching procedure, it looks like the patch in this issue: #647964: Running cron does not check for available updates might fix this bug too? The patch does exactly what you suggest: adds update_fetch_data() between update_refresh(); and _update_cron_notify();.

I don't know if it helps, but after update Drupal to 7.7 version from earlier versions the variable update_notify_emails corrupts in certain (not clear) situations.
Please see http://drupal.org/node/1284364#comment-5194882, and also compare some other issues on this variable.

This doesn't seem to be the problem in my case. Installing the Variable Check module gives a report with "No invalid variables found", and update_notify_emails looks fine to me in the variable database table.

I'm now using Drupal 7.9, and still get no update notifications at all.

[update_contrib] => Array ( [title] => Module and theme update status [reason] => 4 [description] => There are updates available for one or more of your modules or themes. To ensure the proper functioning of your site, you should update as soon as possible. See the <a href="/admin/reports/updates">available updates</a> page for more information. [severity] => 1 [value] => <a href="/admin/reports/updates">Out of date</a> )

The cron works every other time, in update_get_projects()
$projects = &drupal_static(__FUNCTION__, array());
is empty and gets rebuilt one time, the next it has data, but none of these entries contain a status???

I give up...............works every other cron if I comment out both" if (empty($projects)) {" in update_get_projects() in update.compare.inc with my update_cron modified to run everytime for testing....

After so much time still broken for me. Updates are checked now, but not emails are sent.
I looked a bit more into the code, update_cron logic looks broken to me.

Let's look at it again:

<?phpfunction update_cron() {$frequency = variable_get('update_check_frequency', 1);$interval = 60 * 60 * 24 * $frequency; if ((REQUEST_TIME - variable_get('update_last_check', 0)) > $interval) {// If the configured update interval has elapsed, we want to invalidate // the cached data for all projects, attempt to re-fetch, and trigger any // configured notifications about the new status.update_refresh();update_fetch_data();_update_cron_notify(); } else {// Otherwise, see if any individual projects are now stale or still // missing data, and if so, try to fetch the data.update_get_available(TRUE); }

// Clear garbage from disk.update_clear_update_disk_cache();}?>

If cron wasn't run for long time, the first branch is active, updates are checked and the mail sent. You can test it by setting update_last_check for a value in past. BUT if your cron job runs more often, than update_check_frequency days, then this will be the sole and last mail you get.

Indeed, next cron runs else branch is activated, update_get_available function is called, which in turn calls update_create_fetch_task which sets update_last_check to now. This loop will continue forever as long as cron is alive. No messages would be sent.

I propose to untie email notifications sending and checking updates. For example, I'd like to check for updates every day and receive a mail as soon as security update is fetched, but after that I'd like get reminders once a week, not more often.

Well update is already using variables for this, so probably doesn't make sense to do that here. The patch will need to be re-rolled against 8.x per http://drupal.org/node/767608 though, although it's likely to just be the path change in this case, so tagging as novice for the port.

I fixed the paths so patch applies on D8 now. I couldn't run D8 on my environment and test it, but I studied diffs of update module between 7.x and 8.x and found no cardinal changes. So patch should work as is.

@catch, Yes, I tested it on D7, but since I'm the author of patch #23, I don't feel it's appropriate for me to mark it RTBC.

I maintain a couple of dozens of D7 sites and I'm bothered by the fact I receive no notifications about critical updates, looks like a security related issue to me on it's own... Surprisingly, it received almost no attention for about a year.

Git reports that the patch is applied cleanly and I verify that the 3 files are adapted as intended.

Back to /admin/config/system/cron and press button “run cron”
The result is:
Fatal error: Call to undefined function _update_cron_notify() in C:\Users\luk\Desktop\D8\drupal\core\modules\update\update.module on line 307

Yes, this solved the problem. I added an outdated D8 module to the D8 environment and after the next cron run I received the notification email.

I also back ported the patch to D7 and here too everything works as expected.

I expect to get an email every day now if I set “check for updates” daily and every week if I set “check for updates” weekly.
As I told you php is new for me but if I look at the update_cron () function:
I suppose that $frequency becomes either 1 or 7 depending on the choice daily or weekly and that $interval becomes the number of corresponding seconds.
What surprises me is that the configured update interval and the configured time between notifications both relate to $interval
I understood from the comments in #21 that that you like to get reminders once a week, not more often. So I was expecting on update.module line 304
if ((REQUEST_TIME - variable_get('update_last_email_notification', 0)) > 60 * 60 * 24 * 7) or something like that.
Anyway I’ll keep on testing and let you know if I encounter strange or unexpected results.

I have a small question about patch #34: If at line 307 it is necessary to add module_load_include('inc', 'update', 'update.fetch'); before _update_cron_notify();
Is it not needed as well before the _update_cron_notify(); at line 297 ?

I'm hesitant to mark that issue as a duplicate of this one for a couple of reasons:

The approach being discussed in #359171 also addresses a related issue that is currently unique to D6 and already appears to be addressed in D7/D8 core (update data is still refreshed on admin pageloads)

My guess is that this issue (marked for D8) won't receive much review attention by those using D6

Please let me know if I'm off base with this or if I should move that D6 patch to this queue.

@luk.stoops
no, the call to _update_cron_notify() on 297 is preceeded by call to update_refresh which by itself loads update.fetch.inc. I'm hesitating though, should we refactor the loading and calling _update_cron_notify in a separate function. Like it's the case with for example update_create_fetch_task.

FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1263040-no-notifications-sent-when-updates-are-available-40-D7_x.patch. Unable to apply patch. See the log in the details link for more information.

All tests on #34 provided expected results.
I’ll suggest that possible refactoring’s could taken in account in the new spin off issue #1566662 ?
I include the D7 backport.
It’s my first patch ever so please handle with care;-)
What are the next steps to get these committed?

FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1263040-no-notifications-sent-when-updates-are-available-40-D7_x_0.patch. Unable to apply patch. See the log in the details link for more information.

Oops, I started reviewing this issue about a week ago, but then life intervened before I actually left a comment here....

I think the patch looks good too and would have committed it as is also, but I had a couple thoughts:

First, since this touches a fundamental part of the Update Manager and doesn't come with any tests, I thought it might be a good idea for someone like @dww to take a look at it. I'm assigning this to him, in case he gets a chance to... Won't be the end of the world if he doesn't, but I'd feel better if he gave it a +1 since he knows this module the best :)

For example, one thing that's a little odd about introducing the second variable is that it seems likely for the variables to get out of sync (i.e, your site will learn about about a critical security issue on Wednesday, but you won't actually get an email about it until the next Monday). That seems contrary to what the code in update_cron() was trying to do, which was basically to notify people as soon as the info is available, per this code comment:

// If the configured update interval has elapsed, we want to invalidate // the cached data for all projects, attempt to re-fetch, and trigger any // configured notifications about the new status.

Of course, notifying people a few days late is better than not notifying them at all, so in most cases this patch probably constituted an improvement.... and therefore seems OK at least as an interim step.

Second, speaking about the above code comment, isn't it no longer accurate as a result of this patch? I think it needs to be changed to reflect what the new code is doing.

It would be a really good idea to write tests for this; this is pretty important functionality and it's very bad if it breaks. As far as I can see, that ought to be possible as long as the tests can adjust the variable so that notifications happen on the order of seconds rather than having to wait days? :)

Thanks for pinging me about this. Sadly, I've been fighting a nasty cold for close to a week now, and am therefore desperately behind on d.o D7 porting work, and I was supposed to leave town this morning for 2.5 weeks. Ugh. :( So, I'm not going to be able to review this until late July or early August, if at all. I'm a terribly update manager maintainer, I know. Woe is me. Anyway, unassigning so no one is blocked on a real review. Sounds like this is in good hands with David's latest comments, at least. ;)

@catch, please look at #5 vs #2. The motivation for proposed solution was the difference in update & report logic in D6 vs D7. The problem I told about in #2 doesn't exist in D6, I don't understand how this patch can be backported.

I regularly receive update notifications from D6 sites I'm looking after. If there is a problem with that though, I believe it must be somewhere else.

@akamaus, I believe that the steps to replicate the problem (update mails being missed) is different in D6, but the fix (adding a new variable to track notifications being sent separately from updates being checked) is the same. The missed update notification issue is less common in D6, but it can still happen, and this same general fix appears to address it.

#62 moved this to major based on Drupal 6, but comments above pointed out there's already a separate issue for Drupal 6 (and it's major too). We don't need two major issues, especially when one is filed against Drupal 8 and counting against thresholds even though the bug is already fixed :)