Categories with multiple parents (in multiple hierarchy containers) are not correctly rendered in category selects, but are shown only under the first parent. This is because #options arrays -- as they are still used by the Category module -- can't contain a key twice (see this issue).

This issue can't be solved as long as #options are represented as simple arrays. Therefore #options in taxonomy arrays are represented as objects instead, starting with Drupal 5.x (see Converting 4.7.x modules to 5.x.

I suggest switching to the representation of #options as objects to solve this issue and to keep emulating core taxonomy.

print_r($form['category']) (with category.module enabled)

Array
(
    [#type] => fieldset
    [#title] => Categories
    [#collapsible] => 1
    [#collapsed] => 1
    [#tree] => 1
    [158] => Array
        (
            [#type] => select
            [#title] => Testcontainer
            [#default_value] => 0
            [#options] => Array
                (
                    [0] => <none>
                    [159] => Testcategory 1
                    [160] => Testcategory 2
                )

            [#description] => 
            [#multiple] => 0
            [#size] => 0
            [#required] => 0
            [#weight] => 
        )

)

print_r($form['taxonomy']) (with category.module disabled)

Array
(
    [158] => Array
        (
            [#type] => select
            [#title] => Testcontainer
            [#default_value] => Array
                (
                )

            [#options] => Array
                (
                    [0] => <none>

                    [1] => stdClass Object
                        (
                            [option] => Array
                                (
                                    [159] => Testcategory 1
                                )

                        )

                    [2] => stdClass Object
                        (
                            [option] => Array
                                (
                                    [160] => Testcategory 2
                                )

                        )

                )

            [#description] => 
            [#multiple] => 0
            [#size] => 0
            [#weight] => 0
            [#theme] => taxonomy_term_select
            [#required] => 0
        )

    [#weight] => -3
    [#tree] => 1
)
CommentFileSizeAuthor
#5 activeselect.js_.patch694 bytesbdragon
#4 category-activeselect-multiple-fix.patch1.84 KBbdragon
#2 category.module_2.patch1.35 KBpancho
#1 select_0.patch858 bytesbdragon

Comments

bdragon’s picture

bdragon commented
Status: Active » Needs review
StatusFileSize
new select_0.patch858 bytes

Please test this patch and check for side effects.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
StatusFileSize
new category.module_2.patch1.35 KB

Seems to work perfectly! Tested it on regular and tweaked node forms - the #options behave now exactly like taxonomy.module and correctly render multiple hierarchy terms.

As your patch will break the "category_activeselect" function, I updated that one, too. Enclosed is a combined patch - please check this as well though my obj2arr conversion code has been tested positive!
Actually activeselect seemed to me already broken before patching this issue here -- it didn't get worse... :/

print_r($form['category']) (with category.module enabled)

Array
(
    [#type] => fieldset
    [#title] => Kategorien
    [#collapsible] => 1
    [#collapsed] => 1
    [#tree] => 1
    [158] => Array
        (
            [#type] => select
            [#title] => Testcontainer
            [#default_value] => 0
            [#options] => Array
                (
                    [0] => <none>
                    [1] => stdClass Object
                        (
                            [option] => Array
                                (
                                    [159] => Testcategory 1
                                )

                        )

                    [2] => stdClass Object
                        (
                            [option] => Array
                                (
                                    [169] => -Subcategory
                                )

                        )

                    [3] => stdClass Object
                        (
                            [option] => Array
                                (
                                    [160] => Testcategory 2
                                )

                        )

                )

            [#description] => 
            [#multiple] => 0
            [#size] => 0
            [#required] => 0
            [#weight] => 
        )

    [#prefix] => <div class="taxonomy-form">

    [#suffix] => </div>
)
firstov’s picture

firstov commented

I'm having similar issue with my travel site I'm working on. When I list all categories in Admin menu I see all parents and all their child terms, however when I try to add new content, I only see a few children terms for some parent terms.
Is there a fix for Druapl 4.7.6?
Thanks!

bdragon’s picture

bdragon commented
Assigned: Unassigned » bdragon
StatusFileSize
new category-activeselect-multiple-fix.patch1.84 KB

OK, I got a chance to look at this a bit.

Here is an (untested!) patch to category.module that should make activeselect + multiple parents work correctly on the Category side. (It requires a patch to activeselect, will be posted in a sec)

bdragon’s picture

bdragon commented
StatusFileSize
new activeselect.js_.patch694 bytes

And this is the Activeselect side.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented

I tested your patch under various circumstances and it mostly seems to work. Still there seem to be two problems:

  1. _form_validate() throws an "Illegal choice" error when trying to save. The activeselect element is not considered a select, so it is not flattened before input validation. There are various ways to tackle this: the easiest might be to pretend activeselect was a regular select while validating. Otherwise we would need a separate validation routine.
  2. Given that was fixed (I actually patched form.inc for testing purposes), saving is successful, but the following error message is set twice (exactly identical): "Duplicate entry '1-188' for key 1 query: taxonomy_node_save INSERT INTO wo_term_node (nid, tid) VALUES (188, 1) in ../includes/database.mysql.inc in Zeile 172.". With the patches this error occurs at every nodesave, without it doesn't. Can you confirm it? It is generic enough to be caused by something else, otherwise.

Regards, Pancho

bdragon’s picture

bdragon commented

Ahh, so that's the source of the illegal choice bug...

I think we need to bypass the built-in validation and do it ourselves, there have just been too many bugs regarding activeselect and validation.

For my own and others reference, setting $element['#DANGEROUS_SKIP_CHECK'] on a form element will disable builtin validation on the element. We then need to manually sanity check the selected options.

Regarding duplicate entries, taxonomy_term_save is a bit dumb when it comes to writing to term_node. This is another thing that needs a look at...

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Title: Multiple hierarchy taxonomies don't work correctly » Multiple hierarchy containers don't work correctly

Don't know if that's the source of all Illegal-choice bugs, as this one is only about activeselects...

I agree, we should go for our own val routine, as we can then also check whether a child term is actually allowed for its parent. This way we could make sure Non-JS users (with an actually not so gracefully degraded activeselect mechanism) don't apply non-sense combinations of terms (such as cat1: "2006", cat 2: "February 2004".

Still, I think FAPI should try to flatten all kinds of elements. This being restricted to selects seems to me more like a quick-fix than a generic solution. Why shouldn't other elementtype's options (e.g. radios) be in object or nested array style? This would ease up rendering catboxes as nested selects, radios or whatever. Think we should get that into 6.0 core.

(When I'm talking about core - do jaza and you have alrady laid out a concrete plan about getting certain parts of category module into core taxonomy?)

Concerning the "duplicate entries" issue - I guess we should leave this to another thread, as this needs to be generally fixed once and for all.

Regards, Pancho

bdragon’s picture

bdragon commented

Don't know if that's the source of all Illegal-choice bugs, as this one is only about activeselects...

Without activeselect, the only way to get an illegal choice is to cheat using the webdeveloper toolbar or some such, in my opinion.

I agree, we should go for our own val routine, as we can then also check whether a child term is actually allowed for its parent. This way we could make sure Non-JS users (with an actually not so gracefully degraded activeselect mechanism) don't apply non-sense combinations of terms (such as cat1: "2006", cat 2: "February 2004".

Yep, and by doing that, we only would need one set of logic, no matter if it was an activeselect, select, freetag, or whatever interface.

Still, I think FAPI should try to flatten all kinds of elements. This being restricted to selects seems to me more like a quick-fix than a generic solution. Why shouldn't other elementtype's options (e.g. radios) be in object or nested array style? This would ease up rendering catboxes as nested selects, radios or whatever. Think we should get that into 6.0 core.

I'm not sure what you mean here.

(When I'm talking about core - do jaza and you have alrady laid out a concrete plan about getting certain parts of category module into core taxonomy?)

I don't personally have any plans yet. Fixing things in core that unreasonably interfere with Category are of course a good idea. I'm really excited about the new menu system, it's going to be great.

Concerning the "duplicate entries" issue - I guess we should leave this to another thread, as this needs to be generally fixed once and for all.

Yeah.

--Brandon

John Bryan’s picture

John Bryan commented
Title: Multiple hierarchy containers don't work correctly » Multiple parent hierarchy is a rendering or translation problem

NOTE to anyone with apparently scrambled taxonomies i.e. Containers. Uninstall "Category" and they should be still intact.

I'm guessing you know all the below bdragon 8¬) it looks like you well past diagnosis. But I never presume as it makes a pre out of u and me - Hmm, well I assume you know what I meant ;¬)

Installed "category-5.x-1.1.tar.gz" and every method of viewing or displaying my 'container' 'categories' was messed up (apart from one, see later). Out of several 'containers' only one was hierarchical multi-parent but not only were some of it's branches apearing off the root of that 'container'... some were appearing in completely different un-related 'containers'!

But if I tried to edit a 'category' to correct the miss-placement the edit screen would show the correct parentages still in place. And when I uninstalled the "Category" module I found that the underlying original taxonomy & terms were still intact and correct.

From some of the documentation I gather a certain duality of data is held with "Category" 'categories' being held in seperate tables but the "Taxonomy" 'terms' being retained and maintained in the original core tables? (or is that complete balderdash on my part)

In which case...
The question is where from and how does the edit category/container 'Categories' selection box read it's data? If it reads it's data from the "Category" 'container' then, at least in my case, the container was working fine - it is the retrieval that is $%!!"£.

John Bryan’s picture

John Bryan commented
Title: Multiple parent hierarchy is a rendering or translation problem » Some corrections

My taxonomies do have some damage plus some node are still left as Categories/terms(?) with contents and node family relationships lost.

This blows my location of problem logic out of the water as well as my don't worry just uninstall statement 8¬(

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Title: Some corrections » Multiple hierarchy containers don't work correctly

John: Please don't give your follow-up comments in the issue tracker system (!) a new title as this will change the title for the entire issue thread!
Otherwise I really didn't get your point (except for: "category.module is buggy"), but I will re-read it until I got it... :)

bdragon’s picture

bdragon commented

How it works is:

1) Category provides the interface and storage for categories and containers.
2) The taxonomy.module is turned into a "wrapper" that maintains, as much as is possible, a copy of the "terms" (which are really nodes now) in the term_* tables, for the benefit of modules that try to use the term_* tables directly.

If you need to convert stuff back to real terms, category_legacy can do that on a container-by-container basis. You would also use category_legacy to convert old vocabularies into containers and categories.

firstov’s picture

firstov commented

Not sure why containers got involved in this. It was my understanding the bug is related to some queries in the forms (when you "create new content").
The database structures appear to be working and displaying all parents/children content just fine, when listing all terms for the particular vocabulary.
Again, the bug is when you creating new content and unable to select correct category term.
Thanks.

liquidcms’s picture

liquidcms commented

this ever get sorted out?

I have 4.7 and 5.7 installs of Drupal and category module and neither show a mutliple select for parents when adding a category whose container is set to multiple hierarchy.

jergason’s picture

jergason commented
Status: Needs review » Closed (fixed)

Is anyone still working on this?