Posted by NancyDru on May 5, 2009 at 4:47pm
| Project: | Update status advanced settings |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | fixed |
| Issue tags: | D7 porting, d7 ports, port to d7 |
Issue Summary
Just curious when this was planned.
Comments
#1
When we see how much update.module changes in D7 and what (if anything) we still need update_advanced for. ;) I guess one obvious answer are these:
#162788: Include modules that aren't enabled
#445748: Add hook_update_projects_alter()
So, yeah, we'll probably still need update_advanced... :/
Patches welcome if someone wanted to start porting to the latest UNSTABLE or something.
Not very itchy for me right now, so I doubt this is going to happen anytime soon if people wait for me to do it.
#2
Don't forget developers who have to mark their modules to be ignored.
#3
Yes, I do recall what update_advanced currently exists for. ;) I just have some fantasy that that's going to get into core somehow. Probably sheer fantasy. :(
#4
Well, if I can get Coder to actually run in D7, I might take a look at a patch.
#5
Assigning myself for a contrib upgrade code sprint.
#6
That's great. However, with the 10/15 D7 core freeze looming, I'd vote that any of the following are more time-critical than this:
#555362: Support multiple download links in the available updates report (.tar.gz + .zip packages like on drupal.org)
#238950: Meta: update.module RAM consumption
#361563: Update Notifications causes SQL Server to go away
#319033: Weird order of projects listed on updates page
#237608: "Recommended version" for unsupported branch
#210144: If currently installed release is not found, update.module prints bogus information
#208766: Latest release from maintainer's recommended branch called "Also available", not "Recommended"
;)
#7
Yeah, agreed. I wanted to wait until we hit post-freeze/slush/etc. Marking as postponed.
#8
It should be noted in the module's front page that so far the 'Check for updates of disabled modules and themes' feature is already in D7 core.
#9
Does #8 mean this module does not need to be upgraded? Regardless of answer, could this module's status be recorded in a way that Upgrade Status sees it? Right now Upgrade Status says "No available releases found".
(Marking as active given #8 and this addition.)
#10
Nope! It means that so far one of this module's features is in D7 core already, so this feature does not need porting.
The module though has the feature of controlling update notifications per-module. This feature is not available in D7 core so it does need porting (unless they merge it core too at some time before D7 is released).
Upgrade Status is detecting no 7.x version of Update status advanced settings (correctly, as there is none available), that's why it is in 'No ported yet' status. Once there is a 7.x release available, the status will be updated to reflect that.
#11
...even if all features of this module eventually get into D7 core, it will be once again handled properly by Upgrade status with this: #620714: Denote modules which are in D7 Core
#12
...also with this one: #903060: Better handling for partially in core cases
#13
I really am starting to miss the per-module ignore feature in my D7 test setups. Mostly because I need to ignore a couple of modules that their 7.x-dev versions are in 'not supported' state like CCK and Drupal Reset.
@Dave, #7: Being so close to the D7 release date, can you please consider a 7.x dev with this feature? Please? Thanx.
#14
It will happen at some point, this just isn't a high priority on my list. The D7 release date is only a guess at when the critical issue queue will be completed, not when D7 will actually reach 1.0.
#15
Thanx Dave. I can see it is set to minor and I perfectly understand why. I saw the last update on the issue was last year before I posted #8. So, I was just trying to give it a small boost so it won't fall off your radar ;)
I also know about the D7 release date, since I've seen the date being pushed a little bit further back each time another couple of bugs were promoted to critical. It's just that I am excited we are getting so close now! Hope we can make it before the year change. /keeps fingers crossed/
#16
Subscribe.
#17
Well, rc3 got released today and an official final release date was announced - but I am sure you already know that ;)
...just to get this back on your radar Dave ;)
#18
Subscribing.
#19
subscribe
#20
subscribe
#21
Subscribing.
#22
Any status on this? Because of the drush-integration this module is a crucial part in many sites' upgrade/update processes. It makes automated sitewide module updates easy with svn sync and without messing up patched code.
If no D7 version is released sometime soon, it may actually slow the process of moving new or old projects from D6 to D7.
To me this issue is closer to major than minor, so I'm setting this accordingly.
#23
+1
#24
#25
(Subscribing.)
The D7 version will show updates for disabled modules as well, right?
#26
@Taxoman: D7 core already has that setting.
#27
@dww: yes, but we are forced to set daily or weekly check, cannot set it to be triggered manually only, or am I missing something? I really do not a) want to bug the drupal servers unnecessarily, and b) not trigger this resource-intensive request on the local server unnecessarily either. Hopefully this contributed version can provide some more flexibility than the one in core.
#28
@Taxoman: "manual only"? Sure you already have that - disable the module. I rarely enable Update on a production site - only on my dev version. I have had too many cases where the site got badly broken because of a module update. I test it first - and even then it occasionally breaks the production site. And if there are sub-admins who continually see the "available updates" message, they can get nervous and even think I don't know about it.
#29
@NancyDru: I mean the convenience of having it enabled so it is only a matter of accessing a url at will without having to enable a module to get the list. To have to enable it every time we want to check that list would become increasingly annoying, I think - especially when administering many sites across several servers and hosting providers/environments. I too prefer to avoid using the automatic updates on production sites. Every site has a test version, a development version and a production installation... So there is no perfect solution other than having the flexibility to adjust it to the situation for each site.
#30
Is anyone working on the D7 port?
#31
Not that I know of.
#32
subscribe
#33
EDIT: download link removed
#34
Thanx for the initial port Bálint. I'm testing right now!
PS: One minor thingy with the .tar archive though... it seems to suffer from the "tar: A lone zero block at ##" error (using Ubuntu 11.04 with latest tar and
tar -xz --directory="." -f "[filename]").#35
...looks ok so far.
I still suffer from the issues I mention in #909712: Globally allow dev versions to be reported as available updates + fine-grained control over ignored items (which I think I'd better break down to smaller sub-issues - given the fact that it had no attention for close to a year now).
#36
Using latest 7.x-dev core. I got these two errors today after resetting an ignored version of a module back to 'always' and saving:
Notice: Undefined index: title in theme_update_advanced_settings() (line 100 of /var/www/sites/all/modules/update_advanced/includes/settings.inc).
Notice: Undefined index: title in theme_update_advanced_settings() (line 113 of /var/www/sites/all/modules/update_advanced/includes/settings.inc).
Setting were saved ok though. @Pasqualle: Any ideas Bálint?
#37
...ping?
#38
It doesn't take under account the "Also check for disabled modules & themes" setting. No way to disable update warnings for disabled modules.
#39
subscribe
#40
I still use Pasqualle's version from http://windmill.sk/project/module/update_advanced and it works fine so far (besides the minor "bugs" I mention in #35 & #38 above), but I just had this slight WTF today...
Custom Formatters 7.x-2.x-dev (2011-Oct-17)Recommended version: 7.x-2.0 (2011-Jun-30)
Latest version: 7.x-2.1-beta1 (2011-Oct-17)
Development version: 7.x-2.x-dev (2011-Oct-17)
...when I went to the "Settings" tab in order to exclude 7.x-2.1-beta1, the only option given in the drop-down menu (besides "Always" & "Never" of course) was "Ignore 7.x-2.0". It does its magic by selecting that too, but I'd expect to either see a "Ignore 7.x-2.1-beta1" option as well, or only that alone.
#41
subscribe
#42
@klonos: Thanks for testing.
@basicmagic.net: Stop subscribing, start following!
@all: A monolithic new project download offsite isn't particularly easy to review. Can someone generate a patch and post it here?
Thanks,
-Derek
#43
#35 I don't know, I guess new feature..
#36 can't reproduce. can you give me a list of modules and themes you have. The 'title' index contains the module name or theme name. So it is quite weird that it is missing.. Or if you can find which module makes that notice, that would be even better.
#38 that's a bug. I have a solution (need to rename disabled-module to module-disabled, same for disabled-theme)
#40 #647428-15: Show latest release (if different from recommended release) in the "Other releases" table 7.x-2.0 is the latest official release, not 7.x-2.1-beta1 (check the project page). But anyway that missing option is also a bug in this module, I guess, as it is not consistent with update status..
#44
patch without the directory changes..
my first git patch, so not sure if it works..
#45
Thanx for the prompt replies and actions guys.
@Pasqualle:
I know, that's why I filed #909712: Globally allow dev versions to be reported as available updates + fine-grained control over ignored items ;)
Let me take off some burden by troubleshooting this myself and try to locate offending modules. The possible explanation you gave is enough for now to look a bit further into this. Thanx ;)
Are you referring to lines 122-123 in settings.inc?:
'disabled-module' => t('Disabled modules'),'disabled-theme' => t('Disabled themes'),
If so, then does this look right?:
'module-disabled' => t('Disabled modules'),'theme-disabled' => t('Disabled themes'),
I know that. I always use latest dev anyways ;)
...It's just that if you make all available updates show in the drop-down, then one would be able to ignore either one or the other (it is a drop-down not a multi-select checkbox set). So, even if one sets 7.x-2.1-beta1 to be ignored, they might still be offered the 7.x-2.0. In my case (person using only latest devs), it would leave me without options to ignore both. That's why I filed #909712: Globally allow dev versions to be reported as available updates + fine-grained control over ignored items.
Thanx for pointing to #647428: Show latest release (if different from recommended release) in the "Other releases" table
#46
...I guess it is right because I know can see a "Disabled modules" section in my Available updates' "Settings" tab. Thanx for the clue Pasqualle ;)
#47
...stupid me, it was all in the patch you've attached in #44. D'oh!
#48
I had to apply by hand, but that could be due to my set up.
I installed the module on a fresh D7.8 setup and it installed without issues.
A problem is that the module itself is not listed in;
- admin/reports/updates/list
- admin/reports/updates/settings
Other than that it look sfine for now, haven't tested thoroughly tho!
Cheers and thanx for the port!
#49
I've been using it for a while on several D7 sites. There are these issues mentioned, but I would still call #44 releaseworthy :)
A release would bring in new users which can help clean out minor bugs.
#50
I second Ilmari's thought. I've been using it in at least 3 setups with no issues.
#51
I think I might have a clue on the "Undefined index ..." issue reported back in #36. I'm surprised I haven't noticed this previously, but here's what I've noticed now...
Some of you might have faced this issue where after checking for updates, some of the projects' status is displayed in gray and there is a "Failed to check for updates for [x number] of projects" error message. If you switch to your settings page, you'll see that these projects aren't listed in the table that Update status advanced adds (bug?? ...related perhaps? I don't know). If you save the settings (even without selecting a version of a module to be ignored) there is a message that the settings have been saved along with a list of these "Undefined index..." messages. Their number is equal to the modules that drupal failed to check their update status.
This could simply be a quiescence of course :/
PS: ...btw, I'm using this in almost a dozen of my setups without issues in its functionality. Can we please make this an official 7.x-dev?
#52
I mailed dww yesterday to get his attention on this for a moment. Hope he has the time.
#53
Sorry I've been MIA in here. Way too much going on in my life these days. I haven't had a chance to test #44, but a very basic skim of the patch looked okay, so I pushed that to the 7.x-1.x branch in the upstream Git repo and created a 7.x-1.x-dev release. Any problems with the port should be posted as new issues.
Thanks to Pasqualle for the port, and to everyone who tested!
Cheers,
-Derek
#54
Thanks dww and all involved :)
#55
Yeah, thanx Derek! Perhaps adding Pasqualle as a (co)maintainer for the 7.x branch would help ...I mean if he's up to it ;)
#56
I try to minimize the amount of modules I have to maintain. I rather fix the problems I encounter and let the maintenance to someone who has more free time.
http://drupal.org/taxonomy/term/999
The modules (and themes?) seeking co-maintainers just exceeded 666, which is a big problem. We will have to find a working solution, because half done modules could make a bad name for Drupal..
#57
I might be interested in co-maintainership of this module, if pasquelle isn't. Anyway, this case is resolved.
#58
@bibo: link for you: Apply as co-maintainer, if you do not get an answer try dww's contact form, but please just don't give up trying. Thanks
#59
@Pasqualle: fair enough, but I wasn't talking about full-time maintenance (IOW issue queue baby-sitting). I mean that if you had commit rights yourself, then this would most likely not have taken so long. Derek and Dave are also busy with other projects + Real Life (tm), so the last commit to this project was back in October 2009 (if you exclude this one here and the Git migration "hiccup"/dummy commit in February 2011).
PS: there's only less then a dozen of issues in this project's queue btw ;)
#60
This module rarely gets commits since it doesn't do very much and it does it well. I'm not opposed to adding comaintainer(s) but only if they share my vision for the module (in this case, small, light, and simple). But yes, let's talk in another issue if anyone's serious about it.
Cheers,
-Derek
#61
Since this issue here is closed, I've filed a separate one for the issue in #36: #1418870: Notice: Undefined index: title in theme_update_advanced_settings() in sites/all/modules/update_advanced/includes/settings.inc
#62
Small, light and simple. Got it. I'm definitely not opposed to that idea, I also have very limited time. I use this module all the time professionally.
I'll request co-maintainership once I've gotten GIT/ project access the proper way: through a module I'm building, which is not anywhere near publication yet.
#63
you do NOT need git access to become a co-maintainer. The module maintainer can give git access to you just for his/her module.
#64
@Pasqualle
I have no excuse then ;) => #1419074: Co-maintainer Application for update_advanced