After enabling a module, the update cache is flushed and you see the message in the attached picture. The message leads me to believe that when cron runs next (either manually or scheduled), the update statuses will be re-cached but they aren't. The "check manually" link does work.

The source of the problem is that when the update cache is cleared, the update_last_check variable doesn't get reset. Cron will eventually update the cache on the schedule it would have done anyway without the new module installation. So it's not a critical problem, but it confused me enough to warrant this post :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cpugeniusmv’s picture

FileSize
18.9 KB

Here's the attachment.

cpugeniusmv’s picture

Version: 6.2 » 7.x-dev
Status: Active » Needs review
FileSize
476 bytes

This should fix the issue in 7.x-dev and 6.x-dev.

Dries’s picture

cpugeniusmv, this looks good but it might be good to add a code comment that provides some context.

cpugeniusmv’s picture

Updated.

dww’s picture

Status: Needs review » Needs work

I don't think this is the right patch for this problem. This clobbers the information about the last time we checked for updates. That's printed in the UI, and just because the cache is invalidated for some reason doesn't erase the fact that we last checked for updates 5 hours ago or whatever it is.

Instead, we need to change the logic in cron when deciding if we need to check for updates to use logic something like:

if (!$have_any_data || $been_too_long_since_we_last_checked) {
  // Check for updates.
}
cpugeniusmv’s picture

I hadn't thought of that! I'll come up with a new patch.

cpugeniusmv’s picture

Status: Needs work » Needs review
FileSize
828 bytes
828 bytes

How's this?

obsidiandesign’s picture

Code applies cleanly to d7 HEAD. Next cron update does update the module status page. +1 for RTBC.

maartenvg’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
932 bytes

No longer applied, attached is a new version. (time() was replaced by $_SERVER['REQUEST_TIME'] recently)

Simple problem, simple patch, wonderful result. Marking RTBC.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Needs a re-roll again due to REQUEST_TIME.

Could we also see a before/after screenshot of what this patch changes? http://webchick.net/visualize-your-patches Preferably with some arrows pointing to what's wrong. I didn't quite grok it from the original description.

cpugeniusmv’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
840 bytes

Re-rolled.

There are no changes made to the UI by this patch. Before this patch, if there is no cached update data (e.g., a module was just installed) and the amount of time that has passed since the last update fetch is less than the interval configured for update checks, running cron wouldn't get the update data.

The patch simply modifies the behavior of cron so that update data is fetched when it doesn't exist, regardless of the last time it was fetched.

Status: Reviewed & tested by the community » Needs work

Patch failed to apply. More information can be found at http://testing.drupal.org/node/14501. If you need help with creating patches please look at http://drupal.org/patch/create

cpugeniusmv’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
821 bytes

Let's try this again...

Status: Reviewed & tested by the community » Needs work

Patch failed to apply. More information can be found at http://testing.drupal.org/node/14502. If you need help with creating patches please look at http://drupal.org/patch/create

cpugeniusmv’s picture

FileSize
868 bytes

Third time's a charm?

cpugeniusmv’s picture

Status: Needs work » Reviewed & tested by the community
webchick’s picture

Ok, I think I duplicated this bug (it's hard to tell, because there aren't really testing instructions in this issue, and the modules page is so FUBAR right now) via the following:

Before patch:

  1. Enable Devel module
  2. See message about no update information available
  3. Click "run cron"
  4. See that the message about no update information available persists

After patch:

  1. Enable Devel module
  2. See message about no update information available
  3. Click "run cron"
  4. See that the message about no update information available goes away

The latter behaviour looks to be an improvement, so I committed. Let me know if there's something I overlooked.

Marking down to 6.x.

webchick’s picture

Version: 7.x-dev » 6.x-dev

Or I thought I did anyway. ;)

maartenvg’s picture

FileSize
924 bytes

Yup, that is exactly the way it should behave. Because the message (by update.module) tells you to run cron to solve a problem, and running cron doesn't solve the problem. That's annoying, and fixed by this patch.

Thanks for commiting!

Attached is the version for D6.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed
FileSize
901 bytes

Added two sets of parenthesis so that the relations are obvious on first sight. Committed this one.

dww’s picture

Version: 6.x-dev » 7.x-dev
Status: Fixed » Reviewed & tested by the community
FileSize
857 bytes

Now available in D7 with more parens (as per Gabor). ;) Once this lands (again), I'll fix D5 update_status in contrib...

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Fixed! (again :))

dww’s picture

Project: Drupal core » Update Status
Version: 7.x-dev » 5.x-2.x-dev
Component: update.module » User interface
Status: Fixed » Needs review
FileSize
986 bytes

Thanks, webchick. ;)

Here's an untested backport to update_status D5 contrib.

dww’s picture

Assigned: Unassigned » dww
Status: Needs review » Fixed
FileSize
1.81 KB

Now that #155450: backport separate {cache_update_status} table and private non-volatile cache API from D6 core is fixed, I ported #23, tested, and committed the attached patch to DRUPAL-5--2.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.