category_get_parents indexing changes

I ran into the same issue.
Though I am not sure about whether or not this is the proper solution (I understand too little of category) It /does/ fix the bug.

FWIW, this patch fixes the "SQL error" bug #70229 too, it seems.

Can you make it please?

Which of these three patches (the one in the original post, #6 and #12) should be applied? Or should all the patches be applied? In any particular order? I am willing to test this out.

Could you please provide category_array_fix.txt as a patch file?

Thank you bdragon. I am going to jump into this headlong. I have invested too much time in category module not to. I rarely use multiple parents, but do use category_legacy frequently and hope this will solve the bugs. I experienced the category_hierarchy bug just today when using category_legacy.

I applied both the patches. Now, when I create a container, I can see the container hierarchy in the parent select drop-down. I don't remember having seen this earlier. Is this correct?

In the attached screenshot, 'Find' shows up as the child container of 'Find Section', a hidden container. This is exactly the way I set it up. I don't remember this ever having worked this way.

Yet to test category_legacy. Unfortunately, I trashed a large test site built on taxonomy so I don't have much data. Will create another test site and report this later.

On a hunch, I decided to try category_pathauto, which has been broken for the last month or so after applying these patches. Good news- it works. No more problems as reported in the issue queue.

Bulk update still has problems creating the correct category paths, as does the creation of an alias when you manually remove the exisitng one from the 'Url path settings' field, but it works cleanly by and large.

Well, as far as I know, without the patch, parents were getting sorted by id, so it was possible to end up with things in the wrong order, like

*
o Find *
* Find Section *

I don't really remember as I haven't been using category for about a month now.

The 'Find' container wasn't meant to disappear, so everything is working as it probably should. May be I should test category without the patches on another site to find out the exact differences. I will try and set up a test site for category_legacy as I am curious about it too.

I want to add that while these patches have made category less buggy, the category map problem still persists. Unfortunately, I wasn't paying attention to what I was doing, so I am unable to report the exact sequence that caused the error.

category_pathuto is still largely broken (edit a container/category or node- pathauto will report the alias as having been created but nothing happens really. Only works when you manually enter the alias and save), but I will report that in its own issue.

One problem after applying the patch:

If I have a regular or free tagging category under a hidden container and I create a node tagged with that category, this category is not picked up during breadcrumb generation.

As a result, on the node page view, one gets just the 'Home' link in the breadcrumb trail. This breaks the hierarchical menu tree generated by cat_menu too.

At least, this is how the problem appears at first glance. Screenshots to follow.

In the attached screenshot, the node has been tagged with the category 'News' which is under a hidden container. Notice that the 'News' link is not shown in the breadcrumb trail.

The container in question here is 'Spirituality'. It has a hidden container called 'Site Sections' as its parent. 'Discourses' and 'Festivals' are categories created by free tagging. The node displayed in the sceenshot is tagged with both the categories. All good so far.

Everything breaks on the node view. See the collapsed cat_menu tree on the left and the absence of breadcrumbs at the top. It is not an url alias issue, as you can see from the url in the browser.

From what I have seen so far, the issue seems to be only when hidden containers are used. For a container directly under root, the breadcrumbs are correctly generated.

See attached screenshot where the container 'Projects' is directly under root.

Thanks for looking into this.

I just tried changing the weights of the hidden containers around. For good measure, I resaved the nodes tagged with categories in those containers. It didn't help, unfortunately.

Thanks for the quick assistance. Much appreciated. It is past midnight here, though, so I will report back tomorrow after tyring the patch:-)

I applied the patch and resaved the nodes in question, but with no apparent effect. The problem remains.

I am loath to applying the category_breadcrumb.module as it is in the 'wild' at the moment and because category otherwise never has a problem with generating correct breadcrumbs.

I also tried the following, resaving the nodes on each occasion, but without results:

1.) Changed the weights of the free tagged categories to both positive and negative values instead their current 0
2.) Changed the depth of the free tagged categories to an infinite value (-1) even though they didn't have child categories
3.) Changed the depth of the hidden, top level container that holds all the site's containers to an infinite value (-1)

Whoops! Some bug here.

A few things are noticeable:

