Basic considerations for latest version

GOOD!
With me is vice versa! I never was a real good programmer - I was partner in a software company for architecture and engineering software. But that is more than 18 years ago. My strong side was front side development and TESTING.
Now I´m into Natural Medicine - we have a praxis and I also give seminars. I´m setting up a community site for practitioners - that´s what brought me to drupal.

The only thing I'm a little worried about implementing is having a drop down list of views.

Me too. I made this suggestion to be a bit unperfect. I know that it won´t really work with your new concept of Hierarchy.

Some additional thoughts:

I) Could the vocabularies for each taxomomy menu be moveable up/down and! left/right like the ones in the core menu module? I´m not sure if this would make sense.

II) If a tax_menu gets changed by the core menu module - could your module be aware of that change and show at least a red warning sign? So people know that it is no longer in original condition.

III) What happens if a user moves terms within a vocab? I´ll test how your current version reacts on this.

One has to take into account that moving terms from one vocabulary to another will be possible in future. It is not yet possible - at least not with the modules I have installed (taxonomy manager) but I saw various feature request in this direction.

The problem is that people start Drupal sites without understanding the whole meaning and use of taxonomy. After a while they notice that their tax-terms and vocabularies are not well organized but can´t be changed easily because they have already a lot of content linked to the terms.

IV) Terms
a) The term "Vocabulary" is fix and defines a whole thread or bunch of taxonomy terms.
Is it correct to use the word also for a part of a vocabulary? Better to say "vocabulary and taxonomy terms"?
b) The term "Menu" is defined by the core menu module. What will be defined in my suggestion are menu-items - to call it menu could be confusing esp.for new drupal users. What term do you think could be used instead of? In German we have "Menü" for the whole and "Menüpunkt" ("Punkt" means point) or "Menüeintrag" for a single menu item.
In English there are the words "menu selection", "menu bar", "menu item" which don´t bring us further.
Instead of menu one could say "top-item for menu" "name for top-item: ....."

V) Before rebuilding a tax-menu the module could create a duplicate of the excisting one with the name "copy of ...." So in case the rebuilt is not what they want they could delete it and rename the copy version and activate it again.

VI) How Drupal reacts on double menu entries? I think it shows only one. For example: a view creates a menu "sport activities". If there is a taxonomy top-item with the same name within the same menu-structure only one will be shown. How to deal with that?
When activated, the module could check if the top-item-name is already used by other modules and give a warning (cancel/go ahead).

VII) Together with cck taxonomy field the new module would be perfect to create nice menu structures for all kind of node types - with perfect bread crumbs.

That´s so far.

My step son asked me to practice some mathematics with him: integral calculus.

Klaus

One more thing comes into my mind:
A better UI version for the function:
-> ADD / EDIT VOCABULARY

Vocabulary: ....
(dropdown list to select. Only Vocabulary names will be shown - not the terms within! Otherwise this select list could be very very long)

Parent item: ....
(The choosen vocabulary with all terms. User can choose the vocabulary as whole or just parts of it)
(Have a look at CCk content taxonomy field: add a taxonomy term to a content type and look what the options are and which select lists it present there - maybe that you could take a part of code into your module)

Depth of taxonomy tree: ........
By setting a numeric value, the depth of the hierarchy shown can be limited. Leave this field blank to show the whole hierarchy.

enable / disable: Create menu item for parent item

I was outside for a run - cleanse the head.

I'm adding you to a favorite list next time I need ideas for a new module ;)

There is already some major module in my mind - but I don´t tell you, otherwise you might not complete this one.

-> IV. Terms
I think that the word "menu" should only be used for the menus created by core menu module. Taxonomy menu creates "menu items" within menus.
I suggest:
"Menu item group" That is one bunch of vocabularies and/or terms charactered by a name, that can be the "top menu item" (optionally)
"Parent item" or "parent items" for the top items within a "menu item group".

-> V. Rebuild
With fresh air in my head I think a rebuild function will not be neccessary.

We have the following opposites:

build (create) - remove
enable - disable
add/edit - delete

