Where is 'Add item for Vocabulary?'

Doesn't exist yet in D7, sorry. I'm still getting my head around the API changes.

hi there i'm also interested by this feature;
this post is a year old, are there any improvements?

The item is available in the latest version however it's inactive. Is there a way to activate it?

I just found out this incredible modue existed, and I really would need this option. What is the progress of it? Great module!

I've been working on this issue and it's most of the way there. The last remaining problem (that I know about) is that D7 removed the means to display multiple taxonomy terms using the old "taxonomy/term/tid tid ..." path and won't display the menu item if its path is invalid.

So...what path should it use? I really want to avoid having the module provide a view (and thus be dependent upon Views) to support that functionality but so far I don't see another way.

Suggestions?

After discussions with dstol, the current plan is to include the view that provides this functionality but to set up the whole thing as a submodule. The submodule will be dependent upon Views, but if a particular site doesn't need to include a link to the vocabulary they wont have to enable the module and can thus not use Views if they choose.

As always, patches are welcome.

Alright. Try on the attached patch (rolled against the 7.x-1.x branch in git). It adds a new submodule with a dependency upon Views and adds a view to provide the missing functionality. It needs some clean up and documentation before it's ready for release, but all the tests are passing and it works as expected.

I have a few nitpicks. I'll reroll soon.

After some more review, I'm thinking the submodule should also include the options for "Display descendents" and "Use 'all' at the end of URL", since they'll need the same view. Thoughts?

+1

Here's patch version 2.

This one moves the "Display descendents" and "Use 'all' at the end of URL" functionality into the submodule and changes the name and location of the submodule.

Paths are not rewritten when the module is disabled, so if you enable it and create multiterm paths then disable the module the created paths will no longer be valid and the links won't be displayed.

Tests are still needed.

Switching status back to 'Needs Work' until we've got some tests in place.

Getting closer. Tests are in place for all but the Display Descendants feature. The feature is working but for some reason the test fails to fetch an mlid for the parent term. I'd appreciate input.

in regards to #7

Ultimately, this is the problem. Perhaps users could create pages with the same name as the vocabulary, point the vocabulary name to those pages, but have the module disable the link?

This is currently the pseudo work-around (minus disabling the link). For example, I have a vocab. called Services containing 6 items (a, b, c and x, y, z). I want to split those 6 items into 2 separate vocabs called Print (containing a, b, c) and Web (containing x, y, z). I created 2 pages, one called Web and one called Print. I then nest the vocabulary taxonomy menus under their respected pages, and the 2 pages are nested under a page called Services. This way, on the Services page, you see 2 menu items Web and Print. Those menu items link to the pages that when visited, display their respected taxonomy menu.

Services
-Web
--a
--b
--c
-Print
--x
--y
--z

The problem becomes that the when you visit the vocabulary pages, their respected menu jumps to the top. So when you are on page "Print", the print menu jumps on top of the web menu. Imagine how confusing this would be to a user, especially with more vocabularies.

The vocabulary title linking to a page is also very redundant. I believe this is why the problem exists. I believe people just want some sort of simple separation between menu items that still utilize active trails. If the vocabulary title could just be text, there would be no issue.

I'm in an "F' it Ship it", place. I haven't been able to get the test I referenced above working (though the functionality it supposedly test does work), so for now I've commented out the test. If someone feels strongly about needing the test and can write it, then great. Otherwise, let's get this blasted thing out the door.

Re-roll of patch from #20.

to the tune of Rawhide..

rollin', rollin', rollin'
keep f**kin' re-rollin' that patch

Alright, I don't know what the problem is. I applied the patch locally on 7.x-1.x and the tests all pass.

#24: issue1034310-add_vocabulary-v6.patch queued for re-testing.

