Refactor project module to use Views [meta issue]

see my comments in http://drupal.org/node/76725 (which apply here, too).

see http://drupal.org/node/76725#comment-142606, in particular.

Here's a very rough initial stab at views enabling project.module and project_release.module.

Right now the patch just adds the field definitions and a style plugin for displaying project overviews in a similar manner to how we display them now.

If it weren't for releases, this might be pretty close to finished. But I haven't figured out a good way to filter project nodes by whether there are any release nodes of a certain version associated with a given project. I'll take a crack at this when I get a chance, if someone doesn't beat me to it.

There are some translatable strings inside this patch like t('The project\'s homepage.'). This is not correct and should be fixed. It should look like t("The project's homepage.") if you have a single quote inside a translatable string. thx,

@hass: You are more than welcome to reroll the patch.

I've re-rolled the patch with the backslash-single quotes removed from the strings that hass mentioned above.

Reroll to remove offset and fuzz. I think this also still needs work, so setting status back to CNW.

My understanding is that this is postponed for now and will be done as part of the port of the project module for Drupal 6. See http://groups.drupal.org/node/9500 for more information.

Changing title so that when this issue is linked in other issues it's obvious which module this is for.

Gabor posted a Views2 patch at #157694-48: Upgrade project module to 6.x based on aclight's efforts over the last year. It's not really the file layout that we wanted, and none of the views style plugin theme template files were working. I fixed all that and committed to HEAD: http://drupal.org/cvs?commit=164356

There's still a lot of work to do in here, but at least everything's in CVS now, has a sane directory structure, and I've given an initial review of the important parts.

The project browsing views are still currently broken. So much so that we wrote project_solr for the faceted search for project browsing on the new site. So, this is still active to get the default views working (I just got a pointer from aclight on some of the problems), but this is no longer in the critical path for the d.o upgrade.

I took a look at my local site that I stopped updating when I stopped working on the project* port last summer. This was just before the big Views 2 API change that required each handler to be in a separate file, etc. I then compared the SQL queries generated by views for the project browsing page to a new site that's running project* HEAD and Views 2 HEAD (or close to it). I see the reason that the browsing is broken, but I'm not sure what the underlying cause is.

Here's what I'm doing:
On both sites going to project/modules (this is handled by the "project_overview" view). My exposed filter settings are as follows:
API version: Any
Keywords:
Category: Developer
Sorty by: Name

For the record, the tid for the term "modules" is 3 and for the term "Developer" is 14.

First of all, here is the SQL query that Views creates on my old site (not updated for several months). The results on this site are what I expect: I get three projects returned, each of which is a module with the "Developer" term.

Now here's the result when I do the same on the new site running HEAD everything:

Clearly the problem is that in the later case there is only one left join for the terms, not two as in the case above. If I query the database using a slightly modified query directly, I get the proper project nodes returned:

I'm not sure if you changed any of the handlers (other than splitting them into separate files) before you committed them to CVS or not. I looked at a few of the likely candidates for the problem and didn't see any major changes but didn't go through line by line. I'm going to ping merlinofchaos and ask him to take a look at this comment and let us know if he recognizes where the problem might be (either views or our handler).

Though the attached patch doesn't fix the problem I describe in #13, it does clean up the code in a few minor ways.

I think the reason these handlers aren't working right is (if you can believe it) not the fault of my handler. Instead, I think it's a change that got made in views sometime between when this last worked for me and now. I have filed an issue about this in the views queue. See #371219: Incorrect logic in views_many_to_one_helper::ensure_my_table() for more information.

This appears to be the last issue on the Project* roadmap for D6 that needs to be fixed. Is this the last issue that's required before 6.x-1.0 releases can be made for Project and Project Issue?

One of the last, yes. However, I refuse to ship project* 6.x-1.0 without a views 6.x-2.4 official release to depend on. I keep getting "bugs" that are really support requests since project* depends on features in views that aren't in 6.x-2.3 but are committed to HEAD.

We should probably go through and make a list of issues to be resolved before a 6.x-1.0 official release in the various project* issue queues.

Makes sense. I provided a little more information on #371219: Incorrect logic in views_many_to_one_helper::ensure_my_table() which will hopefully get fixed and make it into Views 6.x-2.4.

Tagged this issue with requires-views-6.x-2.4 -- if that's helpful, you can send me a list of other issues that should be tagged the same and I'll update them.

Excellent, thanks! I see Earl committed #371219: Incorrect logic in views_many_to_one_helper::ensure_my_table() yay. ;)

I'll have to see if there are any others that need views 6.x-2.4 and tag them -- good idea.

Tagging for #439958: Document issues left before 6.x official release

When I try to patch it it show this message:

And it doesn't patch it, does anyone know how I can fix this so the patch works.

I got the patches not to show the previous error by fixing the Index line, but for some reason it doesn't apply the patch to most of the files, instead it creates a .rej file for each one of the files it doesn't apply it to; the only file that gets not even patched but created is project_views.inc (which is not in the original module).

@jfha73: When patch finds conflicts, it typically will apply the patch still to a file, but it indicates a conflict within that file. It then also creates .rej and .orig files that contain the original contents of the file and any rejected parts of the patch that it couldn't figure out where to put them.

Since it's been a while since this patch was created, and the project module has changed quite a bit since the patch was rolled, it wouldn't surprise me if it doesn't apply without conflicts.

I just found something very interesting (in my case) when I uncheck the DISTINCT option of the project types view, it works, so I guess the whole work has to be done to the SQL in the view, I know that MySQL 5.1 running on windows (my case) has problems with DISTINCT but I don't know if it's the same for all platforms.

I hope that helps.

By the way, I'm using it with Views 6.x-2.5

sub

Views 6.x-2.5 is out which is greater than the verson you requested ddw!

Subscribing

Have you found any solution for project browsing?

I just split #584026: Provide separate project browsing views from project_release with release-aware features out into a separate issue.

Generally, Project* views integration 6.x-1.0 blockers is the list of stuff to work on for this.

However, to be more specific, here are the key tasks for fixing project + project_release views integration before 6.x-1.0 can be shipped:

#357925: Provide default project browsing views that don't depend on project_release
#584026: Provide separate project browsing views from project_release with release-aware features
#539682: Replace hard-coded release download table with a view
#358563: Breadcrumb broken for node/N/release view

subscribe