Click on parent term and show nodes for its descendants

Going to look at this. Can't promise a quick fix.

I'm laughing! Errr - look, it seems reasonable, but in this module I've been tackling the things nobody else wants to take on...

(still laughing!) I really admire the Taxonomy Menu folks, because they were doing that too, but look at their issue queue - they get it in the neck all the time because they finessed to links only. And I got multi-dimentioned grumbling about how this thing wouldn't work... and that bit was bust and ...aw heck.

Sure, I'll look it over pretty quickly. I just suspect I need some look up some APIs and stuff, so it will take time to code.

[irrelevant partiality alert!] We're big fans of Creedence, the Allmans and Dr. John over here so, anyhow, your tag name will probably do the trick!

Hey you didn't say that this is a Taxonomy Menu special option! Well, I guess why would you see it from that point of view. The implementation seems clearer to me now, though.

If you happen to drop by, I've started working on this one. But it needs a new version, as I have to extend the database.

Ok, try V6.0

Limitations
- no Views integration, conventional term pages only.
- doesn't respect the tid+tid/ tid, tid convention, always does an 'OR' search

Good bits
- stock Drupal. No bodge at all (try it - write your own URL in)
- works on stock or extended URLs

Was this what you were thinking on?

Arrgh! I should have BETAed the release. I was worried about this. But I tried a back install on a working site, and that went ok.

I'll look at it!

[Applicable Dr. John song: "Walk on Guilded Splinters"]. Bet Allen Toussaint has a song for this.

Posted 6.1. Is a bugfix for the problem posted above, and is tested ok. Apology due, I broke the new menu code.

Checkbox selection "Term pages include the nodes from descendant terms" is not saved.

Ok, 6.2 fixes this and is out.

And I apologise to everyone who is waiting on this.

Duplicate titles - I'll dig in for this. HTML might pass me some clues though?

Messy headings - ok, I face the same problem as the Taxonomy Menu folks, that the rendering goes out of the module,

however,

I'm prepared to get in there. I've been vaguely thinking for a while that it's a shame I can't get the the internal theme onto stock URLs. And this is much the same idea - how do we get the rendering into the module's circle of magic? Where we get the render generalities out of the templates (you could hack this issue in templates, but I take it as given the folks on my queue are not up for that) and into the interface?

I think the clue has to lie in Views. That overrides everything, right? And should be good Drupal.

It's getting late here, so I got to drop this for tomorrow (like your text work, by the by, even if you can do that for sandwiches).

Got it. hook_menu_alter(). Can't give you a timeframe. I'll keep you posted.

Question: do you have Views loaded anyway? Views, using the hook, very drastically overrides the menu system (I can't support starting a territory war over URLs such as taxonomy/term/%. Apart from anything else, I'd loose). If you're ducking Views, this is relatively simple, if extensive.

Duplicate titles:

Havn't solved your problem, but I'm a couple of steps forward. I'm assuming(?) your site uses stock URLs.

The H1 (class=title) tag suggests a page template. BlueMarine contains code for rendering such a title.
Garland renders titles with a H2 tag.

The title is provided by the Taxonomy through it's theme (drupal_set_title()).

No idea if the following tip is of help, but here goes:

Tracking down where page content is rendered is difficult, due to the flexible and overidable nature of Drupal's themeing. You can use 'theme developer' (I think that's the name) in the Devel module, and that's what you'll find recommended at Drupal.org. But this piece of magic is very heavy on the javascript and cache, and overloads my little 1GHz setup.

As a (in this case) Linux user, I searched the installation for files containing 'h1' and 'h2' (grep -r "h1 class=\"title\"" .) There's not so many of them, and it's easy to tell where the titles (and all sorts of other rendering) are coming from. I found my dev sites titles in a minute or so. A Windows user just needs a similar facility, to search the contents of the Drupal installation's files. If you have a LAMP stack installation, it might have enough command line code to use a Linuxy search anyhow (sorry, wouldn't know, and if you don't use a command line, the Linuxy solution is too much trouble to learn. Sitll, there may be a Windows way?).

It's an idiot approach, but so long as you can think of a good search, it works every time.

Messy headings:
Ah, if your site uses Views, well, it will be of no use to implement this internal solution. It's a loss I somewhat regret, because the internal term renderer does titles as you wished, term title only. And the idea is extendable to core term lists.

I still plan on the hook implementation, now I've found it, but it goes down the priority list.

If you have a working Views solution, and it seems neat, I'd use that. I understand you have a job you wish to do, which is your main purpose, apart from being on this list. My response time will collapse in about two weeks time, and Views is poorly documented. That apparently so simple little default View, and the background code need to inject Treemenu options, cost me several evenings - Views is rough on developers too. I'm very chuffed with it, because people are using it and it's just what they wanted. But when I revisit Views, I'm going to need a rucksack and several days provisions (virtually speaking).

