project shouldn't require taxonomy

here's an even better version (IMHO) that adds a new site-wide project setting -- a checkbox to enable/disable project's taxonomy use, even if the taxonomy module is enabled. i'm setting up quite a few sites that are using project now, and none of them need the additional complexity and confusion of the currently-forced project taxonomy. i'd love to disable project's taxonomy, but i don't want to disable *all* taxonomy use on the system to do it.

i'm not sure if there's a better way to do this where most of the call sites just check variable_get('project_use_taxonomy'), and only allow that to be 1 if taxonomy is enabled *and* the user selected the checkbox, since i'm not sure when we can assume that setting has been initialized properly (in terms of the order various hooks are called, etc). if there's a better way to do this that doesn't require:

if (module_exist('taxonomy') && variable_get('project_use_taxonomy', 1)) {
...
}

at every call site, i'd be glad to hear it.

also, it'd be possible (though more work) to enable browsing by name and date, even if browsing by category is disabled. however, that's not very important to me, and seems like a lot of work for not much return, especially since sites that don't want categories probably just don't have many projects in the first place.

this patch is also a feature request, but it does fix a bug, too, so i'm leaving the category of this issue as "bug". when reviewing/commenting, please be sure to specify which patch you looked at and/or tested.

thanks!
-derek

good idea, nedjo. i'll roll a new patch with the condensed code.

new patch with project_use_taxonomy(). unfortunately, b/c the taxonomy code is so interwoven with everything else, once you disable taxonomy support in project via this patch, you loose the ability to browse by date. i started getting this working, but ran into a big mess in project_page_overview() and i don't have energy to deal with all of that right now. ;) this patch still fixes the original bug, and provides a reasonable set of functionality if you disable taxonomy integration. i think it should go in, and then we can work on the other stuff later.

oh yeah, the patch. ;) by the way, this fixes some bugs in the previous patch, e.g. the help text getting screwed up since i forgot to add a "break;" after a taxonomy-specific code block that returned.

good point, leafish_paul. while i was re-testing after the change, i also noticed one other spot we were sticking a taxonomy term in the breadcrumb even if taxonomy usage had been disabled. new (hopefully final) patch attached. ;)

dries, i'm not sure if you're talking about how it should work or how it does "work". ;)

aside from the bugs fixed by my first patch, the project module currently only checks if (module_exist('taxonomy')), and if so, it assumes there is a taxonomy, it automatically creates it for you on install, etc, etc. unless you add the setting (like my most recent patch), then the only way to prevent project from requiring this taxonomy is to turn off the taxonomy module entirely.

maybe you're saying that instead of the code for the new setting, the patch should change project_use_taxonomy() to see if there's a project-specific taxonomy defined, and if so use it. then, i should rip out the code that's automatically creating this taxonomy on install, and in its place, add more useful documentation about "if you enable a taxonomy for projects, then ... blah, blah... you can add this by going to administer - categories - ... blah blah". then, on install, project will not use a taxonomy, but if someone goes out of their way to add one, it will have all this funky built-in functionality to use it. is that what you have in mind? i could live with that.

The project vocabulary needs to be added programatically and not manually (via the taxonomy UI), because it needs to be assigned to the project module.

i don't know what "assigned to the project module" means. do you just mean it has the "Types" box checked for "project" when it's created, or is there more to it than that?

We could maybe do a test in project_use_taxonomy() to determine if any terms have been added to the vocabulary, and use taxonomy if so. We'd need to document this behaviour as it's not inutitive.

the problem with this (and my approach, for that matter) :( is that once project automatically creates this (required) taxonomy, you're stuck in a situation where you cannot add new projects until you populate some terms into the volcabulary. there's a required field (care of taxonomy_form_alter()) on the node creation form called "Projects" in the "Categories" fieldset that has no values. all attempts to use this form end in pain and suffering. ;) see http://drupal.org/node/49623 for more info (and a recently posted screenshot).

