Garbage shown in tree branches

If I discover this is a rendering error, it needs a patch upgrade. If the module upgrade has produced a malformed tree, you need to run a menu rebuild. I'll look.

Thanks for testing. I assume, as default, it is TTM's problem, until proven otherwise. Besides which, I want a fix - even if other modules have the problem...

What's missing is a value in the {menu_link} options field, set as ['html'] = TRUE. Lacking that, the HTML shows.

There is now complex interaction on the links. I'm using, for translation purposes, a hook, and running other forms of the menu through the internal renderer, which OUGHT to be adding this. Problem I'm facing is getting a test case going, as it's clearly working here. I'll try and think of some test cases.

Bright light of anew morning and all that, I see we have two issues here.

- HTML is showing when it should be processed.
- Node counts are returning zero, but my understanding is that this installation has plenty of nodes.

Moving the second issue to new post.

In a new installation, I've concocted a set of circumstances which do not do what the user intends, and have some similarities to all these problems. Started work on the fix this morning, but know I will need to think it out, and will probably need tomorrow to get a good and grounded solution.

Should be online then. Rob.

Waiting for some talk on this issue, which worries me a little.

Does the ALPHA-4 have any effect here?

I've had to scurry round the HTML issue to get translation working, and I'm not pleased to see HTML appear on a user installation.

Yeah, your intuition, that this is a separate issue, is borne out by the code background. My only caveat was that until the node counting was working, I had no idea if TTM was delivering the intended code into your installation. You see, TTM switches on HTML processing if it sees a node count. So that stuff doesn't appear without 'node count' enabled, because none of it is appended to the link title.

The fact Vocab Index suffers the same problem is very interesting, for two reasons,

1) Just personal, they too felt that a node count should be surrounded by HTML.
2) They may well be suffering the same problem - but what is it? Don't think I'm going to find the critical code by concentrating on them...

One thing that puzzles me is that TTM deliberately leaves very little room for external tinkering with our menus?

Here are some ways we can start getting at this,

- Does this site have any other modules enabled besides TTM and stock core (I've given Views a brief roll on my clean site, using both your own and my default view, with no ill effects)? Anything that might have a go at links, particularly access/translation modules?

- Umm, this is quite code, but if you're willing to have a go it will yield important information, be the answer yes or no.

First, you need Devel enabled.

line 3625 in taxonomy_treemenu.module, you'll find,

    //if ($ttm['menu_name'] == 'menu-lineage') {
      //dpm($tree);
      //dpm(menu_tree_output($tree));
    //}

take out the comments as follows, and replace the menu name with your menu (the machine) name, as you see and use in the URL.
(leave the double lines on the one where I've left them)

    if ($ttm['menu_name'] == 'menu-myMenuName') {
      dpm($tree);
      //dpm(menu_tree_output($tree)); 
    }

Now revisit the menu page. Maybe you know what the result will be, but if you don't - first, your page may well struggle to reach the screen, with the browser rendering lurching all over the window. When the trauma settles, there will be a VERY large scrolling box above your menu, displaying all the data that goes into the making of your menu, close to the output functions.

Again, you may know what I'm referring to, or maybe not. If not, you could send me a screenshot (scroll down a little and try and find a data chunk referring to a term, any term will do).

If you have some idea where I'm going here, we're looking for the ['localized_options'] entries, and we'd like to see ['localized_options']['html'] = 1 (or true, or something).

To get rid of all this, put those double slashes (//) back at the start of each line.

I've thought quite hard about where to try this. This particular trace will tell me, at least, if the problem is mainly within TTM (the values have vanished) or in later rendering (the values are there). If I had the site here I'd bash away for 15 minutes all over the code, until I'd traced the error. I'm sorry to offer it up as a possibility on an issue queue, so if you don't want to try it, that's fine by me. I'll keep staring at the code and try and devise some more conventional tests until inspiration strikes - Rob.

'lo Bill,

No Daddy duties for me, but I get Parent duties, and then there's Uncle stuff, but that's just fun! However, I'm employed heavily over weekends and evenings - one reason for the post on availability and support is that I'm just not around when others are.

Big old thanks for the testing. We might skim the code work anyhow, now. Seems like you've swung round into a test which gives some purchase on the problem - what's going down round Vocabulary Index? I'll have a go too, sometime in the next couple of days. At the very least, this is going to result in a warning being added to the Help, but I think I want to know what they're up to.

Got to be a strong suspicion now that this is Vocabulary Index's work, for example that they glue all this into the menu titles. I think that this is what Taxonomy Menu does too. Then TTM behaves itself, but renders whatever traps and fixes they have already set... (I veered away from appending to the menu data, as translatable sites may start piling up silly string duplicates, particularly on very mobile sites ( 'childA (0)', 'childA (3)', 'childA (19)' ... ). But that makes the code more complex, and costs computer power).

At least we have an in on this. More to come, soon, I hope. Rob.

Strange - I couldn't get Vocabulary Index to work on my nearly-clean install? Kept throwng errors to say I hadn't installed their V2 database?

Maybe have a go later. Oh well...

Well, that's the one, for sure. Makes me wonder about the module because I scurried over the internals, and it's plainly a serious piece of work by someone with coding agility and deep knowledge of Drupal internals. Perhaps like me they are having problems with migration (database updating). I fret. While Drupal is not uneducated in this, I have tinkered with the Ruby on Rails framework, which can change the database with a flick of the wrist.

Anyhow, I still intend to revisit the issue. Just as soon as I get some time and can get a grip on it - I'd rather look over TTM's performance and get 7 stable, though.

So leaving this live (and thank my stars my issue queue doesn't look like theirs, or Views).

Hi guys,

Trying to follow this thread the best I can and wondering if there is anything like closure/resolution? I've gotten to the point of seeing the span tags appear in the menu and yes I have the count nodes option enabled beecause that's really important.

Running 6.x.7.1 on D6.16