Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 :)
Comment | File | Size | Author |
---|---|---|---|
#24 | 267724-24.update_status_fix_cron.d5.patch | 1.81 KB | dww |
#23 | 267724_update_status_fix_cron_D5.23.patch | 986 bytes | dww |
#21 | 267724_update_fix_cron_7x.21.patch | 857 bytes | dww |
#20 | update_fix_cron_6x_2.patch | 901 bytes | Gábor Hojtsy |
#19 | update_fix_cron_6x.patch | 924 bytes | maartenvg |
Comments
Comment #1
cpugeniusmv CreditAttribution: cpugeniusmv commentedHere's the attachment.
Comment #2
cpugeniusmv CreditAttribution: cpugeniusmv commentedThis should fix the issue in 7.x-dev and 6.x-dev.
Comment #3
Dries CreditAttribution: Dries commentedcpugeniusmv, this looks good but it might be good to add a code comment that provides some context.
Comment #4
cpugeniusmv CreditAttribution: cpugeniusmv commentedUpdated.
Comment #5
dwwI 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:
Comment #6
cpugeniusmv CreditAttribution: cpugeniusmv commentedI hadn't thought of that! I'll come up with a new patch.
Comment #7
cpugeniusmv CreditAttribution: cpugeniusmv commentedHow's this?
Comment #8
obsidiandesign CreditAttribution: obsidiandesign commentedCode applies cleanly to d7 HEAD. Next cron update does update the module status page. +1 for RTBC.
Comment #9
maartenvg CreditAttribution: maartenvg commentedNo longer applied, attached is a new version. (time() was replaced by $_SERVER['REQUEST_TIME'] recently)
Simple problem, simple patch, wonderful result. Marking RTBC.
Comment #10
webchickNeeds 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.
Comment #11
cpugeniusmv CreditAttribution: cpugeniusmv commentedRe-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.
Comment #13
cpugeniusmv CreditAttribution: cpugeniusmv commentedLet's try this again...
Comment #15
cpugeniusmv CreditAttribution: cpugeniusmv commentedThird time's a charm?
Comment #16
cpugeniusmv CreditAttribution: cpugeniusmv commentedComment #17
webchickOk, 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:
After patch:
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.
Comment #18
webchickOr I thought I did anyway. ;)
Comment #19
maartenvg CreditAttribution: maartenvg commentedYup, 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.
Comment #20
Gábor HojtsyAdded two sets of parenthesis so that the relations are obvious on first sight. Committed this one.
Comment #21
dwwNow available in D7 with more parens (as per Gabor). ;) Once this lands (again), I'll fix D5 update_status in contrib...
Comment #22
webchickFixed! (again :))
Comment #23
dwwThanks, webchick. ;)
Here's an untested backport to update_status D5 contrib.
Comment #24
dwwNow 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.