Initially a "menu item group" is stored only locally within the module.

build or create: writes the structure into Drupals menu system, simultaneously it should get enabled.

disable: the menu structure stays as it is but its flag gets disabled (same as core menu function)
enabled: changes flag to enabled
(Warning: with this function your settings in core menu module will be overwritten)

remove: removes the "menu item group" with all subitems from the menu system, but still exists within the tax_menu.
(Warning: with this function your settings in core menu module will be overwritten)

delete: delete the "menu item group" completely.

(so rebuild = first remove then build again)

-> VI. I have done this too and strange things happened.
I´ll try it again.

OK!

Hi Neil, some short ideas to 6.x-3.0.

Functions:

GA: Add menu group
GE: Edit menu group
GD: Delete menu group (=+Remove group from menu)

VA: Add vocabulary
VE: Edit vocabulary
VD: Delete vocabulary

GWM: Write (or publish?) group to menu
GUM: Update changes to menu
GRM: Remove group from menu

(The last three functions could have three conditions:
highlighted (bold) = that should be the next step
normal (black) = is possible
inaktive (grey) = is not allowed)

Prompts:
PNW: "Group not written yet to menu"
PHA: "Group has to be actualized"
PWM: "Group has been written to menu"

Flags:
(I´m sure there are shorter words/phrases)

FVE: Vocabulary exists: true/false (number of vocabularies within group>=1)
(if false
"Write group to menu" not allowed
"Remove group from menu" not allowed
AND Prompt "Group not written yet")

FVC: Vocabulary changed: t/f
(If true: only changes have to be written to menu? or all?
AND Prompt "Group has to be actualized."
AND Highlight function : "Update changes to menu")

FOC: Options/parameters changed: t/f
(If true:
Prompt "Group has to be actualized."
AND Highlight function : "Update changes to menu")

FGM: Group has been written to menu: t/f
(if true
Prompt: "Group has been written to menu"
inactice function: Write group to menu)

(if false
inactive Function "Remove group from menu")

---------------
I could complete this truth or condition table if its helpful to you.

Klaus

About strictly hierarchical vocabularies:

Please read my comment on http://drupal.org/node/399380
(And support it, if it makes sense to you)

Thanks, Klaus

Hi Neil, very quite here at the moment.
Some more ideas for next version.

/Preamble:
We can differentiate the follwoing types of vocabularies.

UNSORTED (like interests, free tagging)
Most probably nothing to create a menu out of.

MIND-MAP TYPE (every term can have nodes linked to it)
Can be used for t-m (taxonomy menu or transcendental meditation)

STRICTLY HIERARCHICAL (only bottom terms can have nodes linked to it)
Unfortunately drupal has no module up to now, that allows users to select only bottom terms.
Ideal to use with t-m.

MIXED (one branch is umsorted or mind-map type another strictly hierarchical)

/Some examples
The following two vocabularies are given:

VOCABULARY 1
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
---- teRm 1.2.1.1
---- teRm 1.2.1.2
--- tErm 1.2.2
-- Term 1.3
- TERM 2
-- Term 2.1
-- Term 2.2
--- tErm 1.1.2
- TERM 3

Vocabulary 2
- Attribute 1
- Attribute 2
- Attribute 3

/Some examples for “menu item groups” that users might want to create:

Example A)
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
---- teRm 1.2.1.1
---- teRm 1.2.1.2
--- tErm 1.2.2
-- Term 1.3
That´s - I guess - the easiest part.

Example B)
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
--- tErm 1.2.2
-- Term 1.3

Like A) but lowest level should not be shown.
So we need the option to cut off the bottom ---- teRm 1.2.1.1 and ---- teRm 1.2.1.2 are not included.
My idea about “Display Depth in Custom Path:” basically was, that it limits the depth of the branch that is selected.

C) User wants to have:
VOCABULARY 1
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
---- teRm 1.2.1.1
---- teRm 1.2.1.2
--- tErm 1.2.2
-- Term 1.3
- TERM 3

So the branch TERM2 is missing.
Depending on the way to select Terms and branches (dropdown lists or checkboxes) one or two “vocabularies” within a “menu item group” are needed.

