#11416: Please provide *.zip downloads. would be a huge usability win for drupal.org. Dries even blogged about it. I've been working on the backend changes in project_release module to make this happen for a while. One of the last remaining hurdles to make it a reality is that update.module currently only knows about a single "Download" link from the XML and in the UI. We need to fix this. Ideally, in both D7 and D6, although it'd impact the string freeze in D6...
The relevant XML currently looks something like this:
<release_link>http://drupal.org/node/156281</release_link>
<download_link>http://ftp.drupal.org/files/projects/drupal-7.x-dev.tar.gz</download_link>
<date>1250813342</date>
<mdhash>6331b74cf71a09f699ff5a23d1207926</mdhash>
<filesize>1995307</filesize>
Update status itself doesn't even look at mdhash and filesize at this point. To prevent confusion with existing clients, I'd probably leave all of that in the XML, and just add some new stuff which newer clients would look at. Older clients will happily ignore the new data, and new clients will ignore the old. That seems easier than separate release history links to fetch some kind "schema-version-dependent" XML...
Anyway, I think the new XML should include something like this:
<release_link>http://drupal.org/node/156281</release_link>
<downloads>
<download>
<url>http://ftp.drupal.org/files/projects/drupal-7.x-dev.tar.gz</url>
<text>tar.gz</text>
<mdhash>6331b74cf71a09f699ff5a23d1207926</mdhash>
<filesize>1995307</filesize>
<filedate>1250813342</filedate>
</download>
<download>
<url>http://ftp.drupal.org/files/projects/drupal-7.x-dev.zip</url>
<text>zip</text>
<mdhash>6331b74cf71a09f699ff5a23d1209999</mdhash>
<filesize>1999666</filesize>
<filedate>1250813345</filedate>
</download>
</downloads>
Then, in the UI, instead of just Download as a link, We'd see:
It'll be a bit hard to implement/test this without real data on updates.d.o, and I'm going to be completely offline for the next two weeks, so I can't offer to coordinate/help in the short term. But, if anyone's really excited to get this in before D7 code freeze (just to be safe), they could follow the instructions I wrote over at Setting up a site to serve release history files used by the "Update status" module
Comment | File | Size | Author |
---|---|---|---|
#43 | 555362-multiple-download-links-43-do-not-test.patch | 3.68 KB | mikey_p |
#38 | 2015-02-05 at 12.03 PM.png | 91.83 KB | mikey_p |
#36 | 555362-multiple-download-links.patch | 2.81 KB | mikey_p |
#23 | 555362-20.png | 42.45 KB | klonos |
#20 | update_manager_download_links.png | 121.51 KB | bfroehle |
Comments
Comment #1
dwwI'm happy to report that I tested this with D6 update.module and it didn't break horribly. One PHP notice during parsing, but we don't ship with E_ALL enabled on official releases, anyway (right?). The resulting data structure is a little wonky due to our craptastic legacy parser (which, in fairness, is pretty good for PHP4), but 6.14 update.module works fine. The one trick is that we don't want to use the same attribute names inside the nested
<files>
array as any of the release-level attributes we care about (e.g. "date") or you get weirdness. But, so long as we avoid this, we're fine to start publishing more useful XML with the multiple files (which is an issue now that Fully packaged Drupal distributions now deployed on drupal.org is done -- see #652566: Support multiple download files per release in release history XML for more).I haven't tested on D7 yet since my local dev environment is broken again, but a) I bet it Just Works(tm) already and b) if not, we can definitely fix it before 7.0 ships.
Also, here's a patch for the D6 parser that removes the PHP notice and gives us a working data structure in case we actually want to use any of the new data (e.g. for the "tar.gz | zip" UI).
Comment #2
greg.harveyAnything I can do to help with this? Like you, I'm keenly interested in seeing #11416: Please provide *.zip downloads. happen, as you've probably gathered from my other posts this evening. ;-)
Comment #3
dwwNext step is probably to change how we generate the release history XML files to include more data as I describe above. See #652566: Support multiple download files per release in release history XML. Thanks for the offer to help, much appreciated!
Comment #4
dwwThe changes on d.o for .zip files are hopefully going to be happening Really Soon Now(tm). It'd be awfully nice to fix this before 7.0 ships. Bumping to major. Definitely not a release blocker, put just putting it on the radar again.
Comment #5
sun.core CreditAttribution: sun.core commentedA (starter) patch for D7 would help to evaluate whether we can still do this for D7. If it's going to look similar to the patch for D6, then chances are high.
Comment #6
mikey_p CreditAttribution: mikey_p commentedI've tested the above schema changes with D6 which simply ignores them, and I'm about to test Drupal 7 as well. I have a basic patch that would work with the above schema for D6, as long as the current fields are left in the schema, such as the following to represent a single release:
Comment #7
dww@mikey_p: Cool, thanks for moving this forward. However, now that I look at it again, can we call them
<files>
and<file>
instead of<downloads>
and<download>
? Maybe it doesn't matter, but a) it's smaller and b) more self-documenting (IMHO).Comment #8
mikey_p CreditAttribution: mikey_p commentedAlso confirmed that Drupal 7 does not choke on the above schema change. No warnings or notices were produced.
Comment #9
mikey_p CreditAttribution: mikey_p commented@dww #7, just read through your patch in #1, +1 to files, I'll make those changes.
Comment #10
mikey_p CreditAttribution: mikey_p commentedGot a basic patch working for parsing the release XML and getting the data into the update cache.
Now that the data is there just need to figure out the UI for the update status form, and figure out where we'd like to do the parsing to determine what to label each link. The simplest way to handle this would that each link would just be labeled with the full filename:
Download: drupal-7.0-beta3.tar.gz | drupal-7.0-beta3.zip
Comment #11
mikey_p CreditAttribution: mikey_p commentedTagging in preparation for RC.
Comment #12
dwwI think we should do what project_release's views code does and parse the filename to find the extension and stick with the UI I proposed in the OP. I suspect that using full filenames will visually overwhelm a UI that's already extremely busy.
Thanks!
-Derek
Comment #13
EvanDonovan CreditAttribution: EvanDonovan commented@mikey_p: Can you re-roll before rc1 with the UI from #12, or is it too late?
Comment #14
Bojhan CreditAttribution: Bojhan commentedNo idea why we need this, but I trust dww and mikey_p on that.
I think we should retain the Download trigger word, moving it outside of the link will make it visually harder to find. So for example: Download tar.gz | zip
Comment #15
mikey_p CreditAttribution: mikey_p commentedI'm not quite sure how to go about putting two links on one line given that the current download link and release note links are run through theme_links.
Comment #16
dww@Bojhan: The idea is that windows users are much more comfortable with .zip than they are with .tar.gz. So, for folks that:
- Are on windows
- Can't use the Update manager (there's a new core release, or Update manager is disabled in their config, or they don't have https and don't want to type their password in the clear, etc)...
having direct download links to the .zip versions (once they exist) will be a win.
@mikey_p: Not sure, I'd have to look more closely. It's been way too long since I've looked carefully at the code (theme function, I believe) that generates the update status report page.
Comment #17
EvanDonovan CreditAttribution: EvanDonovan commentedZip files are going to be a major usability improvement, believe me :) That's what the WordPress crowd that I believe this functionality is targeted at uses.
Comment #18
dwwEvanDonovan: I don't think that's what Bojhan's question is. I think he's raising the important question of why we need direct download links on the available updates report given that we have the Update manager. But I hope #16 answered that -- not everyone can use the Update manager, and since #606592: Allow updating core with the update manager was postponed to D8, no one can use it to upgrade core (and as good as the 7.0 release might be, we all know there's going to be a 7.1). ;)
Comment #19
bfroehle CreditAttribution: bfroehle commentedWell, we should be able to implement this feature now... How did the theming work on drupal.org?
Comment #20
bfroehle CreditAttribution: bfroehle commentedHere's a patch which builds upon mikey_p's code in #10. See the attached screenshot for the theming which is as suggested in the original post.
Comment #21
EvanDonovan CreditAttribution: EvanDonovan commentedPng looks good. Didn't look at patch yet.
Comment #22
klonos#20 seems to work just fine for me in latest 7.x-dev. Thanx ;)Comment #23
klonos...rushed to jump into conclusions:
...of course available updates status is messed up (see attached screenie).
PS: I hope this is not another php 5.3.x issue.
Edit: all these errors were simply being repeated. No point to have them multiple times - makes the post longer.
Comment #24
bfroehle CreditAttribution: bfroehle commented@klonos: Did you apply any other patches, since the differences you are displaying are not related to this patch.
Comment #25
klonos...fresh setup (minimal profile) of latest dev (March 1st) with only that patch applied. Reverting the patch fixes the errors.
Comment #26
bfroehle CreditAttribution: bfroehle commented@klonos: Whatever you are experiencing is a different issue. The patch doesn't touch anything with 'status' or update.compare.inc or similar. That said, I did notice one bug in #20:
This should be is_array() (and not !empty()) -- otherwise there are errors if the update cache is not cleared immediately after upgrading. Essentially $version['files'] is set to a string in 7.0 so !empty() will always return true.
Another option would be to just override the 'download_link' parameter to be either a string or an array of associative arrays, each containing a 'url' and 'archive_type' key.
I've tried but cannot reproduce, what you experienced in #23.
Comment #27
aspilicious CreditAttribution: aspilicious commentedSubscribe, pushing to D8? + backport?
Comment #28
Bojhan CreditAttribution: Bojhan commentedFor the record, the solution of tar.gz and .zip we won't allow anymore. In testing we found that it confused people.
Comment #30
greg.harveyDoes that mean .zip will be withdrawn from d.o? Just curious...
Comment #31
Bojhan CreditAttribution: Bojhan commentedNo, it means we will optimize how we show it.
Comment #32
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedWell, what are the alternatives?
"Support multiple download links in the available updates report." My mind draws a blank as to how to implement this without using tar.gz | zip (or writing it in a less confusing way that does not take a lot of space). Any ideas?
The users are confronted with this choice when downloading something from Drupal.org. What makes it so confusing when they have to make the same choice again? By then I suppose they understand the choice they made, as they would have had to unzip/untar Drupal core. To be fair that could have been done for them and they are now maintaining an already set up Drupal site, but is it so bad to force the user to make this choice? They will have to become familiar with either zip or tar anyway if they are going to update their site (assuming drush users already know this). It was obviously deemed to be good enough for Drupal.org and its visitors.
Comment #33
klonosYeah, besides I really think this is (mostly) a win/unix thing. If you think that providing both download variants is too much of a UI mess, we can then simply detect the server environment (checking if DIRECTORY_SEPARATOR is "\" or "/" for example - I don't know) and based on that provide only one option.
...or we can make this whole thing configurable in the settings tab. We already have options in this tab related to the way updates are presented to admins. There is the "Also check for disabled modules/themes" checkbox provided by core, the ignore list provided by Update status advanced settings module and there could be others as well from other contrib that I'm not familiar with. So, we can have a "Select the format(s) that updates are offered" radio-box set with three options: ".zip", ".tar.gz" & "both". The default could either be the "both" or -instead of hard-coding it- we can base it on a server OS check I mentioned before.
Comment #34
tim.plunkettRecategorizing.
Comment #35
jhedstromProbably needs to wait until 8.1.
Comment #36
mikey_p CreditAttribution: mikey_p commentedLooking through old issues and found this. Re-rolled this as a drop button since we now have that available. The styling is a still a bit off, but I'll need someone better at frontend to look at that.
Comment #38
mikey_p CreditAttribution: mikey_p commentedComment #39
mikey_p CreditAttribution: mikey_p commentedComment #43
mikey_p CreditAttribution: mikey_p commentedWhen 8.1.x catches up, this should be ready to test.
Comment #51
jhedstromSince the preferred method for updating modules is now composer, should we even be providing links at all anymore?
Comment #60
smustgrave CreditAttribution: smustgrave at Mobomo commentedSince there has been no follow up to #51 going to close out as outdated. If still a request please reopen addressing #51 comment and updating issue summary for D10 and up.
Thanks!