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.Splitting this off from #11416: Please provide *.zip downloads. since it's more of an infra issue than a project* development question.
Based on how the views that power the download tables for project nodes work, we're going to have a problem when we first deploy .zip on d.o. The current plan was to not repackage any existing releases to provide .zip, and only let .zip start filling in as new packages are built (either new -dev as the code is updated, or new official releases).
The views being considered over at #11416 and undergoing UX review all mostly degrade just fine for releases with only one file. The | delimited ones degrade perfectly. The ul ones have the additional markup, but so long as the li isn't styled with a circle or anything, it's not really going to matter. However, they're always going to show 2 files if there are two. That's going to be a problem for existing packaged install profile distributions. Those all have 3 tarballs: a full distro (core + profile + projects), projects-only, and profile-only. So, until new releases are created for those, the download tables are going to show basically:
Download tar.gz (3 MB) | Download tar.gz (1 MB)
for the full distro and the everything-but-core distro. :( Not sure what we want to do about that. A few options:
A) We could retroactively re-package .zip for all install profiles + distros so that we'd always have a .tar.gz and a .zip of the full distro to include in these tables as soon as we deploy the views changes for multiple files per release.
B) We could just retroactively re-package everything and immediately have .zip available for all releases.
C) We could try to write some extra code in the project_release views handler to exclude two files with the same filename extension.
D) We could mark this issue "won't fix" and just email install profile maintainers saying "Please make new official releases of your profiles so that they get repackaged with .zip ASAP".
Anyone feel strongly? Now that I look at it, (C) isn't as bad as I thought it might be, and probably gives us exactly what we want with no additional repackaging. If that's the best solution, we can just move this issue over to the project queue and retitle it. ;)
Thanks,
-Derek
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1006238-5.distro-release-table-without-zip.png | 35.5 KB | dww |
| #4 | 1006238-4.project_release_handler_field_files_max_weight.patch | 2.67 KB | dww |
| #1 | 1006238-1.broken-distro-release-table-without-zip.png | 36.65 KB | dww |
Comments
Comment #1
dwwBTW, here's what I'm talking about in action:
http://beta.drupal.org/project/drupalorg_testing
Comment #2
gregglesD won't happen, but would be fine to nudge those folks anyway.
A, B, or C all seem fine to me. C seems like it's the most robust. I say go with whatever takes the least work.
Comment #3
dwwActually, given #1006346: Add a {project_release_file}.weight column the most simple solution in here is to extend project_release_handler_field_files to add a little weight limit setting. Then we can just say we display a max weight of 1. The main release files we care about will use tar.gz = 0, zip = 1. The other variants (project-only and profile-only) will use 6, 7 and 10, 11 respectively. This should be the most robust and easiest solution. Rolling a patch now, stay tuned.
Comment #4
dwwYou need to apply #1006346-1: Add a {project_release_file}.weight column first, but this works beautifully to solve the problem.
I'm not going to change the default view to use it yet, I'll just do so over at #11416: Please provide *.zip downloads. once we figure out what UI we want for that.
Comment #5
dwwTested again on beta.d.o, working great:
Committed to HEAD of project.