Hi Jaza,

Not trying to hustle you or be impatient, but I have spent the better part of the last few days dealing with menu issues that are making a site impossible to use. These issues seem to have worsened after importing taxonomy data. I am summing up the major problems:

  • Deleting a container/child container scatters that container's categories all over the admin navigation menu
  • Deleting containers/child containers/categories results in those entries being deleted at administer>>category ((confirmed by no orphans in the outline view), but all the links remain in the admin navigation menu
  • Deleting or editing a menu item or menu block at administer>>menu takes a horrendous amount of time- upto 2 minutes and more for each menu link
  • Frequent display of blank pages whenever doing anything at administer>>menu. The only way to find out if the changes have been saved is to go back to the original page and force refresh the browser
  • Assigned nodes are getting added to the navigation menu for categories and containers that have menu items for assigned nodes disabled.

All this is with the latest category module version (the one that corrected the SQL syntax error) installed to overwrite the earlier module. These menu issues are making the excellent import and bulk edit functions look utterly meaningless. In this instance, I could have set up a new site from scratch, added all the containers and categories and the nodes in less time than I have spent trying to troubleshoot menu issues:(

I am sure you will understand that I am not complaining but just trying to report the issue in detail. I will gladly give full access to the site and the database if that would help you to debug this problem. I flushed the cache table and all other tables with overhead, optimized all the tables etc, but to no avail.

CommentFileSizeAuthor
#7 container_outline_view.gif5.53 KBvenkat-rk
#6 category_menu_update_issue3.gif5.13 KBvenkat-rk

Comments

betsyj’s picture

betsyj commented

Ramdak: Do you also see evidence that the Category Information Container / Parent relationship is incorrect or cannot be restored for items once the menu structure has been damaged? I got into a similar state and had to restore the database and start over. Since then I have avoided manually changing anything in the menu, letting everything be generated automatically, but I will eventually want to control the menu structure independently of the category structure and am fearful of getting into the same predicament.

Jaza: A related question: Once the basic category structure, including menus, has been created, can you effectively turn off the regeneration of menus for any items that are changed? This would give you good menus to start with but then protect your menu structure from accidental damage.

Jaza’s picture

Jaza commented
Category: bug » support
Priority: Critical » Normal

Hi Ramdak - please see below for my responses to your questions:

Deleting a container/child container scatters that container's categories all over the admin navigation menu

This is the way that the menu module behaves when it finds an 'orphan menu item' - it moves that menu item to the top level of the default site menu tree (i.e. the 'navigation' menu tree). Sorry, but there isn't much that can be done about this - creating orphan categories will also create orphan menu items, and Drupal core does not handle orphan menu items very 'elegantly'. I recommend using category_bulkedit to move all of your categories out of a container before deleting it, if you wish to avoid this from happening.

Deleting containers/child containers/categories results in those entries being deleted at administer>>category ((confirmed by no orphans in the outline view), but all the links remain in the admin navigation menu

Cannot reproduce this - sorry.

Deleting or editing a menu item or menu block at administer>>menu takes a horrendous amount of time- upto 2 minutes and more for each menu link

The 'administer -> menu' page is 100% handled by the Drupal core menu module. Any issues with this page are therefore the fault of Drupal core, not the category module. I've never experienced this myself, however I wouldn't be surprised if the 'administer -> menu' page is unable to handle large numbers of menu items.

Frequent display of blank pages whenever doing anything at administer>>menu. The only way to find out if the changes have been saved is to go back to the original page and force refresh the browser

See above - this is a core menu module problem.

Assigned nodes are getting added to the navigation menu for categories and containers that have menu items for assigned nodes disabled.

Cannot reproduce this - sorry. Please check that if you're assigning nodes to categories from multiple containers, that all of the containers have their 'menu items for assigned nodes' option set to 'disabled'.

Sorry to hear that you've been having so many problems with category_menu - it is a complex module, and it deals with the even more complex core menu system. With so much complexity involved, there are many benefits, but there are also bound to be many bugs. Also sorry that I couldn't be of more assistance. It seems that many of the problems you've encountered are related to the core menu system, and not to category_menu. A number of people (including myself) are interested in improving the core menu system for the next version of Drupal, and when those improvements are made, modules that build upon the core menu system (such as category_menu) will also benefit.

venkat-rk’s picture

venkat-rk commented

Hi Jaza,

I really appreciate your taking the time to explain things in such details. I generally agree with you that the quirks of the drupal menu system are having an impact on the way category_menu behaves or is perceived to behave. However, that still leaves a few clarifications and a question and I hope you will be kind to answer these also.

Clarifications:

Sorry, but there isn't much that can be done about this - creating orphan categories will also create orphan menu items, and Drupal core does not handle orphan menu items very 'elegantly'

The problem is that during the whole trouble with the menu items I didnt find even a single orphan category!

Deleting or editing a menu item or menu block at administer>>menu takes a horrendous amount of time- upto 2 minutes and more for each menu link

I ruthlessly deleted all the custom blocks I had created, each with their own menu items (this was a site that I upgraded from 4.6.5 to 4.7.1 and then used category_legacy to import the stuff) and the performance of admin>>menu improved noticeably and immediately.

Deleting containers/child containers/categories results in those entries being deleted at administer>>category ((confirmed by no orphans in the outline view), but all the links remain in the admin navigation menu

This is basically the same problem as categories getting scatted over the nav menu. I just wanted to make the additional point that I couldn't find any orphan categories at any point of time.

Cannot reproduce this - sorry. Please check that if you're assigning nodes to categories from multiple containers, that all of the containers have their 'menu items for assigned nodes' option set to 'disabled'.

I always set menu items for assigned nodes disabled. Have hated it right from the time of taxonomy_context:-) Will try again in the latest category version I am using.

Question

I recommend using category_bulkedit to move all of your categories out of a container before deleting it, if you wish to avoid this from happening.

I can't quite get how to do this. And, is there a specific place to which they should be moved?

Thanks for the patience and support you are providing for this module.

venkat-rk’s picture

venkat-rk commented

I just figured out how to move categories out of a container using bulk edit. I will write a tutorial as soon as possible.

venkat-rk’s picture

venkat-rk commented
Status: Active » Fixed

Leaving status to fixed so that others find this thread and don't raise these same issues again.

venkat-rk’s picture

venkat-rk commented
Status: Fixed » Active
StatusFileSize
new category_menu_update_issue3.gif5.13 KB

I am reopening this issue because I just encountered this problem again and this time the trouble is with the ToC links.

Reproducing this error:

1.) Create a child container and set its menu items to enabled.
2.) Then, edit the container again to disable the menu items for that container. Saving these changes does NOT remove this child container's link from the menu tree on the first save
3.) Edited again and this time selected the 'Delete this menu item' in menu item settings. This removed the menu link for the child container from the administer>>menus page, confirming that the core system has disabled it.

