Project makes special use of a vocabulary, and so introduces problems when more than one vocabulary is assigned. See previous discussion in http://www.drupal.org/node/31264.

This roughed in patch follows what we do in the forum module: automatically create a new dedicated vocabulary if there is not one in place.

If there's agreement with the approach, I'll finish the patch off with e.g. needed updates, to make it work with existing project installs.

CommentFileSizeAuthor
#7 project-designated-vocabulary2.patch9.49 KBnedjo
project-designated-vocabulary.patch3.04 KBnedjo

Comments

dries’s picture

dries commented

I'm OK with this approach.

Did you try categorizing some projects using an alternative vocabulary? Does it work? It should. :-)

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Did you try categorizing some projects using an alternative vocabulary? Does it work?

Yes, designating the vocabulary like this frees us up to apply other vocabularies.

But I'm thinking we likely will want to make more specific use of the project dedicated vocabulary. The thing is that the categories we want are going to differ by the main project type. On drupal.org, "themes" will want a different set of categories from "modules". This is parallel to what firefox does: "extensions" are classified by "blogging", "bookmarks", etc., while "themes" have "animals", "compact" and so on, see https://addons.mozilla.org/extensions/?application=firefox and https://addons.mozilla.org/themes/?application=firefox. The way to do this is to follow forum for more than just the vocabulary. In forum we designate between the first-level terms in the forum vocabulary - called "containers" - and subsequent levels, called "forums". I'd like to code the same approach for project, borrowing from the custom taxonomy handling of forum.module.

This would also need some custom handling on the project form - likely, a two stage process where we first select project type, and then have a custom taxonomy node select showing only second-level options for the particular project type, e.g., when submitting a "module" the options are for module categories.

Thoughts? If there are no problems with the idea, I'll get coding a draft.

dries’s picture

dries commented

I think the idea is OK, although it might be doable as is. There are site maintainers that could fix up projects that are not categorized properly. Maybe it's worth using the folksonomy features to classifiy projects? How would that work. I'd rather not be restricted to one way of categorization. As such, I'm somewhat hesitant to solutions that limit our possibilities afterwards.

killes@www.drop.org’s picture

killes@www.drop.org commented

I'd love to try tagging with projects.

boris mann’s picture

boris mann commented

I think we need both. One "maintained" vocabulary (determined by the docs team), and then the free tagging. And of course, only the maintainers would have permission to edit this after the fact.

The big thing with both of these is a specialized display that actually does stuff with these terms.

killes@www.drop.org’s picture

killes@www.drop.org commented

two vocabs doesn't sound like a bad idea. For display of the tagging vocab we could use Ber's tagadelic.module.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new project-designated-vocabulary2.patch9.49 KB

Here's an updated patch.

A dedicated vocabulary is created for the project module. The first-level terms of this vocabulary become the project types (on drupal.org, modules, themes, etc.). Subsequent level terms are the categories used to classify each of these types. So modules might have, e.g., mail, xml, etc. as sub-terms of modules.

Besides automatic creation of this vocabulary, I haven't implemented any special handling for either admins or users. But I have added help text to the admin/settings/project and node/add/project pages.

This patch makes it possible to use other vocabularies with projects--but it also opens the way to browsing by category, customized for each project type.

I'd like to apply this soon, as it's the basis for other enhancements. Any issues before I do so?

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

One issue (already present, not raised by this patch) that I haven't figured out is how to update the menu local tasks when a first-level term is created/changed/deleted. Because the menus are cached, changes don't take. A workaround is to reset the menus using the menu module. But this is clearly awkward. Do we need to use a different 'type' setting for the menu items? Or we could, e.g., use a _taxonomy() hook call to reset menus when necessary (e.g., call menu_reset() if available). But this would reset all menus, not just the project ones.

Ideas?

moggy’s picture

moggy commented

is the type => MENU_DYNAMIC_ITEM of any use in this situation?

MENU_DYNAMIC_ITEM: Dynamic menu items change frequently, and so should not be stored in the database for administrative customization.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs review » Fixed

Applied. Since function _project_get_vid() will test for and use any existing vocabulary for projects_project node types, this should apply cleanly without an update script to existing installs, including drupal.org.

The main immediate difference visible to users will be that the select form element for submitting projects will now be multi-select.

The next step in implementing this change will be to create some second-level terms in the dedicated project vocabulary. These will appear in the multi-select, and, as soon as there are any second-level terms, help text will instruct users submitting or editing projects in how to categorize them.

moshe weitzman’s picture

moshe weitzman commented

Without looking at code, I wonder if you shouldn't be dymacically attaching menu items/local tasks and thus avoiding the taxonomy refresh problem. If thats not plausible, then your approach of flushing cache with hook_taxonomy() makes sense.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Thanks for the suggestions.

I wonder if you shouldn't be dymacically attaching menu items/local tasks and thus avoiding the taxonomy refresh problem.

I wasn't sure how to do this.

If thats not plausible, then your approach of flushing cache with hook_taxonomy() makes sense.

So this second option is what I did. In function project_taxonomy():


  elseif ($type == 'term' && $object->vid == _project_get_vid()) {
    menu_rebuild();
  }

Is there a better approach?

moshe weitzman’s picture

moshe weitzman commented

Is simple. Hook menu implementations have a switch on a variable $may_cache. For example:


function project_menu($may_cache) {
  if ($may_cache) {
    // declare some static $items. this block gets executed infrequently - after a menu rebuild
  }
  else {
    // declare some dynamic $items. is executed on every page view
  }
  return $items;
}

an example of this technique is seen in node_menu() in order to attach the edit tab on node views.

the docs for hook_menu() are not clear on this point.

Anonymous’s picture

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