remove project_release dependency on taxonomy

thanks for the report. however, i've been trying for months to make project not require/depend on taxonomies, so i'd rather fix this by correctly wrapping the code in question with a check for if taxonomy.module is enabled or not.

since #163738 was marked as a dupe, i'll chime in here. i think the correct thing to do would be to commit the change to the .info file to fix the bug and then to change this to a task/feature request and removing the dependency.

the existing patch has the deprecated version tag so i'm reposting the patch i'd attached to #163738.

I just tried to test pretty thoroghly on a d.o testing profile site with taxonomy.module disabled. The only problems I could find are in project_release land. I agree, they're tricky, and I want to get a 5.x-1.0 release out ASAP (http://drupal.org/node/150278). So, I'd be willing to put the dependency in project_release.info and call it a task to untangle those dependencies in the future.

However, before I do that, can anyone confirm a page that blows up in either project or project_issue when taxonomy is disabled? I can't find it. Also, if you review the code, you'll see that the taxonomy_* calls are wrapped inside if (project_use_taxonomy()) checks, so the fact that they're there doesn't mean they're broken. ;)

disabled project_release and taxonomy, gave the project and project_issue modules a good workover, and couldn't find any problems.

Committed a change to project_release.info in HEAD to include a dependency on taxonomy. As far as I and hunmonk can tell, neither project nor project_issue depends on it. Setting this back to active for the longer-term task of making project_release not depend on taxonomy.

This is very low priority to me, so I'm postponing this for now.

Hi there,



I am struggling with the same problem -



______________________________________________________________________________
"user warning: Unknown table 'prsv' in where clause query: SELECT DISTINCT(n.nid), n.created, r.* FROM foundation_node n INNER JOIN foundation_project_release_nodes r ON r.nid = n.nid WHERE (r.pid = 17) AND (n.status = 1) AND r.rebuild = 1 AND prsv.snapshot = 1 ORDER BY r.version_major DESC, r.version_minor DESC, r.version_patch DESC, r.file_date DESC in /var/www/web125/html/foundation/includes/database.mysql.inc on line 172."

______________________________________________________________________________

I am pretty new to Drupal - and I am not 100% sure how to read your recommendations and how to apply this patch. Would you mind to help me a bit out?



It would be very appreciated.



Thanks
,
ORkan

*

@orkan: This is still a task, so please don't change the category to support request or the title. Also, I don't think your question has anything to do with this issue, so you should really create your own bug report with the information you gave above.

When you do so, please provide some additional information:
1. What page/URL are you getting this error message on?
2. What version of the project module do you have installed?
3. Have you enabled the project releases module?
4. Do you have the core taxonomy module enabled?
5. What version of drupal core are you using?

It's still a little early in the morning and my brain is still warming up :) I'm sure some of these questions would have obvious answers if I spent a few minutes looking through the code itself, but that'll only happen after breakfast. In general, when you file a bug report, please provide as much information as you can so it's easier to track down the bug.

For the record, there is a related, though IMO not duplicate, issue at #231614: Project release should handle case where api terms are not defined that deals with removing the reliance of the project_release module on having the API compatibility version terms present and configured.

I'd like to point out that removing dependancy to taxonomy is not a full solution to the problem.
If dww or other mantainers are going to make a check on taxonomy module being active in order to add functionalities to the project module, such as categorized projects and Project Release API Compatibility (i still haven't figured out what that vocabulary is for and how to use it), i suggest you to consider the option to completely disable those two functionalities, upon user request.

I am currently running a site with D5.7 and project 1.2, and I also make use of taxonomy.
Since the introduction of the categorization, i haven't been able to fully understand the concepts behind this module. Sure, project categorization is a great thing, and i know it would come handy to admins of sites with a large number of project, but i think you should consider making this module more flexible, since some users that may want to release a single piece of software or two, could find all this forced configuration and relative functionalities useless and quite confusing.