hi merlin. i made a few minor but good improvements in the D6 copy in my sandbox:
http://drupal.org/cvs?commit=71732
Fixing up settings tab to emulate system_settings_form() more closely. We can't actually use that, since it forces certain things we don't want, but for the consistency of the UI it's good to behave like it.
http://drupal.org/cvs?commit=71721
There's no reason to define and register update[_status]_system_submit() as a callback, we can just register update[_status]_invalidate_cache directly.
Any objections to me backporting them into D5? They'd require a little work, since they both touch FAPI, so I don't want to spend the time if you don't think they're worth putting in.
Just let me know.
Comments
Comment #1
merlinofchaos commentedupdate_status_system_submit is more flexible; I'd rather stick with that.
Not sure about the system settings form one. Use your judgement =)
Comment #2
dwwRe: update_status_system_submit() -- fair enough. I guess we might want to add more later.
Here's a followup on the system_settings_form() thing:
http://drupal.org/cvs?commit=71806
Also, let me know what you think about the split into .inc files:
http://drupal.org/cvs?commit=71802
http://drupal.org/cvs?commit=71810
http://drupal.org/node/94154#comment-266878
It's true that D5 doesn't support this as nicely (e.g., no help from the menu system), so it might not be worth it, but perhaps update_status.fetch.inc and update_status.compare.inc are worth backporting?
http://drupal.org/cvs?commit=71804 for better core consistency, or leave it 'enabled' and 'disabled'? ;)
thanks,
-derek
Comment #3
dwwCommitted a slew of changes. Mostly upto comment #67 in http://drupal.org/node/94154, with a few other minor points taken care of from later comments. Also, the relevant parts of #87 are now in here, which made it easy to add the nagware from #98. I gotta go now, but I'll continue this ASAP. I was originally just going to make a list of changes for 5.x-1.1, but I found it was easier to just fix as I go, instead of filing issues, etc. ;)
Comment #4
dwwWe're upto comment #99, except for the separate {cache_update_status} table. I think that might want to wait for 5.x-2.1.
Almost there! Just a few minor usability tweaks from #123 and we're ready for 5.x-2.0-rc2 (and the string freeze). Hopefully later tonight...
Comment #5
dwwOk, had a brief chance for the last of the fixes I plan to do for 5.x-2.0.
All that remains (not all of which I think we should even backport) are:
- adding a {cache_update_status} table
- splitting into .inc files
- t('No filedate available') and t('Invalid info') could be more helpful to the user
- phpdoc
- variable renames in functions and nested arrays
Any final objections before the 5.x-2.0-rc2? The t() items on here are the only possible changes to the strings now.
Comment #6
vikingew commentedI just installed the latest 5.x-2.x-dev and on manual check I get this
warning page not found 08/07/2007 - 14:08 admin/logs/updates/check JoakimYes I ran update.php
Comment #7
vikingew commentedHm not sure what I did, but suddenly it started to work, maybe some cron job had to run first to set things right. It shouldn't matter as I have no caching set in performance and browser cache is disabled, but I ran Empty Cache from Devel this time before opening the module but there might been some caching going on anyway behind the sceen.
One thing I miss though since some updates ago, is that it no longer show the availability of a later dev release when you have a stable release installed. I think it did so at some point... Fact is many modules doesn't get stable updates that often and a clear majority of them are out of date I would say, while the dev often are uptodate and stable "enough". Well that's my thinking anyway.
Comment #8
dww@yettyn: You have to clear your menu cache *after* installing the new version of the module for it to work (which is done every time you save the admin/build/modules page, for example). I added a
cache_clear_all()to update_status_update_5201() so folks don't get hit by this.@merlin: the one other item from the core version we don't yet have here is porting the settings tab to use system_settings_form() so that the UI is more consistent and we start supporting "Reset to defaults". This is a big enough change that I think it, too, should be postponed until 5.x-2.1.
Comment #9
dwwOk, 5.x-2.0-rc2 is out. I think everything else in here should wait for 5.x-2.1. If someone wanted to be helpful and create separate issues for each of the tasks i mentioned at #5 and at the bottom of #8, and then closed this issue, that'd be great.
Comment #10
vikingew commentedWith all respect but shouldn't this be RC3 really? Afair RC2 was out sometime in July or even late June. At least it has been running on one of my sites for quite some time now :-)
Comment #11
vikingew commentedOk after an update check it now says I an running rc and recommend to update to rc2, but I am sure it said rc2 before I did the check... nevermind.
Comment #12
dwwnope. regular old "rc" was out at the end of june. there hasn't been a release since then. hence, "rc2".
Comment #13
dwwOk, this is now resolved. All the remaining tasks mentioned in here have their own issues now:
http://drupal.org/node/155450 -- separate {cache_update_status} table
http://drupal.org/node/167486 -- Split up code into separate .inc files
http://drupal.org/node/167488 -- t('No filedate available') and t('Invalid info') could be more helpful to the user
http://drupal.org/node/167489 -- backport phpdoc
http://drupal.org/node/167490 -- convert settings tab to use system_settings_form()
I don't think I'd want to mess with the "variable renames in functions and nested arrays" one...
Comment #14
(not verified) commented