If you try to browse by date without the project_releases.module you get the following error:
user warning: Table 'tablename_projects.project_release_nodes' doesn't exist query: SELECT COUNT(DISTINCT(n.nid)) FROM node n INNER JOIN node_revisions nr ON n.vid = nr.vid INNER JOIN project_projects p ON n.nid = p.nid LEFT JOIN term_node r ON n.nid = r.nid INNER JOIN project_issue_projects pip ON n.nid = pip.nid INNER JOIN project_release_nodes prn ON n.nid = prn.nid WHERE n.status = 1 AND r.tid = 17 in /var/www/drupal-5/includes/database.mysql.inc on line 172.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | project_browse_by_release.patch | 2.76 KB | hunmonk |
| #9 | screenshot.jpg | 137.7 KB | ac |
| #3 | 239240_project_browse_by_release_3.patch | 3.79 KB | aclight |
Comments
Comment #1
acI see you can actually turn of this type of browsing in the admin so I imagine this is by design.
Comment #2
aclight commentedEven if you can turn off browse by date, I wouldn't call this by design. It also looks like this query will break without having the taxonomy module installed. There's a similar taxonomy related issue for the project releases module itself at #133052: remove project_release dependency on taxonomy.
Comment #3
aclight commentedIn project_page_overview(), there are several checks for the project_release_browse_versions variable. Unfortunately, if that variable is TRUE, but project releases is not enabled (which could be the case if it was enabled at some point but later disabled), project_page_overview() just goes along as if the project_release module was there, and I think that's what's causing stuff like what's reported here. I wasn't actually able to reproduce this database error, so I'm not certain which part of the function is the culprit, but it could be one of several places.
The attached patch adds in additional calls to module_exists() to make sure the project release module is enabled when the project_release_browse_versions variable is checked.
While testing this I also noticed that when browsing by date without the project release module installed, the Date values that are printed in h3 tags are bogus, because there is no timestamp pulled from the database if project releases isn't enabled. Though this is sort of a separate issue, it's just a small fix and I don't want to have too many issues about this one function because that makes keeping track of all of the patches more difficult.
I've tested this on MySQL and don't see any problems.
I don't know that we should spend a ton of time trying to fix this function with the port to views on the near horizon. But if someone wants to review/test this, that would be great.
Comment #4
acSuccessfully applied to 5--1-2 and fixes the original issue. I also get the bogus timestamp.
Comment #5
aclight commented@ac: You get the bogus timestamp before applying this patch but it is fixed by the patch, or you get a bogus timestamp even with this patch?
Comment #6
acNo timestamp prior to patch, bogus one after the patch.
Comment #7
aclight commentedThe patch will pull the timestamp from the changed time of the project node itself if project_releases isn't enabled. Are you seeing different behavior with the patch applied? If so, what timestamp is it getting?
Comment #8
acWith the patch applied I get one date, and it is UNIX epoch time. It then lists the projects in the correct order (according to 'sort by date') under that time . If a project that is not the most recent is edited, it becomes the most recent after editing (but still under the UNIX epoch date).
Comment #9
acComment #10
hunmonk commentedattached removes a couple of unnecessary hunks due to fixes in a previous patch, and uncomments the code that makes the date thing work correctly. tested with project_release disabled and enabled, works perfectly.
Comment #11
dwwReviewed, tested, and committed to HEAD and DRUPAL-5. Thanks, folks.
Comment #12
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.