Misleading instructions after enabling a module.
cpugeniusmv - June 6, 2008 - 23:49
| Project: | Update Status |
| Version: | 5.x-2.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | minor |
| Assigned: | dww |
| Status: | closed |
Description
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 :)
#1
Here's the attachment.
#2
This should fix the issue in 7.x-dev and 6.x-dev.
#3
cpugeniusmv, this looks good but it might be good to add a code comment that provides some context.
#4
Updated.
#5
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.
}
#6
I hadn't thought of that! I'll come up with a new patch.
#7
How's this?
#8
Code applies cleanly to d7 HEAD. Next cron update does update the module status page. +1 for RTBC.
#9
No longer applied, attached is a new version. (time() was replaced by $_SERVER['REQUEST_TIME'] recently)
Simple problem, simple patch, wonderful result. Marking RTBC.
#10
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.
#11
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.
#12
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
#13
Let's try this again...
#14
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
#15
Third time's a charm?
#16
#17
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:
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.
#18
Or I thought I did anyway. ;)
#19
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.
#20
Added two sets of parenthesis so that the relations are obvious on first sight. Committed this one.
#21
Now available in D7 with more parens (as per Gabor). ;) Once this lands (again), I'll fix D5 update_status in contrib...
#22
Fixed! (again :))
#23
Thanks, webchick. ;)
Here's an untested backport to update_status D5 contrib.
#24
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.
#25
Automatically closed -- issue fixed for 2 weeks with no activity.