In the ToC, though, the link to this child container remains, no matter what. Screenshot attached. The link is the one called 'By media type'.

The issue is that I had to choose the 'delete this menu item' option only because disabling the menu item for that child container in 'category menu' settings did not work. I realise that this is probably the quirky core menu system at work, but addressing that deficiency by deleting the menu item seems to shift the problem to the ToC.

As usual, there are no orphan categories or containers anywhere.

venkat-rk’s picture

venkat-rk commented
Component: Category_menu » Category_display
StatusFileSize
new container_outline_view.gif5.53 KB

Screenshot of outline view of the resources container confirms that the child container is nowhere within it.

Yet, the ToC displays the link to that child container. Any amount of editing and resaving that container fails to remove the link.

Jaza’s picture

Jaza commented

How is this a bug? The ToC is not related to the category_menu settings. All children of a category or container are listed in the ToC, as long as they are within the specified ToC depth, and are not hidden containers. If you have a structure as follows:

Container 1 (menu items enabled, toc enabled, toc depth 0)
-- Container 2 (menu items enabled)
-- Container 3 (menu items enabled)
-- Container 4 (menu items disabled)
-- Container 5 (menu items enabled, hidden cont)

Then containers 2, 3, and 4 will all be shown in the ToC of container 1. Only container 5 will not be shown, because it is hidden. So perhaps you need to make your container hidden, to remove it from your ToC?

venkat-rk’s picture

venkat-rk commented

Thanks! I forgot that category_display's logic is independent of the menu system.

But, shouldn't the child container have appeared then in the screenshot of the parent container along with the other categories?

Jaza’s picture

Jaza commented
Component: Category_display » Category_menu
Status: Active » Fixed

But, shouldn't the child container have appeared then in the screenshot of the parent container along with the other categories?

You mean, should the child container have been shown in the screenshot of the outline view that you posted? No. That outline view was container-specific (i.e. it was a admin/category/x/list/outline view), so it only showed non-distant children of that container (i.e. it didn't show any child containers, and not necessarily all child categories).

To see the outline view with distant parents/children, you need to use the site-wide outline at admin/category/list/outline.

Moving this issue back to its previous states, as these recent comments have not been related to the original issue, and do not constitute a bug anyway.

venkat-rk’s picture

venkat-rk commented

Okay, Jaza. I get it now. Thanks as always for your tremendous patience in dealing with my nagging questions:-)

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)