| Project: | Project |
| Version: | 6.x-1.x-dev |
| Component: | Views integration |
| Category: | task |
| Priority: | normal |
| Assigned: | dww |
| Status: | postponed |
| Issue tags: | 6.x-1.0 blocker |
Issue Summary
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.
Comments
#1
Those issues are mostly done. So, here's a work-in-progress view that sort of replaces the download table...
#2
Good 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?
#3
@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. ;)
#4
Related 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...
#5
I'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!
#6
$view->is_cacheable = FALSE;
I wonder if we could simply change this to TRUE?
#7
Started 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...
#8
The 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"
#9
Based 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.
#10
Split #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.
#11
Instead 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.