Subtask of #76726: Refactor project module to use Views [meta issue]: We should kill the hard-coded release download table and replace it with a view.
Depends on:
#539282: Denormalize release info a bit and store latest and recommended releases in {project_release_supported_versions}
#539668: Expose files attached to releases to views
#539676: Expose {project_release_supported_versions} data to views
Once those are done, it should be relatively easy to create a view of release nodes, with a project argument, and some filters from {project_release_supported_versions}. Might be so cheap we don't even have to keep caching it, but we could also keep {cache_project_release} and just use that to cache rendered copies of this view.
This will provide a lot more flexibility (both for the d.o redesign, and for other sites using project*), and will allow us to remove a bunch of ugly code.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 539682-7.download_table_view.patch | 21.48 KB | dww |
| #7 | 539682-7.download_table_view.png | 61.03 KB | dww |
| #4 | 539682-4.view_of_projects_with_release_table.png | 34.93 KB | dww |
| #4 | 539682-4.view_of_projects_with_release_table.view_.txt | 4.3 KB | dww |
| #1 | 539682-1.download_table.view_.php_.txt | 10.01 KB | dww |
Comments
Comment #1
dwwThose issues are mostly done. So, here's a work-in-progress view that sort of replaces the download table...
Comment #2
aclight commentedGood work on this. One question--I must have missed something, since I didn't know it was possible to have multiple files for a given release. Is this something new or are you using custom code for a site you're building?
Comment #3
dww@aclight: See #179471-12: release file attachments should use drupal upload functionality, #357920: Numerous errors when previewing/submitting a new release node and #366448: Port packaging script to new {project_release_file} schema -- Chad and I added most of the plumbing for this during the d.o upgrade sprint in Boston at the beginning of the year. This issue is finally putting a sink in with some of that plumbing. ;)
Comment #4
dwwRelated effort. Here's the beginnings of a single view that lets you browse projects and see the recommended releases and file downloads for each one...
Comment #5
dwwI've committed everything this was blocked on, so this is viable again. However, I don't really have time to keep going on this right now. If anyone wants to pick this up from the views I posted above, please do!
Comment #6
gerhard killesreiter commented$view->is_cacheable = FALSE;
I wonder if we could simply change this to TRUE?
Comment #7
dwwStarted working on this again since it has implications for packaged install profiles. Here's the latest iteration:
http://d6.project.drupal.org/project/views
The attached patch doesn't actually rip out all the old crufty code, it just provides the new view based on recent enhancements to project_release views support. Still working out some of the details on the UI, but it's getting a lot closer.
Part of the point of the change is to save color/icon/text inside the table for the download tables for packaged release nodes, so we can mark stuff out of date or insecure. By splitting recommended vs. supported vs. -dev into separate tables, we don't need to use color/icon/text for the status of each row in the table...
Comment #8
dwwThe date field displayed in here should be from the file timestamp, not the node changed time, e.g. for -dev snapshots. e.g. this is wrong:
http://d6.project.drupal.org/project/cckdatetest
http://d6.project.drupal.org/node/337981 was just rebuilt last night, but the date in the table still shows "2008-Nov-23"
Comment #9
dwwBased on lots of great UI discussions w/ Bojhan and yoroy, committed most of this to HEAD:
http://drupal.org/cvs?commit=295622
#8 is still wrong, so leaving this as 'needs work', but we're a lot closer...
Also, this patch does not yet rip out any of the crufty non-views code, since that's still being used for the project browsing pages in project_solr. Cleaning up all of this is a 6.x-1.0 blocker, but not urgent for the packaged install profile deployment.
Comment #10
dwwSplit #8 out into a separate issue: #647426: Date in the project download tables is when the release node was edited, not file timestamp so it's more visible.
Setting this back to active for cleaning up all the cruft from the old download table code.
Comment #11
dwwInstead of calling it duplicate, I just converted #682040: Project browsing pages doesn't use download table views, but old hard-coded download tables into a subtask of this to fix what I pointed out in #9:
So, let's use #682040 to make sure we use the download table views in the project browsing (or rip out the direct download links entirely, as per the d.o redesign), and then we can come back here to finally rip all the stale code out.
Comment #12
hass commentedI see these nice screenshots in #7, but cannot get this working at all and only get #1672724: Unknown column 'project_release_nodes.tid. Can someone take a look and share a hint? I tried finding the root cause, but it looks not that easy. Maybe one of you has a quick idea?
Comment #13
dww@hass: D6 or D7? Are you working on project nodes or project browsing pages? Not sure what's going wrong since I'm not sure what you're trying.
Thanks,
-Derek
Comment #14
hass commentedI'm still stuck at D5, but I fixed all the open upgrade bugs I've found and posted the D6 patches in the project queue. They are CNR... Hope you find some time to get them committed to D6!?
The issue #1672724: Unknown column 'project_release_nodes.tid is about D6. It's about project nodes (project/foo) where the download table is normally shown, but currently the table visible in your #7 screenshots is not visible at all, but many errors are shown since the mentioned column .tid does not exists in the database table.
This one is not visible:

I tried to find the tid reference in this views, but failed. There are two views marked as "broken", but I cannot find the cases where this issues are discussed.
Comment #15
hass commentedIt's view
project_release_download_tablethat is broken.Comment #16
hass commentedThere is something really weird in this view. The INNER JOINS are broken.
Defect:
Here are single quotes added to
'project_release_nodes.version_major'and'project_release_nodes.version_api_tid'andproject_release_nodes.tidneed to beproject_release_nodes.version_api_tidCorrect:
I just executed this manually in mysql and now I get the proper resultset.
Heck... debugging this view is really a heavy task.
Comment #17
hass commented@dww:
'raw' => TRUE,is not a documented feature of views joins. I understand that we really need this here. I guess you are running any custom views patch? Can you share a link to this patch, please?[project_release_handler_relationship_supported_versions.inc]Comment #18
hass commented#1433516: Provide a way to add raw extra join conditions has no patch.
Comment #19
hass commentedDamn,
RAWis fixed in views DEV. Several hours lost with debugging.Comment #20
hass commented@dww: Could you help commit #1672724: Unknown column 'project_release_nodes.tid, please?
Comment #21
drummThis was fixed in 7.x. I suspect it isn't worth changing in 6.x.