Please suggest!

1. How to remove "View, Talk" tab under node, also use link "Add new comment" or "Talk page (1 comment)" (meta area in bottom of node) for go to Talk page?
(talk-remove-tab-1.png)

2. How to click on node title on Talk page for go back to Node page?
(talk-remove-tab-2.png)

Thank.

CommentFileSizeAuthor
#3 444894_3_hide_tab_on_non_talk_page.patch1.79 KBgreggles
#2 missing_tab-1.jpg115.45 KBgreggles
talk-remove-tab-2.png39.15 KBpoakpong
talk-remove-tab-1.png45.67 KBpoakpong

Comments

todd nienkerk’s picture

todd nienkerk commented
Title: Request to remove "View, Talk" tabs under node title » Add option to remove "View" and "Talk" tabs under node title

+1. Displaying a talk tab could simply be one of two (or more) display options. There could also be a "back to node" link on the talk page.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
StatusFileSize
new missing_tab-1.jpg115.45 KB

It's actually a bit of a problem to try to remove the tab :(

If we use MENU_CALLBACK as the menu type then the tab disappears, but when you go to node/NID/talk *all* of the tabs disappear because Drupal forgets where you are relative to the other menu items. If we could figure out a way keep those tabs, I think this could be a good solution.

If you just use an empty "title" value for the menu callback as a local task, then it displays as empty which helps to diminish the display, but frankly it just looks silly/ugly. On some browsers having an empty string as the link disappears (safari) but I don't think we should rely on that, exactly...

I'm not sure of a good way to fix this.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Needs review
StatusFileSize
new 444894_3_hide_tab_on_non_talk_page.patch1.79 KB

After working on the access check I had a crazy idea on how to do this.

Attached patch makes it work, but it _does_ show the talk tab when on the "node/NID/talk" page. Does that still seem valuable? The reason it has to show the tab on that page is because of the results of the research in comment #2.

Anonymous’s picture

Anonymous (not verified) commented

The MENU_CALLBACK solution works fine for me. I have implemented it on a private dev site and I see no problems.

I do not understand why it is a problem to not have the other tabs appear on the talk page. They don't seem like they are useful there?

This seems like an important thing to support. Tabs are good for wikis but not for most other site types. Putting the comments on a separate page is good to remove clutter, and also because if there are many comments, the scrollbar suggests that the main page text is huge, and readers may give up before discovering that the main text is quite short (maybe ending just off the bottom of the screen).

For anyone else who wants to use the MENU_CALLBACK approach:

Edit talk_menu() in talk.module, changing MENU_LOCAL_TASK to MENU_CALLBACK .

Then you need to disable and re-enable the module to decache some stuff. If you have page caching turned on, you may also need to clear the page cache.

I will post a link to a site that uses this once I move it from my dev install to the live one. (That is waiting for a solution to the "recent comments block" problem.)

I couldn't make the #3 patch work. It got a fatal error (WSOD) on the page. I didn't debug in detail because it wasn't the behavior I wanted anyway.

Anonymous’s picture

Anonymous (not verified) commented

You can see the MENU_CALLBACK approach in operation at http://approachingaro.org/comment-policy and http://approachingaro.org/comment-policy/comments .

Is there a problem with this that would make a different approach preferable?

If not -- I guess it would be good to have an admin checkbox to let you switch between these two? It would need to call whatever the right function is to rebuild the menu.

amocsy’s picture

amocsy commented

If it's only a theme issue, one could use (css) display: none;

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

Moving this to 7.x.

As of 6.x, the trivial solution works. Can this be incorporated into the 7.x beta?

(I haven't looked to see if changes in menus in 7.x would make it any more difficult.)

Anonymous’s picture

Anonymous (not verified) commented

(By "trivial solution", I mean MENU_CALLBACK, which is clean, whereas display:none is gross and a potential SEO issue.)

Anonymous’s picture

Anonymous (not verified) commented

I've verified that this (MENU_CALLBACK) works in 7.x-1.0-beta4.

It's a one-line change, plus one checkbox in the admin screen... Could this be incorporated?

It's probably much easier for the module developers to create a patch than for me, but I will do that if the developers will accept a patch but don't want to write it themselves...

Thanks!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Why are people talking about the MENU_CALLBACK solution? The patch posted in #3 is a working solution to this problem that needs reviews in order to get committed. Please test it out :)

Having the tabs disappear means that people will have no built-in way to get back to the view or edit pages on the node. I think we should definitely provide that to people.

Anonymous’s picture

Anonymous (not verified) commented

Hi greggles,

The use case for which MENU_CALLBACK is appropriate is for a blog, rather than a wiki.

It's common on blogs to want to put comments on a separate page. This is a built-in functionality in Wordpress, I believe.

For blogs, you don't want anyone other than the blog writer to see tabs anywhere.

The #3 solution is appropriate for a wiki, certainly.

Can we support both use cases?

Thanks,