This module could implement its own invisible field which could be assigned to entities like taxonomy terms or nodes. That field would show up in the entity edit form and provide some settings like enable/disable and maybe something like a weight value. That would then allow additional things like:

  • If the field was assigned to taxonomy terms, then individual terms from the tree could be excluded from the menu tree automatically, even if the menu was re-created over and over again.
  • If the field was assigned to nodes of a certain type, then those nodes could be included into the menu tree automatically as menu item children of the taxonomy term they are associated with. The detailed field settings would then allow the editors to manage, which of those nodes and in which order (by the weight) would be included into the menu.

The use case that created that idea is a mega drop down menu which is derived from a product group taxonomy, but only certain components of the whole content should be included into the menu.

What do you think? It could be implemented completely optinal, so that current functionality would not be broken.

CommentFileSizeAuthor
#5 taxonomy_menu_2463795.patch6.77 KBdtamajon
#1 taxonomy_menu_2463795.patch3.37 KBdtamajon
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dtamajon’s picture

dtamajon CreditAttribution: dtamajon commented
FileSize
taxonomy_menu_2463795.patch3.37 KB

I have added a check in term to decide if term should be shown in the menu, so every time it is rebuild the terms will be shown only if they are marked.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at PARAGON Executive Services GmbH commented

Thanks @dtamajon for getting back to this suggestion. I've looked into the implementation and have a couple of suggestions:

  1. Why not using a field instead of variables? I think we would be polluting the variables which is not pretty. And when using a field, you'll (a) get your own table and (b) will get the load and save functionality for free.
  2. The default values when building the menu should be TRUE, not FALSE. This is because the default value from the form will only apply after a term got saved - which doesn't have to be the case for users who update the module or even install it from on their site when terms already exist.
dtamajon’s picture

dtamajon CreditAttribution: dtamajon commented

Hi @jurgenhaas, I have done a try to use fields... so I suppose the logic place to add the "display" field is the "taxonomy_menu" table.

As configuration is by term, it means that I can't save info while taxonomy menu is not defined.

So for one side I think that taxonomy term should be configured independently of taxonomy menu. I haven't tested, but if menu is changed, I guess the "taxonomy_menu" table is rebuilt, not updated, which means that terms configuration is losen (of course, we can take care of holding values and create the correct data).

The other option, is hiding "Display term in Taxonomy Menu" field in terms if no menu is selected for the taxonomy. It means if I don't want a taxonomy for a time in a menu and then I activated later again I will haver to configure every term again.

I'm not sure which path makes more sense on a general solution, so let me know you opinion.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at PARAGON Executive Services GmbH commented

Like I wrote in the original issue description I would prefer to have that field in either the taxonomy_term entity and/or assigned to nodes (or generally any displayable entity). Is there a problem with that?

dtamajon’s picture

dtamajon CreditAttribution: dtamajon commented
FileSize
taxonomy_menu_2463795.patch6.77 KB

Please, let me know if this patch applies as you expected.

dtamajon’s picture

dtamajon CreditAttribution: dtamajon commented

Hi @jurgenhaas,

Will this feature be merged in the taxonomy menu? If not, I will try to create a new project.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
CreditAttribution: jurgenhaas at PARAGON Executive Services GmbH commented

@dtamajon sorry for delaying this, totally my fault. I'm currently so busy with customer work and I have no active project where this is been used. So if you feel comfortable with it, please go ahead and don't wait for me, if you don't mind.