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.once http://drupal.org/node/89538 is done, if you go to the project browsing pages (e.g. http://drupal.org/project/Modules/name) and select <all> for the "Filter by Drupal Core compatibility" form element, instead of just displaying a random download link, if a project has more than 1 release, we should just use another instance of our happy project_release_table() from http://drupal.org/node/89539.
we already have to do a separate query for each project to get the "latest download" link (see http://drupal.org/node/89538#comment-163269 -- we tried), so if we're filtering by [all], we just call our table-generator with the right args, and it does a single query instead of us doing it ourselves.
(this patch depends on #89538 and #89539).
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | project_browse_all_download_table.patch_3.txt | 11.37 KB | dww |
| #5 | project_browse_all_download_table.patch_2.txt | 11.36 KB | dww |
| #2 | project_browse_all_download_table.patch_1.txt | 3.36 KB | dww |
| project_browse_all_download_table.patch.txt | 2.52 KB | dww |
Comments
Comment #1
dwwComment #2
dwwre-rolling now that #89538 and #89539 are committed.
Comment #3
dwwwhen i tried to install this on s.d.o, it gets weird with bluebeach. :( for example:
1) we need to patch bluebeach's template.php to include the table when rendering the project teasers
2) the zebra striping gets all fubar between projects and rows in the release table
3) projects that only have HEAD releases don't show up in the table
4) we should probably only include the table if there's more than 1 branch of releases
Comment #4
dwwalso, this calls filesize() a *LOT*. :( we should either add an argument to
project_release_table()so it leaves off the filesize column, or we should store that info in the DB, but this is generating *many* 100s of filesize() calls, which have to go touch the file system, etc, etc. yuck.Comment #5
dwwnew version with the following improvements:
project_release_table(). i think the args make a lot more sense now and the code is better, too. added a large doxygen comment to make everything more clear.the bluebeach woes are still present, namely: a) we have to modify
phptemplate_project_summary()to include the download table and b) we have to sort out the zebra striping conflicts between the projects themselves and the rows in the download tables. i know how to solve (a), but i'm not sure what to do about (b) just yet. :(Comment #6
dwwyay, unconed was around in IRC just now, and helped me get bluebeach fixed up for this. ;) still not totally ideal, but much better. for example, take a look at http://scratch.drupal.org/project/Modules/category/61 now. at the top, be sure to select [all] in the "Filter by Drupal Core compatibility" drop-down and press "go". then you'll see both the patch from #5 and steven's recent fixes in action.
Comment #7
dwwopen question: should we use a single-row download table for *all* of the existing "Download" links on these pages, even when filtering by a specific core version? it'd require a little more code-reorganization to avoid lots of extra queries, but it'd be quite possible. thoughts?
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedSeems to look good to me.
I think you should keep the filesize at least on the main project view page, even if it's off on the search all page.
The table-within-table does look kind of enh. I'm not sure what to do about it though. Maybe float the table to the right? I think part of the problem may be that it just doesn't line up with anything, so it seems like it's floating in the middle, awkwardly.
Naturally this gets me thinking about search module integration. Thanks to Gordon I have a rough idea of how to do that. (He wrote it for Views). But that's a completely other topic.
Otherwise I see nothing else that stands out at me.
Comment #9
dwwI think you should keep the filesize at least on the main project view page, even if it's off on the search all page..
doh! it's supposed to be there. i dunno what happened. ;) missing an arg somewhere, clearly. my bad. i'll fix that up later this afternoon and roll a new patch.
thanks for the review,
-d
Comment #10
dwwyup, i knew this was just something stupid. ;) behold: http://scratch.drupal.org/project/views
Comment #11
AjK CreditAttribution: AjK commentedsubscribing
Comment #12
dwwhearing no objections, i committed to DRUPAL-4-7--2 and installed this on d.o.
AjK: if you find anything suspicious when you finally review the diff, please re-open.
otherwise, i'll assume you're happy. ;)
thanks,
-derek
Comment #13
merlinofchaos CreditAttribution: merlinofchaos commentedI clicked through a little bit of the modules page, and adding this information to makes its absence on 5.x, 4.7.x, etc very conspicuous.
In thinking about it, I can't think of a really good reason to not just have the same table show up on all views, regardless of what the filter is.
Use the filter to reduce the resultset (i.e, exclude modules that aren't relevant for your version), but show all versions in all cases. The version number is useful, but it's also minorly useful to have the history. And certainly the code would probably be a touch simpler to just do it that way.
Comment #14
(not verified) CreditAttribution: commented