1) Select type “checkboxes”:
The whole vocabulary would need to be represented by a tree and checkboxes. Every Term or branch needed could be checked (this kind of selection content taxonomy module has as option).
Examples A), B), C) are easy to create (from users side). But what is with large vocabularies?
An option within this type of selection could be a function to show or hide a branch by clicking on the term.

2) Select type “drop down list with multiple select”:
More than one branch could be chosen with STRG+Click. Can be confusing and unmanageable for large vocabularies.
Examples A), C) are possible, for B) a function is needed, to hide the two bottom terms.

3) Select type “drop down list with single select”:
Only one branch could be selected.
Example A) is easy to select, for B) a function is needed, to hide the two bottom terms.
To create C) two “vocabularies” within a “menu item group” are needed.

Let´s look at other examples:

D)
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
---- Attribute 1
---- Attribute 2
---- Attribute 3
--- tErm 1.2.2

So we have a mixture of two vocabularies!
Actually a thing I would need to have for my site.

Whatever select type is programmed, more than one “vocabulary” within “menu item group” is needed – I guess three are needed
---------------------
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
--------------------
---- Attribute 1
---- Attribute 2
---- Attribute 3
--------------------
--- tErm 1.2.2

Question is: how to tell ---- Attribute 1 to be child of --- tErm 1.2.1 ?

E)
- TERM1
-- Term 1.1
-- Term 1.2
--- tErm 1.2.1
---- Attribute 1
---- Attribute 2
---- Attribute 3
--- tErm 1.2.2
---- Attribute 1
---- Attribute 2
---- Attribute 3

Uups. I need some time to understand what that means ……
That means a kind of filter is needed.
--- tErm 1.2.1
---- Attribute 1
Only nodes will be shown that are linked to both taxonomy terms, or to make things worse who are members or children of --- tErm 1.2.1 and members of ---- Attribute 1.

F) There are even worse examples possible.

----------------
Now I´m confused. Again this box of ….

….. Mom, do you allow me to put on a bikini this summer? ……No, Charles.

You can do cross vocabulary linking by using term relation. Normally relations are non-hierarchically. You can also link by the name of the term, Like using primary and secondary terms. If you have menu item in secondary that matches primary, then it's linked (or something like that).

I´m not quite sure if I understand what you are saying.

Let´s say we have

Size (Vocabulary)
- large
- small

Clothes (Vocabulary)
- Shirts
- Pullovers

and the menu is:
Clothes
- Shirts (term id=13)
- - large (term id = 48)
- - small
- Pullovers
- - large
- - small

In my example, we work with custom path.

If large is klicked the url path is: "category"/48
So how does view knows to show only large shirts and not larges pullovers?
I think this could only be done by "category"/13/48 - or is there another way?
How this is solved in the patch of http://drupal.org/node/269773 ?

One more for today:

My suggestion for UI. Some changes to first suggestions in this node
-------------------------------------------------------------------

| List menu group | Add menu group | Settings

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
| "menu group name" - display - edit - delete -
|
| - build menu link - update menu link - remove menu link -
|
| status: published /unpublished/needs to be updated
|
| requires view: path="category/%" argument: Term ID
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|"vocabulary name" - edit - delete -
|
| "vocabulary name" - edit - delete -
|
|- add vocabulary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Functions:
- display: shows the whole menu as check for users before they build the menu links.
- other functions and prompts are clear - or not?

---------------------------------------------------------------------------------

Let´s discuss the following example:

Given are two vocabularies

Clothes&Accessories (vocabulary)
- Clothes
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Children
- - - T-Shirts
- Accessories
- - Bags
- - Various

Properties (vocabulary)
- size
- - woman
- - - xs
- - - s
- - - m
- - men
- - - m
- - - l
- - - xl
- color
- - blue
- - green
- - white
- style
- - sleeves
- - - Long sleeves
- - - Short sleeves

The menu should look like this:

Latest Fashion T-Shirts
- T-Shirts Men
- - Long sleeves
- - - blue
- - - green
- - - white
- - Short sleeves
- - - blue
- - - green
- - - white
- T-Shirts Women
- - blue
- - green
- - white

---------------------------------------------------------------------------------
Which steps are needed to build the menu group?

1) Add "menu group"
edit options ....... as described on top of this node.
In our example: menu group name is "Latest Fashion T-Shirts"

2) Add vocabulary
a) Select list with all vovabularies - single select!
"Clothes&Accessories" is selected

b) Selected vocabulary is shown as tree with checkboxes (sth like this excist in the content taxonomy module -> tree)
Parent terms are expanded. Klick on term hides or expands child level.
Check term will also enable all children / uncheck disables all children
In our example T-Shirts under Men and T-Shirts under woman were checked.
-> so we will have two terms with the same name (this needs to be changed later)

c) Were to put the terms?
Multiple select list with shows menu group name an all terms that are already chosen.
In our example the list has one entry: "Latest Fashion T-Shirts" (the name of the menu group)
Select the entry.

d) Save

--------------------------------------
Display menu group will show:

Latest Fashion T-Shirts
- T-Shirts
- T-Shirts
-------------------------------------

3) Add a second vocabulary

a) Select list with all vovabularies - single select!
"Properties" is selected

b) Tree with checkboxes
- - - Long sleeves
- - - Short sleeves
need to be selected in our case.

c) Were to put the terms?
Multiple select list
selection: - T-Shirts (the first one)

d) Save

--------------------------------------
Display menu group will show:

Latest Fashion T-Shirts
- T-Shirts
- - Long sleeves
- - Short sleeves
- T-Shirts
-------------------------------------

4) Add a third "vocabulary"

a) Select list with all vovabularies - single select!
"Properties" is selected

b) Tree with checkboxes
- - blue
- - green
- - white
need to be selected in our case.

c) Were to put the terms?
Multiple select list:
- - Long sleeves
- - Short sleeves
- T-Shirts (the second one)

d) Save

--------------------------------------
Display menu group will show:

Latest Fashion T-Shirts
- T-Shirts
- - Long sleeves
- - - blue
- - - green
- - - white
- - Short sleeves
- - - blue
- - - green
- - - white
- T-Shirts
- - blue
- - green
- - white
-------------------------------------

(To change name T-Shirts to "T-Shirts Men" can be done with core menu function.)

Neil, does it makes sense to you?

I´ll be very busy until next monday.

Do we allow for this type of customization in taxonomy menu? I think we need to be careful and not take over all of the control. Taxonomy menu is a compliment to taxonomy and menu. I really want to keep this simple for people who need it simple but give flexibility for the situation mentioned above (the ultimate programmers struggle).

I´m with you. It is a walk on the edge to decide between usability and functionality. In my experience it is the UI that makes the difference! Easy guidelines for simple use and options for sophisticated functions.

So the option is whether to have the configuration in the taxonomy or the taxonomy menu.

I didn´t thought about this option - so we complement each other well. Your way will makes things easier for you. I can´t see at the moment, which possibilities and limitations this has. I need to play around a bit with relationships in vocabularies. Up to now I never used this option.

When the menu is create it pulls in the related terms and creates the following menu:

What if there are more than one relationship and not all should be shown within that menu?
Will you show users the excisting relationships and let them chose?
( By the side: is there a module that shows the term relationships in a nice way?)

So the default path would be "taxonomy/term/48 13." For custom, it would be "category/13 48" This save all of the hard work we did with compatibility with views.

If this works, great. (I thought that "category/13 48" means: show every content linked to 13 and show every content linked to 48. But you say it is show every content linked to (13 AND 48) - than it is fine.)

Either way, a preview is a great idea so they know what they are getting before it's saved.

Yes, "preview" is the right word, not display.

:-) Klaus

Which other modules work with or uses term relationships? That might decide if it is a good way to go for this module. I think it is important not to interfere with excisting needs or concepts.