1.) The patched cat_pathauto now leaves out the container (musings) from the alias and takes the first category. But the browser url points to the full path
2.) The breadcrumb still doesn't reflect the full hierarchical trail- 'Frugality' is missing

Most interesting.

If I click on the edit link of the node that showed the error and look at the url path settings, it shows the full path (including 'musings'). This is contrary to the message that pathuto printed out to screen.

I am just as stumped by the pathauto stuff, but I don't have your level of technical understanding even to suggest something:-)

One other issue I noticed with these patches (only #0, #6 and #12). If I click on create content and try to add a category under <root>, I can't! I am forced to put it under some existing container or create one just for this purpose.

I am a little confused as I think the default behaviour of category module is different and let you add a category under root. Might be wrong, though.

This missing information in the URL case causes Drupal (actually, pathauto, but this is a simplification) to become confused about what code is responsible for a certain path.

Ramdak: What would fufill the "principle of least suprise" for you? I.E. in a perfect world, what would you expect to happen when you put an item in a category in a hidden container? How would the menu look? How would the URL look? How would the breadcrumb look?

Bdragon, I stepped away from this a bit to get some perspective. But, to respond:

1.) When category_pathauto was initially released on 1st June, it worked perfectly with hidden containers- they would ignore those containers and display perfect urls and breadcrumbs. And, although I frequently got the duplicate entry error for category_map or category_menu, distant parents worked fine in conjuction with cat_pathauto. I can say this for sure because I tested a lot

The problems began to surface around mid-July I think when category_pathauto broke. I don't know if this is because of changes to that module or to category. I would hazard a guess that it is the latter.

2. ) To respond to your question- I think my comment above perhaps answers it:-)

I would expect a hidden container to stay hidden because it is there for creating structure, not for categorisation and it is this combination that category module set out to achieve (and almost has), to put things rather simplistically. So, when I use hidden containers and cat_pathauto in conjunction, as a lay user, I expect the hidden containers not to show in the breadcrumbs and cat_pathauto to ignore them and still build correct urls that traverse the category hierarchy (which obviously includes the hidden containers).

I think hidden containers is one of the most important features of the module. One simple example - with it, you can have a category hierarchy that has several child containers each meant for content related to only one node type and taggable by categories relevant only to those node types. By simply placing a hidden container as the parent of each child container in the hierarchy and then creating specific categories as children of that child container, the node form for tagging that content type presents a great improvement for the end user. This isn't possible with core taxonomy- node types can be only defined at the vocabulary level globally as there is no concept of child vocabularies.

