Projects that have no releases are considered published but are not listed on the project overview/browsing pages. However, on the "browse by category" page, it appears that every project, whether it has releases or not, is included in the count for each category term. So, in the case where a category has only one or a few projects associated with it, but some/all of those projects have no releases, the Category(#) display may be misleading, and if a category has no projects with releases associated with it the user can click on that category but essentially nothing happens.
As for fixing this, I see 2 options:
1. Don't count projects in the terms count if they have no releases.
2. Display projects with no releases in the list of available projects.
I know that a similar issue with regards to publishing/unpublishing nodes based on releases has been opened (http://drupal.org/node/64100) but as far as I can tell the project nodes with no releases are published, they just aren't displayed on any of the browsing pages.
AC
Comments
Comment #1
dwwGood point. I'm torn about this.
a) I absolutely hate the project browsing code. :( This cries out, "Please, dear god, turn me into project_views.inc and rip me out completely". Unfortunately, views.module on d.o will probably be a long time from coming, so this isn't a short-term solution.
b) For d.o, it makes sense to not display projects in the browsing pages that have no releases. However, for non-d.o uses of project*, this doesn't always make sense. So, I think the best course of action would be an admin setting about it.
c) Certainly what you describe is a bug. The query to generate the count totals is different from the one to generate the actual list, which has been the source of many bugs. But, it's not clear we could unify them. That said, we should definitely fix something here.
Therefore, I'm not sure where to go. (a) speaks to "don't spend another friggin' minute on this, just make it views-enabled and cut and run. But, that won't work for d.o for a while, so it's not really a valid solution just yet. (b) is going to complicate (c) (and vice versa).
/me throws up hands in despair.
Comment #2
aclight commentedI'm not exactly excited about turning this into project_views, since that's more work than I have to do at the moment. Furthermore, if it won't work on d.o for any time soon, that would be yet another patch to project* that I would have to keep track of since it wouldn't be committed :)
I agree with having an admin setting for whether or not to display projects with no releases. I will look into adding this setting as well as the queries that are used to get the # of projects to display on the browse by category pages.
Would you consider these two things 1 issue? I think I would, since my guess is that the fix for part c (the incorrect count) will be, in part, controlled by the setting for part b (should projects without releases show up or not).
AC
Comment #3
dwwYes, (b) and (c) can be solved in 1 issue, and done together in a single patch. That's fine with me. Of course, I wasn't really suggesting you should implement (a) yourself. ;) It's just a wider point about time wasted on issues like this because we can't move to views (yet). Maybe once the dust settles on D6 a little bit, I can talk to Dries about this more.
Comment #4
hunmonk commentedwell praise you relevant supreme being, because views has been approved for drupal.org :)
the conversion will begin in 5.x-2.x, as outlined at http://groups.drupal.org/node/6180
postponing until we get that far.
Comment #5
aclight commentedAs a reminder, when/if this gets fixed, we should reflect that change in the Project documentation page (http://drupal.org/node/116527) and the Project* FAQ (http://drupal.org/node/193635#project_item1)
Comment #6
aclight commentedMarked http://drupal.org/node/23956 as a duplicate of this issue, even though it technically came first.
Comment #7
rcross commentedany progress on an administrative setting to force the display of a project without any releases? It would seem like this would also help d.o since the documentation and website type projects/issue-queues would then be more visible on d.o
Comment #8
aclight commented@rcross: If only it were that simple :)
If you haven't looked, fixing this problem is quite difficult (or at least I found it to be) because it would require large rewrites of the query generating code. That's not going to happen for project 5.x. Project 6.x will require views, and therefore fixing this should be pretty easy--probably it will involve just removing a filter from the default view that the project module creates.
So, no, progress has not been made on fixing this for 5.x. It's just too much work and not enough reward. And likely would introduce more bugs in code that is already fairly bug prone.
Comment #9
rcross commented@aclight - fair enough.
I would hope that there could just be a option within each project (instead of a unilateral option, or maybe in addition to one)
Comment #10
aclight commented@rcross: We might be willing to accept a patch for 5.x that did that, but as I mentioned before this is not something that's easy to do. The site I run project on also suffers from this problem, and so I've spent a fair amount of time trying to figure out how to fix the problem. I'm sure it could be fixed by doing multiple queries or something like that, but a patch that added even more queries is unlikely to be committed, and I don't want to have to run a heavily patched version of the module on my site.
As is, you can either get all projects but without any release information on those projects on the overview (eg. if you have not enabled the project_release module) or you can get the current behavior where projects without releases do not show up in the listings but are counted in the query that gets the number of projects in each category.
Comment #11
dwwNote: if/when we fix this, beware #235037: Critical errors in project_page_overview() query and logic -- we want to exclude projects that have no supported releases for a given version of core we're filtering on...