Save entire term lineage

If you really need to tag content with the entire hierarchy you are free to implement hook_node_insert() and/or hook_node_update() to save all parents.

Btw.: apart from comments in other issues this is not necessary when using facets (which seems to be exactly what you need). Otherwise the same requirement won't work with core taxonomy module and facets ... (which works pretty well)

CSHS is simply a module to enhance the input of terms; not a module to create obscure data structure.

I will defininetely not add this feature, but I am leaving this issue open, if someone else would like to work on this.

Although this issue is 2 years old, I still (or even more) face the same old challenge when using CSHS in d8.
The module itself works great, my simple problem is, that I have a migrated d6 site, where the taxonomy for all nodes was created by the hierarchical select module with the option "save term lineage". So I have entities now, that refer to levels of my structured vocabulary (the usual example... level 0=Fruit, level 1=Banana...).
The good news: It´s only about two levels and all have a valid child item chosen by having forced to choose deepest level in HS)

I got the point, that you won´t (!) add this "save term lineage" feature to CSHS, but do you have an alternative idea, especially, as the taxonomy_set_lineage module is only available for d7 and obviously not progressing since 2014...

My rough idea:
- delete all entity references for level 0 - so the table for existing entities will only contain the deepest level choice
- set term reference field to limit 1 (to store only one level for new/edited entities)
- set force to choose deepest level in CSHS

With the given setting, CSHS provides the required fields in my edit form that forces the user to first choose the parent level and then the child level - fine.
Only the deepest level child item will be stored in the DB - ok.
For editing the node, I again find both levels to choose from in my form - so at this point I have the sufficient structure and options visible - that´s good.

My challenge/questions start here:
1. Can I display the parent item (incl. link) in the simple view mode of the node? Or do I need to display all nodes (of this content-type) with a views replacement with additional fields for the taxonomy stuff (especially the parent item!).
2. How can I modify the taxonomy view page, so that the page for the parent item fruit also shows all nodes, that (with the new "storage format") only have the child item banana applied?
3. Maybe based on 2, can I create a custom view (block, page whatever...) with exposed filters, that allow to search on parent OR child level and provide the same kind of results: Searching for "fruit" on parent level only would give back all nodes with banana, apple etc....

I´m aware, that this is not a feature request for the module itself, but answers to questions 1-3 above may(!) satisfy the requirements of many other requests (issues in CSHS, in SHS and maybe other areas) and may make the "save term lineage" feature obsolete.

Thank you in advance!

@valderama,

I'm interested in this functionality as well. When you said,

I will definitely not add this feature, but I am leaving this issue open, if someone else would like to work on this.

Does that imply that if someone else writes this functionality, you'd be willing to commit it?

thanks,
-mike

If the implementation does not complicate the whole module too much. I am open to talk about it.

Best,
Walter

A simple(I hope) potential workaround could be providing an option to allow for multiple terms to be saved to the field without switching to the default fields multiple value widget(keeping it as a single value field as far as the user input is concerned) in conjunction with the taxonomy set lineage module

That way, a user could only be allowed to set the term of their choosing, but the system could save the entire lineage even on fields where the user was intended to only select one term.

So basically let the user set the field to unlimited values, but make sure that the widget which is displayed is the same widget that would have been displayed when the field values is set to 1.

EDIT:

An even simpler approach would be to just use rules(if you have it or are willing to include it!) to add a terms parents to the term reference field on node update or creation. Do not use "set a data value" it will replace whatever currently exists with the new value(s). Create a loop under rule actions that loops through each parent of the term currently in the term reference field(Data selector for loop example: node:field-term-reference:parents-all) and inside the loop use "Add an item to a list" where the item being added is the "current list item" of the loop.

I'd like to put my 2 cents in as to why I'd like this feature as well. I have been using HS for many years now, but over the years with the taxonomies increasing, it has gotten extremely slow where it is almost unusable. Both CSHS and SHS are much faster, but I am also using the Taxonomy Menu module, which includes node counts with the category name/levels, however it has not been updated in years and still doesn't count the parent terms in the hierarchy, which kind of is "broken" in my mind. It's really unusable.

HS had an option to save term lineage, so I never had an issue, Now I need to either get CSHS or SHS to save lineage, or have the Taxonomy Menu updated to count parents. I did apply a patch to the SHS module that is supposed to save lineage, but it is from 2 years ago and has always only saved the immediate parent only. 3 or more levels will not work, which I need.

What is the best way to fix my problem? I have to migrate from HS very soon. I'd prefer to use CSHS over SHS, so I'm asking here first.

I was also missing this functionality from HS and need it for a project that I'm working on -- this patch adds an option to save the lineage of the selected term and makes use of OptionsWidget style value handling to work with the existing field widget.

This works from the patch in 8 to add checks to prevent validation errors and warnings.

This works from the patch in 8 to add checks to prevent validation errors and warnings.

This patch builds on the work in 8 and adds checks to prevent validation errors and warnings.

Builds on work in patch from #8, and adds checks to prevent validation errors.

This patch builds on the work in #8, adding some checks to prevent validation errors.

Updated patch fixes error / warnings when saving field settings form with no default value.

Credit: @yodes

Tested. This works for my use case, however I think this solution might not for others. Even though you set the field to allow for unlimited values you can only select 1 parent and 1 child. I would like to be able select multiple combinations of parents and children.

Here is what it looks like before the patch:

Here is what is looks like after the patch:

I need this feature too, so thanks to @johnnybgoode and @yodes for their work around of it.

I've migrated the patch of the comment #17 to the last dev version of D8 and tested in 8.8.4 and 8.9.2 and it works without a problem.

Maybe @valderama can check it and think if it is possible to commit or tell us some improvements needed to get it committed.

Here an screenshot of the result after the patch:

Credit: @johnnybgoode and @yodes

I amended the latest patch and made a commit to 8.x-1.x.

I would like to be able select multiple combinations of parents and children.

@vector_ray that's a topic for another issue. Let's close this one. Feel free to create a follow-up and work on a solution.

Thanks everyone!

I have a feeling that this isn't totally fixed because it prevents from being able to choose multiple selections. Only 1 parent is available and only 1 child also.

You can save an entire lineage, in my case in one project is used to save a lineage of 5 level of depth perfectly.

And now this feature works similar to "Hierarchical Select" module on Drupal 7 and in my opinion solves and covers the initial requirement.

This could be the inicial trail to develop the feature that fit with your needs in other issue when this issue be merged.