With project 5.x-1.2, we intended to drop the {project_release_default_versions} table, though as I point out in #235035: {project_release_default_versions} table is not dropped in update 5200, that didn't actually happen. However, for sites with brand new project installations, this table won't exist.

So, in project_page_overview(), we get a db error when we JOIN on this table. See around line 781:

      $latest = db_fetch_object(db_query_range("SELECT file_path, version, file_date FROM {project_release_nodes} p INNER JOIN {node} n ON p.nid = n.nid 
INNER JOIN {term_node} t ON p.nid = t.nid LEFT JOIN {project_release_default_versions} prdv ON p.pid = prdv.nid AND prdv.tid = t.tid AND prdv.major = 
p.version_major WHERE p.pid = %d AND t.tid = %d AND n.status = 1 ORDER BY prdv.nid DESC, p.rebuild ASC, p.version_major ASC, p.version_minor DESC, 
p.version_patch DESC, p.file_date DESC", $project->nid, $version, 0, 1));

Note: I manually added line breaks above so that it wouldn't wrap beyond the border.

CommentFileSizeAuthor
#12 og-release-settings-6.x-HEAD.png176.44 KBdww
#10 235037_project_page_overview_10.patch2.16 KBdww
#4 235037_project_page_overview_4.patch2.2 KBaclight

Comments

aclight’s picture

aclight commented

As a note, this needs to get fixed at the same time as or before #235035: {project_release_default_versions} table is not dropped in update 5200 gets fixed, or otherwise users who already have the {project_release_default_versions} table and aren't currently getting db errors on the project overview page will start getting them.

aclight’s picture

aclight commented
Title: project_page_overview() refers to {project_release_default_versions} table which no longer exists » project_page_overview() should use {project_release_supported_versions}

After talking to salvis in IRC, I realized that part of what he was bringing up in #237839: Filtered project list shows unsupported releases was really related to this problem. Not only is this code using {project_release_default_versions}, it's not using {project_release_supported_versions}. This leads to some unintended consequences. For example, at the moment, the 6.x-1.x-dev release of the Subscriptions module (http://drupal.org/node/94792) is set as unsupported. This release is also the only release for the Subscriptions module for Drupal 6. However, if you go to http://drupal.org/project/Modules/category/66 and filter for Drupal 6.x, you'll find that the Subscriptions module shows up on that page, and that the "Download" link under the teaser points to the tarball of this unsupported release.

This is a bad idea, since there's no indication on this overview page that this release is not at all supported or recommended.

salvis’s picture

salvis
he/his
commented

Thanks for expanding my terse comments into a usable description!

aclight’s picture

aclight commented
Status: Active » Needs work
StatusFileSize
new 235037_project_page_overview_4.patch2.2 KB

This patch does the following:
1. Removes {project_release_default_versions} from the query in project_page_overview().
2. Adds a JOIN on {project_release_supported_versions}. I'm not sure I'm doing this quite right so that's why I'm setting this to CNW. But as is, the download link is not present on a node that has an unsupported release for the API version currently being filtered for, which is an improvement from what we have now. However, some might argue that a project should not show up at all in the listings if there is not a supported version for the API version being filtered by. I'm not 100% sure I agree with that but if that's the case then this patch isn't doing that yet.

salvis’s picture

salvis
he/his
commented

Yes, removing the download link is the main issue.

It may not necessarily be so, but the presence of a 6.x-1.x-dev version, even if it's unsupported, is at least a hint towards future availability of a D6 port, so I think displaying the module is not a big problem, as long as the user is forced to go to the module's front page and see the version table.

We might even argue that the download link should only be there if there's a recommended real release, but not for a -dev snapshot release, whether supported or not, so that users can't download a -dev tarball without seeing the red color.

aclight’s picture

aclight commented
Status: Needs work » Needs review

Setting to CNR.

moshe weitzman’s picture

moshe weitzman commented
Priority: Normal » Critical

I have people downloading unsupported HEAD release of OG because of this bug. I am moving to critical. Feel free to downgrade if thats not appropriate.

aclight’s picture

aclight commented
Title: project_page_overview() should use {project_release_supported_versions} » Critical errors in project_page_overview() query and logic

Changing title to be more descriptive of the overall problem and not the specific cause.

dww’s picture

dww
we/he/they
commented
Assigned: Unassigned » dww
Status: Needs review » Needs work

Sorry I've been AWOL from this issue queue for a while. Combo of too much work and some family health issues have taken all my attention.

Yes, this is broken, and sadly, I've known it for a while. I first pointed this out as part of the GHOP task that tried to add the {project_release_supported_versions} over at #176776-23: GHOP #55: Make release summary table UI look more like update(_status)? report. Unfortunately, I was so fed up with how that task turned out, that I lost track of this problem in my blitz to implement that code myself. :(

All that said (and yes, even though the D6 port and views stuff is relatively close at hand), this is broken in my testing. The reason is that the JOIN on {project_release_supported_versions} is wrong. We need to JOIN on both the project nid and the API compatibility term we're filtering on. Otherwise, you get bogus records that aren't what you intend.

I'm debugging and working on a new patch right now... stay tuned.

dww’s picture

dww
we/he/they
commented
Status: Needs work » Needs review
StatusFileSize
new 235037_project_page_overview_10.patch2.16 KB

Well, drat, #156049: counts on project "browse by category" can be misleading is maybe even more broken as a result of this patch, but I don't care enough to delay this any longer. This should do it. @aclight, care to test this at all before I commit and deploy?

aclight’s picture

aclight commented

@dww: I glanced at the code and don't see any problems off hand, but I won't have time to test until this weekend. Feel free to commit before then if you'd like.

For the D6 port, I'm considering whether or not we should drop displaying a download link on the project teaser on the project overview page. With the potential for multiple supported versions for a given API version, just displaying one download might oversimplify things to the point of confusion. In any case, the code to do this would be in an entirely different place, so the fact that this patch (and probably mine from above) includes a "1" directly in the query doesn't bother me. :)

dww’s picture

dww
we/he/they
commented
Status: Needs review » Fixed
StatusFileSize
new og-release-settings-6.x-HEAD.png176.44 KB

Committed to DRUPAL-5 and HEAD, and deployed on d.o.

@moshe: This still doesn't change the fact that if you filter the modules by 6.x and browse to OG, you still get a download link to og-HEAD.tar.gz. Why? Because your module settings claim "HEAD" is the supported/recommended version for 6.x. See attached screenshot. You probably want to change that. In fact, you probably want me to rename your HEAD release. See http://drupal.org/node/267852

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.