When hiding a group on the main page, it is also hidden on it weblinks/% page

Shall we implement this change?

Shame they didn't produce a patch so we could see exactly what was changed. How does this code from four years ago compare to the current .module?

I just tried testing this and on saving after selecting 'no' I got:

Undefined index: confirm_delete in weblinks_blocks_form_alter()
(line 897 of /Library/WebServer/Documents/drupal6/sites/all/modules/weblinks/contribs/weblinks_blocks/weblinks_blocks.module). 

So I guess that's another one to fix before we continue.

Yes, but the changes are minimal and straight forward:

function weblinks_get_tree($parent = 0, $quick = FALSE, $ismainlinkspage = TRUE) {

Third parameter $ismainlinkspage added.

    if (!$admin && ($term->depth > $max_depth || ( $ismainlinkspage && !$show_this_term) )) {
      continue;

Checking parameter $ismainlinkspage, if set skipping the term when it should not be displayed.

  $tree = weblinks_get_tree($tid,FALSE, $tid == 0 );

In function weblinks_page in call to weblinks_get_tree assignment for third parameter added.

I tested hiding a group as well (w/o the above changes), and it works as designed. I could save the changed setting w/o any PHP errors.

Most probably you hit the 'Delete' button which is located left from the 'Save' button. And second when I clicked the 'Delete' button a confirmation dialog was displayed, as expected.

No, I definitely get that error when editing a group on 'save', not 'delete'. I've raised a separate issue to deal with any of these #2383879: PHP5 warnings in 6.x - Undefined index, undefined variable, undefined property

Going back to the original problem, I can see that hiding the group from the main page is a useful feature, as you may want to only have the links displayed in a block. But the designer may also want to provide access to the links for this term from other places, so having the page show empty is no use. I think this is a bug, and should be fixed, and I like the way mdoubez did it.

Here is a first-draft patch for the changes as above. Fixing D7 first.

hm..., I have never seen that error.

But I agree, the change makes sense and your patch looks OK. I can test it the overnext week.

Tested. Patch works for me.

Thanks to Michael for the original code and to Gerhard for testing.

This bug was originally raised at 6.x and the correction is identical. I had this change pending in my 6.x local test site, so thought I might as well make a patch before checking out the code for current testing.
Here's a patch

OK. Tested and works.

Thank you.

The issue is fixed. Old patch from #10 got requeued, and obviously it fails to apply because the code change is already committed in #12.