And using term relationships would require "Taxonomy Vocabulary Relate"
"This module allows you to select related terms in taxonomy from another vocabulary. The default taxonomy module only allows you to select related terms from the same vocabulary."
see: http://drupal.org/project/taxonomy_vocab_relate
I tested tax_manager - it can´t do that. You´re right, it shows relationships nicely.

:-) Klaus

Yes, I guess it is a real challenge to program that.
Especially to take care of changes within the taxonomy that affect excisting menu groups.

An addition to my comments
#14

Clothes
- Shirts (term id=13)
- - large (term id = 48)
- - small
- Pullovers
- - large (term id = 48)
- - small
So how does view knows to show only large shirts and not larges pullovers?
I think this could only be done by "category"/13/48 - or is there another way?

and
#17

If this works, great. (I thought that "category/13 48" means: show every content linked to 13 and show every content linked to 48. But you say it is show every content linked to (13 AND 48) - than it is fine.)

I tested with VIEWS. "category/13 48" is an or-function which shows both. In our example it would show all 13 and all 48. To filter the nodes that are linked to both terms the path has to be category/13/48 and the view needs to have two arguments $tid $tid.

This is only important if the child term (here its is large=48) is an attribute to the term (13) and is also linked to other terms too - which is true for the given example (-> Pullovers).

So how this problem has been solved in the patch of http://drupal.org/node/269773 for Drupal 5?
I don´t have a Drupal 5 installation to check this.

Well, the path also is reliant on the "display descendants" option. That's what turns it into an OR. AND's are 13+48.

I think the "multiple arguments option" provides only the OR function (OR in the sense of binary logic) independent of " " or "+" as separators. I can´t produce any AND relationships in VIEWS by passing arguments without using two seperate arguments tid/tid.

However, as you said, it looks like we need another option. The moment the user connects a second "vocabulary" to an excisting one, he/she needs to decide weather it is a ´normal´ relationship to parent terms or if it is an attribute or property relationship to the terms they get linked to.

Normal relationship: path=category/% argument: TERM ID
One attribute/property level: path=category/%/% argument: TERM ID TERM ID
Two attribute/property levels: path=category/%/%/% argument: TERM ID TERM ID TERM ID
(Maybe that path=category/% will also work with argument: TERM ID TERM ID)

You could limit this function to just one or two levels: the other cases should be sorted out with filters within VIEWS.

One more thing:
In my comment #15 I called the branches that can be added to a "menu group" "vocabularies".
That term can be misleading. Because two branches there could come from the same taxonomy vocabulary.
So would "branch" be a better word?

:-)

Hi Neil, how is it going with the 6.x-3 Version?
It seems you have been busy with making the current version compatible with other modules like i118, domain access etc. I couldn´t help testing because I don´t use these.

I suggest to start the 6.x-3 Version with the option that just one vocabulary (or parts of it) can be added to a menu group - more options can come later.
I would also suggest that a desciption about how to use the module will be available within the module, like:

| List menu groups | Add menu group | Settings | HELP <-

This might reduce the number of issues and comments here.

:-) Klaus

My taxonomy menu time has been spent on answering questions on the forum.

I kept an eye on the comments here - many where written because people don´t read the Readme file or don´t understand what it says. Which supports the HELP idea.
So I´m waiting for the 6.x-3 dev - I´m still with the project.
Klaus

Initial:
Option for base. - Add Argument

Add Argument
Select box (tid, vid, tid with depth, custom, etc)
if custom then a text box

I like the idea. Hopefully users can handle that - as I wrote under http://drupal.org/node/428004 it is a logical AND function.
It needs to have a very good explanation.

Another idea is to use tokens for the path.

Do you have an example for a realistic situation, where this could be helpful?

Another idea:
The next version could implement also
- to create whole blocks,
- to write directories into nodes,
- or provide a cck field with which users can select a menu group which then appears within the node.
Than the module would be a "Eierlegende Wollmilchsau = a oviparous pig with wool that gives milk" which I think means "jack of all trades device" ;-)

I´m sorry that I can´t help with programming.
What I can do is going through all comments here and put together what we have so far.
For that I´ll open a new issue - this one is going to get unclear.

This issue continues with http://drupal.org/node/432048
KSC