Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.After updating to alpha5, all my project release tables disappeared. After some time playing with the view SQL, I discovered that the problems what an over-constraint in the selection of the project_release_handler_relationship_supported_versions relation. It asks for major = 0 and tid=0. In my installation this means no data appears for any of the projects.
I did a hack to work around this, commenting the "extra" array in release/views/handlers/project_release_handler_relationship_supported_versions.inc. With this check gone, project releases appeared once more.
I'm reporting as a bug, but it may be I'm missing some database cleanup or something like that. I use postgresql and some times things don't work 100% on patches. Should I clear the supported release table?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 1347106-2_empty_releases_table.patch | 1 KB | matt2000 |
| #1 | 1347106_empty_releases_table.patch | 747 bytes | Carsten Müller |
Comments
Comment #1
Carsten Müller CreditAttribution: Carsten Müller commentedWe have the same problem. Here is a quick fix to solve the problem. Maybe someone can fix this issue correctly later.
Comment #2
matt2000 CreditAttribution: matt2000 commentedConfirmed, same issue on MySQL. Attached patch is the same effect as prior, but removes the code instead of just commenting it out.
Comment #4
matt2000 CreditAttribution: matt2000 commentedThats a broken test...
Comment #5
dwwI don't think this is the right fix. I believe that's going to make the table meaningless on sites like drupal.org where we actually have tid and major data, since you want separate rows in this table for each supported branch. If you don't include tid and major in the query, you're going to get bogus results.
I believe the reason y'all are having trouble is that your sites aren't configured to use the taxonomy crap, and possibly not using major version numbers, either. I'll be the first to admit that out of the box, project_release doesn't handle this well, and you have to do weird crap yourself to get it working. That's a big part of why this module is *still* (I know, we suck) in alpha, not beta nor 6.x-1.0. In particular, see #717538: Project releases module did not create a vocabulary called "Project release API compatibility and #885816: Notices in project_release if variable_get('project_release_api_vocabulary', '') is not set.
Making project_release more sane out of the box is a better fix for this than the proposed patch.
Comment #6
Carsten Müller CreditAttribution: Carsten Müller commentedOk, i agree, maybe a first step could be to improve the INSTALL.txt and the README.txt. There is no hint about the taxonomy. for the 7.x release i suggest that the taxonomy vocabularies will be installed out of the box during the installation process. In 7.x it become much more easier handling the taxonomy stuff.
Comment #7
dwwmatt2000 posted version_api_tid_views_relationship.patch over at #1542008: Download Tables are empty (version_api_tid views relationship fails) which I just marked as duplicate. Can the folks experience problems please give that a try and see if it helps. On first glance, that seems like a better approach.
Also, I'm pretty sure it's a totally separate bug, but #860758: Release download table views field fails to render in any circumstance is somewhat related, and I'm wondering if anyone in here is actually just hitting that, instead.
Comment #8
drummComment #9
apadernoI am closing this issue, as Drupal 6 is no longer supported. Feel free to re-open it if the bug is still present in the Drupal 7 version of the module.