I'll look for certain into what more we can offer through Views.

There's some interesting thinking in your post.

There are frequent calls on the dev list to put Views into core. The core programmers seem united in their objection to this, though I've never seen an explanation. My guesses are; it's HEAVY (1/3 of core, and a CPU weight), it has a non-standard interface, non-standard object-orientated code, and is difficult for a user. Thinking about it, saying this would probably start a war.

One upshot though, you're right - Views will NEVER be orphaned.

I feel ambivalent about commentary about Views. See, my slight dealings with some of the maintainers suggests they are some of the most pleasant, considerate people in Drupal. Their module is a genius solution to an issue. They broke off, in a very bold move, to create a fully modular interface, and since Views 2 have taken a crateload of grief for their efforts. Yes, you need a paper qualification to use it. But I've not yet come across anyone (you're the first to hint at it, for me) who will accredit the achievement. It needs some time, to sort out the unfriendly quirks in the AJAX interface, and to mature the underlying function provision. Meanwhile,users get a module that makes a CMS work with the same depth as an image or music editing plugin.

The only other way is to go to code. I'm not at all well traveled in this area, but I have used Ruby on Rails. Rails wipes Drupal in so many ways, but you need a dedicated server, and to learn Ruby, the language. Building a secure commercial website, for long term non-technical staff maintenance, is out of the question. So Drupal's peculiar positioning, with an admin drive, but way deeper than a CMS, and with code access, is perfect. And Views is cool. But cool always is painful to live with...

Humm. Think that dev list gets to me sometimes.

Messy headings #2

Within your commercial remit, are able to condone use of a page preprocessor?

If so, put this into your [themename]/template .php file. Anywhere.

function [themename]_preprocess_page(&$vars) {
  $q = $_GET['q'];
  $qa = explode('/', $q);
  if ($qa[1] == 'term') {
    $vars['title'] = substr($vars['title'], 0, strpos($vars['title'], ',') );
  }
}

done, and is the Drupal way to go.

The code GETs the url, checks this is a term page, and if so, strips everything in the title until the first comma.
Unwelcome side effect: if anyone uses a term title with a comma, everything gets stripped after the comma.

Yup, I can go there. I'm out of time this evening, but I'll look tomorrow.

Sorry about the search. Just a guess, or maybe you know this much, but the dot (full stop/period) at the end means 'search from current directory'. Launch it from anywhere but inside your personal site folder and it will search from wherever you started, maybe even every file and folder on Site5.com?

I'm not bailing out on this, sorry if I gave that impression. It may be a Treemenu issue, and if so, i want it squashed. I need to be able to replicate the issue though, and we need to build a bridge there (your site not working/my dev site working).

Look, tomorrow morning I'll build a fresh site, hokay? And see if I can track anything down. Rob.

I know why the duplicate titles. Fix coming as soon as I decide how.

Check 6-3. Rob.

Sorry, Didn't spot #23, as I'd already got my result.

This is an unacceptable error. Should it have been marked as critical, despite the small size, that would be fair.

In the event, I have retained the theme title, and removed the other.

The code, for all that, is kind of correct in it's action. It is generating a title for the page, through drupal_set_title(). However, unenabled functionality - that theme is there because TTM can put multiple menus on a page. So there is a title for each menu, too. But then you wind up with two titles, if there is only one menu. And at present, you can only have one menu.

RE: Views (and the presentation HTML/CSS). I'm up for putting your work into the module. Since you have a working solution, I'd like to do this later? Me, I'd prefer a less frantic and public release schedule?

RE: "...will continue to work on a Views solution so (a) distributed code doesn't need to be modified, which is one of the primary advantages of using Views, (b) the approach is theme-independent, and (c) the unwelcome side effect mentioned in #20 is avoided."

The issues covered in this particular post are not the only posts with this general background standing at their shoulder.

It seems that, well, I'm not sure how you would describe this, but commercial designers who work at a mid level are very interested in how this module controls rendering from admin, for the reasons you state here. My original plan was 'non-contextual menu rendering, put a menu where you want'. But since Drupal doesn't make menus from the Taxonomy, that extended to, 'how do you want the menu?'

From here on out, 'Admin control of menu rendering generalities' is a stated aim of this module.

HTML fix is smart, and will go in next release.

Views will at least go in help, along with relevant text, pending me getting my teeth into Views again.

Both substantial issues closed, so posting closed. Hurrah!

Humm, when it came to it, I don't like 'break', as it's HTML unrelated to content. However, the titling does look lousy out of the can, so I've extended the HTML and put in a snippet of css. Apologies to anyone whose site changes under them, but I'm with Bayou on this one.