In sum, it appears (I haven't rigorously tested it) that the regular category module, despite its many duplicate entry error issues, doesn't have a problem generating correct breadcrumbs and menu items when hidden cotainers are used. However, since mid-July, category_pathauto is broken.

Your patches fix many underlying bugs *and* makes category_pathauto work again, but make breadcrumbs for categories and containers under hidden containers disappear from the breadcrumb, thus breaking the tree view of the cat_hierarchy at node level. Sigh:(

I want to reiterate again that your help has made working with category module possible in Jaza's absence.

I have committed the patches submitted by bdragon in #6, #12, and #29 to HEAD and 4.7. I also committed a few other changes that were needed to make this new version of category_get_parents() work properly, such as changes to the activeselect callback implementation, and changes to the taxonomy wrapper.

Thankyou very much Brandon (bdragon) for your hard work in debugging and patching this issue. I think that your solution provides a more reliable and consistent system for category_get_parents(), and it's clear that it has fixed quite a few category module bugs in one fell swoop. Just how many bugs (and which ones), I'm not quite sure. Thanks also to Ramdak for your testing and feedback in this thread.

I've done a fair bit of testing of this patch (along with my changes), and I wasn't able to find any new problems that it introduced. However, my testing was not particularly extensive. For this reason, I have marked this patch 'ready to be committed' (although it already has been committed) - to indicate that testing of the updated category module is needed, and that further patches may be needed in order to 'clean up any damage' that may have been done as a side effect of this patch going in.

btw, bdragon, I see no reason why I should commit your latest patch in #47, which attempts to undo a bug fix that I committed a while ago. If you can provide some further insight into why you think the $cats_flat thing should be removed, please post your patch and reasoning in a separate thread. Thanks.

I think what just happened to me is related to this thread. I should warn you that I'm really new at this, so I'm never sure if my problems are bugs or newbie functions.

I set up a site in a development environment that was working perfectly. As part of that site, I had put the following code into the category.inc file:

function parenti_title($node) {
if ( ! $node || ! $node->parent ) {
return '';
}

$node = node_load(array('nid' => $node->parent));

return $node->title;
}

I'm not at all sure that was the right place to put it, but I tried several other locations, and that was the only one that worked. It allowed me to use the parent name within a node by inserting the following code:

f ($is_front) {
$parenttitle = parent_title($node);
print $parenttitle;
print t(": ");
}

It worked perfectly.

But when I started to set up my site on a hosted server, I used the most recent version of drupal, and the most recent version of the category module (9/17/06).

Now I have two problems, which I think may be related to this thread.

First, drupal recognizes the function, but it doesn't find a parent (I put a message between the single quotes in the function, to test this. The message prints to the page, where I used to get the name of the parent category.)

Second, when I adusted the weight on one of my categories, and clicked on "Save categories and containers" on the category page, I got the following error messages.

Duplicate entry '2-3#' for key 1 query: INSERT INTO category_cont_distant (cid, allowed_parent) VALUES (2, '3#') in /home/dailymull/domains/dailymull.com/public_html/dev/includes/database.mysql.inc on line 120.

Duplicate entry '2-0' for key 1 query: INSERT INTO category_cont_distant (cid, allowed_parent) VALUES (2, '0') in /home/dailymull/domains/dailymull.com/public_html/dev/includes/database.mysql.inc on line 120.

Duplicate entry '1-0' for key 1 query: INSERT INTO category_cont_distant (cid, allowed_parent) VALUES (1, '0') in /home/dailymull/domains/dailymull.com/public_html/dev/includes/database.mysql.inc on line 120.

Duplicate entry '1-0' for key 1 query: INSERT INTO category_cont_distant (cid, allowed_parent) VALUES (1, '0') in /home/dailymull/domains/dailymull.com/public_html/dev/includes/database.mysql.inc on line 120.

My apologies if this is a red herring, but it seems to fit the pattern in this and related threads.

Thanks

Sorry--correction: the version of the category module I'm using is 9/19, not 9/17.

Okay, I think I'll stop making these posts until I know more.

The problem with the function was my fault--I had some settings wrong. So that has nothing to do with this thread, and I apologize.

The error messages still seem to be connected, as far as I can see now.

Just tryed the latest 4.7 release with category_get_parents fixes, and seems to work.
Also combined with the category_breadcrumb.menu at http://drupal.org/node/75276 outputs nice breadcrumbs that reflect the category hierarchy (with previous versions that didn't work).

I didn't deep test (not more than 20 minutes) but wanted to write this rather than forgetting to give any feedback.

The duplicate entry issue is alive and kicking. It hit me a while ago when I tried to convert a taxonomy based site to category by using category legacy to import the stuff. I downloaded and installed the category module just a few minutes ago, so this bug is still there in the latest version.

Jaza, Bdragon, should I submit an issue against category_legacy or will this do?

Marking this issue fixed, since http://drupal.org/node/92818 has now gone in, and since nobody has reported any problems specifically related to the commit announced in #48 (above).

@bdragon: Thanks. Does this mean that the fix in http://drupal.org/node/92818 committed by Jaza takes care of this and the problem reported in the other thread?

Thanks.

Hi,

I open this bug report again.
I am using the latest category module (version v 1.100.2.26 2007/02/02).
When making a translation with localizer module. I get the duplicate entry error with category_cont_distant:
Duplicate entry '590-0' for key 1 query: INSERT INTO BEST_INFO_category_cont_distant (cid, allowed_parent) VALUES (590, '0') in /home/beontop/domains/agim.nl/public_html/includes/database.mysql.inc op lijn 120.

Please help.
Thanks in advance,
greetings,
Martijn
www.best-information.eu

Please open a new issue for that. This thread is far too long to maintain.