if you read http://drupal.org/node/64221, you'll see my ideas about splitting up this taxonomy, anyway. personally, i think this automatically-created taxonomy creates far more problems than it solves. seems like we should just let admins define their own taxonom(y|ies) for projects as they see fit. we can conditionally check for the existance of these taxonomies and programatically do interesting things with them in the code, but i don't think we should either require them, nor automatically create them.

so, nedjo, what am i missing? what does "assigned to project" mean other than making it clear that if admins want this fancy functionality, they have to be sure the click the box next to "projects" when they're selecting the node type the taxonomy is for?

thanks,
-derek

that link is an interesting read. thanks. however, i still don't fully understand everything going on here. ;) you mean that if we don't use this module field in the taxonomy table, then users can no longer define their own taxonomies that might also apply to project nodes? sorry if i'm being dense. taxonomies are not an area of drupal i've jumped into very deeply.

any thoughts on either http://drupal.org/node/64221 or http://drupal.org/node/49623? they're both related (though not really duplicate) of this issue, but i don't want to repeat myself. ;)

thanks,
-derek

please see http://drupal.org/node/64221#comment-101788. if implemented, those changes will mostly solve this problem, too. we'll still need something like my most recent patch, minus the new setting, and changing project_use_taxonomy() to query the db to see if there are any terms in the taxonomy. i think that'll do the trick. i'll try to re-roll my latest patch with these (relatively minor) changes, and get this ready to go...

ok, here's a new patch that takes in all the conditional taxonomy goodness from my most recent patch, but removes the new setting. project_use_taxonomy() now looks like this:

function project_use_taxonomy() {
  return module_exist('taxonomy') && taxonomy_get_tree(_project_get_vid());
}

i think this is good to go. until we fix http://drupal.org/node/64221 ("taxonomy select needs need"), we're still going to have the problems i describe in http://drupal.org/node/49623 ("better error messages when there are no terms in the Projects taxonomy") -- namely, this required taxonomy makes creating new projects impossible until you add terms to it. i was tempted to include this in the patch, too:

-      $edit = array('name' => t('Projects'), 'multiple' => 1, 'required' => 1, 'hierarchy' => 1, 'relations' => 0, 'module' => 'project', 'nodes' => array('project_project' => 1));
+      $edit = array('name' => t('Projects'), 'multiple' => 1, 'hierarchy' => 1, 'relations' => 0, 'module' => 'project', 'nodes' => array('project_project' => 1));

so that the auto-generated taxonomy isn't required. however, since i'm actively working on fixing the taxonomy selector for projects, i'm not going to worry about it too much in this patch...

comments? is this RTBC?

now that http://drupal.org/node/64221 has been committed, the old patch was a little bit stale, since it added a duplicate version of project_use_taxonomy(). new patch attached.

from IRC:

Dries_: dww, still using a global setting or not?
Derek: nope
Dries_: dww, cool
Derek: dries: it's all happy now: just based on existance of the taxonomy module and existance of terms in the auto-generated taxonomy
Dries_: dww, i'm ok with this patch -- it looks like a lot of work to make taxonomy optional though (not sure it is really worth it)
Derek: and now that http://drupal.org/node/64221 is committed, the project edit form doesn't include a taxonomy selector at all if the project taxonomy is empty.
Dries_: dww, when would you not want to use a vocabulary?
Druplicon: http://drupal.org/node/64221 => taxonomy selector needs work
Derek: dries: for example, on my band's site, that only has 1 project, for tracking issues with the website itself.
Derek: plus, taxonomy isn't a required module.
Derek: it's possible sites just turn that off.
Dries_: dww, k
Derek: there's already a bunch of code in project that tries to handle this case, but is currently broken.
Derek: the patch just makes all that existing code work, and catches a few other places that were assuming taxonomy is enabled
Dries_: dww, go ahead and commit it then

applied to HEAD and 4.7 (since none of the taxonomy stuff exists in 4.6, a backport is unnecessary).