+++ b/taxonomy_menu.database.incundefined
@@ -139,7 +139,7 @@ function _taxonomy_menu_get_terms($vid) {
-  return $result->fetchAll();

Are we sure it won't break anything ? I think we should patch/review/commit that separetely.

+++ b/taxonomy_menu.moduleundefined
@@ -813,7 +813,8 @@ function _taxonomy_menu_create_item($args = array(), $node) {
-    $item = array(
+dsm($vocab);

Let's not forget to remove the dsm, there are a few others I think. Plus the code code formatting.

Also I think we definitely need working tests for this. Maybe even test the patch against the latest tests from 2.x

Are we sure it won't break anything ? I think we should patch/review/commit that separetely.

I can tell you the taxonomy_menu (and submodule) tests, and those of Drupal core, pass after the change is made and that the observed behavior of the module is as expected. Beyond that...no, I'm not sure. Do you have suggestions for how to further verify it won't break anything? I'm not averse to committing and reviewing it independently, but the other code in this module will not work until that function's output is corrected.

Let's not forget to remove the dsm

In my grep of the code base after the patch is applied, there are no references to dsm beyond those in the patch. If memory serves I committed them inadvertently at one point and subsequently removed them. Are you finding dsm in the resulting code?

Plus the code code formatting.

My run of coder-review isn't flagging significant style issues in the affected code. The criticals found in the taxonomy_menu.module are addressed in the code, as the comments above the relevant lines explain. The couple complains of "Use an indent of 2 spaces..." I believe are justified deviations from the standard which enhance readability. The complaints about vocabulary_entry are outside the scope of this patch.

[Edit: I was mistaken about vocabulary_entry. The new taxonomy_menu_multiterm module was previously knows as vocabulary_entry, but those old references should have been cleaned up when I moved it. I'll have to look into that.]
[Edit2:The vocabulary_entry files aren't in the repo and existed only in my local environment.]

$ drush coder-review minor comment security sql style taxonomy_menu
Severity minor, Drupal Commenting Standards, Drupal Security Checks, Drupal SQL Standards, Drupal Coding Standards

sites/all/modules/taxonomy_menu/taxonomy_menu.module:
 +50: [minor] Use an indent of 2 spaces, with no tabs
 +194: [critical] Potential problem: drupal_set_message() only accepts filtered text, be sure to use check_plain(), filter_xss() or similar to ensure your $variable is fully sanitized.
 +241: [critical] Potential problem: drupal_set_message() only accepts filtered text, be sure to use check_plain(), filter_xss() or similar to ensure your $variable is fully sanitized.

sites/all/modules/taxonomy_menu/vocabulary_entry/vocabulary_entry.views.inc:
 +29: [minor] There should be no trailing spaces
 +99: [minor] There should be no trailing spaces
 +102: [minor] There should be no trailing spaces

sites/all/modules/taxonomy_menu/modules/taxonomy_menu_multiterm/taxonomy_menu_multiterm.test:
 +174: [minor] indent secondary line of comment one space 

sites/all/modules/taxonomy_menu/modules/taxonomy_menu_multiterm/taxonomy_menu_multiterm.views.inc:
 No Problems Found

sites/all/modules/taxonomy_menu/taxonomy_menu.batch.inc:
 No Problems Found

sites/all/modules/taxonomy_menu/taxonomy_menu.database.inc:
 No Problems Found

sites/all/modules/taxonomy_menu/taxonomy_menu.install:
 No Problems Found

sites/all/modules/taxonomy_menu/taxonomy_menu.test:
 No Problems Found

Status Messages:
 Coder found 1 projects, 8 files, 2 critical warnings, 5 minor warnings, 0 warnings were flagged to be ignored

Also I think we definitely need working tests for this

Tests verifying the functionality for Add Item for Vocabulary, adding the description for the vocabulary, and adding an alias for the vocabulary are all working. The test for including the descendants in the path is currently failing (and thus commented out in the code). As I said in comment 16, I'd appreciate any input on how to get that test up to speed. The observed behavior is that the functionality being tested does, in fact, work.

I only reviewed the patch with Dreditor, now I must say haven't applied the patch, I was just giving a quick feedback. I'll try to find time to investigate the tests this week.

For the fetch change, I think we can commit it very quickly, creating a separate issue and review/test the patch. This would surely happen before this patch is completely ready, if we need to fix the tests. This would be also better to keep track of that particular change.

Barett, I could ported your patch to 7.x-2.x and make it work, which is great. I also created some tests for vocabulary entry. But I'm still not sure about a few things:
- Do we really need to embed a view ? I mean, it's up to the user to decide how he wants to register the path of the vocabulary item page. For example, he could just decide to go with the default taxonomy term page provided by views and tweak it to make it happen, a bit like the view we provide atm in this patch. I think maybe a warning or a requirement that the user must have the path taxonomy/term/tid1+tid2+tid3... registered somewhere should be enough.
- Because vocabulary entry is now a sub-module, i think we can get rid of the voc_item option. If the module is enabled, provide the feature, else don't. I don't think we need this option anymore, we could just test if vocabulary_entry is enabled and proceed from there.
What do you think ?

Do we really need to embed a view ?

I'm ambivalent. I agree that we don't want to prevent someone from implementing the term handling a different way, but I do think there's value in the module providing some handling "out of the box."

Because vocabulary entry is now a sub-module, i think we can get rid of the voc_item option

See commit babddb8db9 (Patch 6 of 16) in the last patch file. The submodule was initially just for the vocabulary entry option, but expanded to include all the "multiterm" options like Display Descendants, since they rely on the same functionality, and was renamed to reflect that change in scope. So I think the option to enable/disable the vocabulary entry independently is necessary.

I see what you mean... Currently, I have 2 submodules in my port of your patch, which are "Vocabulary Entry" and "Multiterm". I've done that because in my mind, a user may want to display descendants but not a vocabulary entry. So basically, "multiterm" is required by "vocabulary entry" but not the contrary. "Multiterm" module would have the options like "display descendants" or "all at the end of path" but not "Vocabulary entry", which is why I wondered about "voc_item" option...

Hey Barett, FYI, I've added multiple terms paths to taxonomy menu 7.x-2.x, but not the view or the "Vocabulary entry" feature. This would be a base to add the feature later when we're ready.

I can confirm that the patch at #24 works; I am getting the vocabulary entry in the menu as designed (i don't need multi-term so i didn't test that). The failing tests does not impact function, although it would be nice to have the tests path. I may be able to throw some time at contributing tests over the holiday. In any case, nice work.

7.x-2.x branch now has a function that can check whether a path has been registered or not. A Taxonomy Menu can't be created or updated if the path does not exist. With good documentation and validation messages, I think we can skip including a default view in this feature.

I've been working on this a little bit and already have things working. It just needs polishing and tests. Assigning to myself so you guys know that it is on his way - 1-2 days before a new patch against 7.x-2.x.

Sorry guys, could not make it. I'll work on this again in a week or so.

I also need this particular function. The "Add Item for Vocabulary" is an available option but sadly, its greyed out. I do not have any views going and path auto has everything taxonomy-related using site.com/[vocabulary name]/[term] as a path. Closest I can get is a menu displaying the terms but not with a hierarchy of:

Vocabulary Term
Term
Term

Vocabulary Term
Term
Term

Is there an expected update to this module in the next month which might fix this?

I have a taxonomy vocab = 'Products'
This includes terms: Term 1, Term 2, Term 3, Term 4

I have a a view at /products (view = 'Products').

I use a custom view and a taxonomy view to list the products. This way, when at the URL:

/products (all products are listed - uses view = 'Products')
/products/term (uses built in taxonomy view - just enabled it and changed the look to match 'Products' view page)

Both views use the same grid so its seamless to list all products or products by taxonomy term. So this of course needs to be linked together.

Common sense would say to me there a menu like this:

Show all | Term 1 | Term 2 | Term 3 | Term 4 etc...

This way a user can see everything or filter down the list and they also get a very nice URL. I am not a fan of using exposed filters as the generated URL is disgusting!

Of course, taxonomy menu will generate a nice list for me including Term 1,Term 2,Term 3,Term 4 but what about when a user wants to list all products again?

This would be where 'Add item for vocabulary' would come in! It's greyed out though.

I can see the problem though, where would this link? In my case, it would like to mysite.com/products (to my view) but how would you go about putting this into code. What if someone doesn't have a view at /vocab-name?

I guess instead of using:

Vocab name: Products
- Term 1
- Term 2
- Term 3
- Term 4

you could use:

Vocab name: Whatever
- Products
-- Term 1
-- Term 2
-- Term 3
-- Term 4

Just a thought.

Then just create one extra menu item and put it as root of tax. menu.

Hi, Also needing the vocabulary function "Shows the vocabulary name as the top level menu item of the taxonomy menu".
Because I want to add the vocabulary to the menu, and not all underneath terms.

For User experience to make a root-term so it becomes:
- vocabulary
----root term
-------term 1
-------term2
---------term 2a etc...

I do not think that is the best solution!

Greetings, Martijn

#42, thanks, that's what I did.

Hi, Off course could #42 help, but I do not think this is the best solution.
Please bring back the vocabulary function.
Greetings, Martijn

subscribe.

putting the vocab title as a top level menu item would help alot.

This issue needs a summary. Or at least a post with latest code.

I used the #42 solution, but the url seems not good. It has extra term in root item.

I agree with #46. Would love to see this in Taxonomy Menu.

Subscribe

#10: issue1034310.patch queued for re-testing.

Any progress on this? It seems to have been abandoned. Perhaps removing the deceptive disabled option from the module would be sufficient to avoid teasing others as if the capability is somehow possible to configure.

Hi,
I agree. This is still a very wanted feature, but may be this module is abandoned?
Greetings, Martijn

I tried to do this as #42 suggests, but all menu items fall out of place after each change in the taxonomy vocabulary. The option that "shows the vocabulary name as the top level menu item of the taxonomy menu" is a most wanted feature, I agree.

Thank you for your contributions.
Drupal 7 is no longer supported.
Closing this issue as outdated.