[drupal-devel] [bug] "Add new comment" no longer shows up in $links?
Project: Drupal Version: 4.5.1 Component: poll.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Junyor -Status: active +Status: patch Attachment: http://drupal.org/files/issues/junyor.poll.patch (762 bytes) The change to theme_node was done as part of http://drupal.org/node/9287. Other than theme_node, poll_view is the only function that calls link_node directly. Attached is a patch to fix the function call in poll_view to send the correct parameters. Junyor Previous comments: ------------------------------------------------------------------------ December 30, 2004 - 15:41 : Morbus Iff I recently upgraded from 4.4.2 to 4.5.1, and have noticed that the poll block no longer displays the "add new comment" or "# comments" link. This is (was) important to me, as I usually ask for comments whenever someone chooses the negative option. Any idea where and why this went? You can still get to the comment form in a roundabout way ("other polls", choose your poll, whammo), but that's far too many clicks and intellect points. ------------------------------------------------------------------------ January 18, 2005 - 16:50 : rooey I had the same problem going from 4.4 to 4.5 - i still see it in 4.5.2 :( There is *some* info on comment issues here: http://drupal.org/node/11366 I didn't find any of them solved this particular issue tho. ------------------------------------------------------------------------ January 18, 2005 - 18:28 : Junyor So, not even the "add new comment" link is showing up? I just loaded the poll module and that shows fine. However, the current comment count doesn't show correctly in the block. This is what I've seen so far: 1) poll_block calls poll_view 2) poll_view calls poll_view_voting, which outputs the poll choices 3) for blocks, poll_view calls link_node, which calls hook_link('node') in each module. For all other poll displays, the theme does the call to link_node (via node_view) I'm guessing poll_view is where the problem is. I'll keep looking at it. ------------------------------------------------------------------------ January 18, 2005 - 18:41 : Junyor Changing the call to link_node on line 438 in poll.module (in poll_view) to: ------------------------------------------------------------------------ January 18, 2005 - 18:51 : Junyor Trying again with correct PHP tags. :) Changing the call to link_node on line 438 in poll.module (in poll_view) to: seems to solve the problem. I'm trying to look now at the history of link_node to see why that fixed it. That's the same parameters that the call in theme_node uses. -- View: http://drupal.org/node/14936 Edit: http://drupal.org/project/comments/add/14936
On Tue, 18 Jan 2005 18:58:58 +0100, Junyor <drupal-devel@drupal.org> wrote: [RE: http://drupal.org/node/14936]
The change to theme_node was done as part of http://drupal.org/node/9287. Other than theme_node, poll_view is the only function that calls link_node directly.
Attached is a patch to fix the function call in poll_view to send the correct parameters.
Is there a function to theme links specifically for blocks? poll_block calls poll_view, which outputs its links. I checked around a little and saw other blocks outputting their own links. It would probably be best if they called a theme function, which called hook_link with a block parameter so the modules could handle the links correctly. I haven't looked at any theming issues before, so I might not know what I'm talking about, too. :) -- Tim Altman
On Tue, 18 Jan 2005 21:47:58 +0100, Steven Wittens <steven@acko.net> wrote:
Is there a function to theme links specifically for blocks?
There is none, but depending on you want, the simple CSS selector ".block a" (and variations on it) might be all you need.
What I'm thinking is probably more along the lines of a new hook, rather than theming. So, we'd have hook_block_links (or extend hook_links to have a binary block parameter), which would allow all modules to add links to specific blocks. Then, those links would be passed to theme_links, which would do its work. I think this is more than a CSS issue, as most links should be wrapped in some block level element. Weblink.module is currently inserting its own HTML to do this. Thoughts? -- Tim Altman
Tim Altman schreef:
On Tue, 18 Jan 2005 21:47:58 +0100, Steven Wittens <steven@acko.net> wrote:
Is there a function to theme links specifically for blocks?
There is none, but depending on you want, the simple CSS selector ".block a" (and variations on it) might be all you need.
What I'm thinking is probably more along the lines of a new hook, rather than theming. So, we'd have hook_block_links (or extend hook_links to have a binary block parameter), which would allow all modules to add links to specific blocks. Then, those links would be passed to theme_links, which would do its work. I think this is more than a CSS issue, as most links should be wrapped in some block level element. Weblink.module is currently inserting its own HTML to do this.
Thoughts?
-1 on this.. We output a unique id for each block, which helps us to theme the various blocks in a unique way.. Stefan
On Wed, 19 Jan 2005 11:42:08 +0100, Stefan Nagtegaal <drupal-devel@frontaal-online.com> wrote:
Tim Altman schreef:
On Tue, 18 Jan 2005 21:47:58 +0100, Steven Wittens <steven@acko.net> wrote:
Is there a function to theme links specifically for blocks?
There is none, but depending on you want, the simple CSS selector ".block a" (and variations on it) might be all you need.
What I'm thinking is probably more along the lines of a new hook, rather than theming. So, we'd have hook_block_links (or extend hook_links to have a binary block parameter), which would allow all modules to add links to specific blocks. Then, those links would be passed to theme_links, which would do its work. I think this is more than a CSS issue, as most links should be wrapped in some block level element. Weblink.module is currently inserting its own HTML to do this.
Thoughts?
-1 on this.. We output a unique id for each block, which helps us to theme the various blocks in a unique way..
Fair enough, but there's no clean way for a module to output links specifically for a block. And, AFAICT, any links that are output now are stuck in module-specific markup. Isn't consistency a good thing? -- Tim Altman
What I'm thinking is probably more along the lines of a new hook, rather than theming. So, we'd have hook_block_links (or extend hook_links to have a binary block parameter), which would allow all modules to add links to specific blocks. Then, those links would be passed to theme_links, which would do its work. I think this is more than a CSS issue, as most links should be wrapped in some block level element. Weblink.module is currently inserting its own HTML to do this.
-1 on this.. We output a unique id for each block, which helps us to theme the various blocks in a unique way..
Fair enough, but there's no clean way for a module to output links specifically for a block. And, AFAICT, any links that are output now are stuck in module-specific markup. Isn't consistency a good thing?
Is it cleaner to -------------------------------------------------------8<------------ if (enabled(comment module)) { add comment links } -------------------------------------------------------8<------------ in a module OR -------------------------------------------------------8<------------ $output .= call_hook("add block links", "blockname", "block delta"); -------------------------------------------------------8<------------ in that module and -------------------------------------------------------8<------------ function comment_add block links($name, $delta) { if (this_block_needs_to_have_comment_links($name, $delta)) { return comment links } } -------------------------------------------------------8<------------ in the comment module? Now the modules know what their blocks should contain, and on what else they depend on. Now you say it would be better if comment module would know what else depends on it (even contrib modules?). I doubt it. Goba
participants (5)
-
Gabor Hojtsy -
Junyor -
Stefan Nagtegaal -
Steven Wittens -
Tim Altman