Incompatibility with other modules overriding node view menu callback.

It's really hard to tell where this problem is occurring, considering this module is in a super-flux state and doesn't yet have an upgrade path from the 1.x version. Could you start from a scratch Drupal site and try to outline steps to reproduce?

Note: If the node comment module is going to depend on the comments module, it may be a good idea to make it a dependency. but that's another issue.

Yes we're aware of this, but right now we don't have an upgrade path from 1.x. If we marked the comment.module as a dependency but nodecomment was already enabled (which will be the case for all users upgrading), then Drupal unhelpfully disables the checkbox for enabling comment.module making it impossible to turn on. We'll fix this in #473350: Upgrade path from Nodecomment 1.

Just something to try before starting from scratch, visit admin/content/nodecomment-convert and make sure there aren't any pending conversions necessary.

At the moment nodecomment is not compatible with the delegator module in Panels 3. It is also possible that it may not be compatible with any other module that tries to take over the node view page.

Can you run this query and tell me the result?

select path, page_callback from menu_router where path = 'node/%';

I created a delegator module issue over here: http://drupal.org/node/486910 -- if that's your problem I hope to have a fix checked in later today.

The dependency issue is here: #486912: Nodecomment module depends on comment but that dependency is not in the .info file

You were just supposed to run that query and tell me the result. =)

From mysql command line or phpmyadmin

Ok, nodecomment_node_view is a good sign. You should be seeing the nodecomments with that set up. THe other option might be if something is wrong with your view. You might consider deleting the nodecomment view to revert it to what comes in the code.

I'm having this exact problem. There were working before installing Google Maps Tools. Can this module has something to do with this?

In the views panels, the comments appears if I pass a node as an argument but in the node view not.

I can add that running the query from post #5 returns:
path page_callback
node/% node_page_view

Hmm. That means that either nodecomment failed to change the node/% handler, or something else put it back. I'm not sure why, but it explains the problem. nodecomment makes this change in nodecomment_menu_alter() (and this piece of code only gets run when a menu rebuild happens).

this is what i'm seeing when i run the query from #5

path page_callback
node/% _revisioning_view

(i'm also not seeing node comments view OR the comment form itself)

ok - so for me i can confirm that i'm having a conflict with the revisioning module .. when i disable the module and rerun the query from #5 I see "nodecomment_node_view" and nodecomment starts functioning as expected

I just found this thread about a conflict with panels and revisioning that looks very similar
http://drupal.org/node/519924#comment-2640810

i'm starting to get out of my comfort zone here but it seems like in "nodecomment_menu_alter" the module isn't able to take control of node/%node because revisioning already has?

is there a way to let these 2 modules play nice together? i definitely need revisioning and would love to get nodecomments working for a new forum we're rolling out

thanks!!

I just updated to the latest version of Views 6.x-2.10 (2010-Apr-09) and Nodecommeent 6.x-2.0-beta3 (2010-Jan-29)
and I get the current result as seen on the attached jpg.

I haven't been able to get these two modules to work together since Node comments 6.x-2.0-beta1 and Views 6.x-2.6.

hope this helps.

Is there a way to try to fix this?

Just wondering if there is any active development/support going on with this branch?

Up in comment #24 I think I'm getting closer to the root of my problem, but I'm not really sure how to proceed. I really need revisioning installed to support other workflows I already have going on the site. Ideally I would like to be able to use revisioning on the nodecomments content type.. but in the short term I'd be happy to let that go just to get nodecomments working.

Is is possible to somehow allow nodecomments to take over the node/node% for certain content types and allow revisioning to control it for others

(sorry if i'm not articulating this correctly)

There's no active development atm, and the only support you can have is from other users.
Also, since it's incompatibility between modules, this is not critical. Nodecomments itself works fine.

Thanks Crea .. agreed.. not critical .. although for me its feeling critical :)

Is this conceptually possible? (to get these 2 modules working together)

Although not perfect, I don't even really need revisioning for my nodecomment content type or the source content type (forum in my case) .. but I do need revisioning installed for workflows dealing with other content types.

I'm more than willing to try to dig into it myself, but I'd be grateful for a little guidance. Are there other situations like this (conflicting node view menu callbacks) that have been solved that I could look to for a precedent?

I'm just not really sure where to start.

And I guess it would also be helpful to hear if this sounds like a really hard thing to fix .. in which case I'd fallback and use core comments.

Thanks !!

Well. When 2 or more modules want to work with the same path, there are several options:

1. Modules can check if the path is already overriden and give up early. This is what Panels and Page Manager module do. Then first module (with lowest weight) wins the race, other modules don't work.
2. Modules can have sort-of compromise who will process the path, and the "leading" module then is responsible to provide bridges for other modules. This is what Panels (actually Page Manager) does when it's overriding a path and then lets display panes containing information from other modules including those whose path was overriden.
3. Modules can declare each other incompatible and ignore the problem ;)

Thank you Crea - that is super helpful.

Given my skills I'm thinking while #2 sounds ideal, #1 or #3 are more what I might be capable of.

Are you suggesting in #1 that it might be as simple as changing the weight of nodecomments so that it "wins the race"?

Thanks again - I'll see what I can sort out and then report back.

Simply changing weights won't help - most modules blindly overwrite old values. Only module I know that is is smart enough about not overwriting is the Page Manager.

UPD: It could help, but in opposite way - by increasing Node Comments weight you can ensure it's hook_menu_alter() runs last. Problem with this approach is you still get single module working, thus you are hiding the whole problem instead of fixing it.

Want to add that I'm now (co)maintainer of Node Comments module so I am ready to discuss possible fixes. Though I don't see any easy solutions besides using Panels and let it be aforementioned "compromise" solution.

I just noticed that Node Comments also is careful about overriding menu callbacks:

  // Override the node view handler for our purpose.
  if (!module_exists('delegator') &&
      (!module_exists('page_manager') ||
      variable_get('page_manager_node_view_disabled', TRUE)) &&
      $items['node/%node']['page callback'] == 'node_page_view') {
    $items['node/%node']['page callback'] = 'nodecomment_node_view';
  }

So we are stuck: if we decrease weght of Nodecomments, it will override first but will be overriden by other modules which are not so polite. If we OTOH increase it's weight, it won't override because it's polite and careful ;))))
Because of this, changing module weights is not an option again.

I suggest the following: if another module needs own node view page callback, it's his responsibility to provide Node Comments compatibility (inserting nodecomment view, node comment form etc). It works this way already with Panels.

I guess what I'm thinking about is an approach based on content type.. that if a given content type is using nodecomments to handle its comments it would override the callback of other modules

its still not a real solution - the two modules would still conflict.. but it would be contained to a content type instead of site-wide

seems like something like this would give folks some more flexibility until a better solution could be found

"a better solution" already exists - it's called page manager module. And it does what you describe.
Regarding conflict with Revisioning: I think it's Revisioning module duty to play nice in this case.

okay - sorry.. starting to feel like i'm going around in circles..

so would you suggest switching this issue to revisioning? or starting a new issue with them?

if you could bare with me, i'd appreciate your help in wording the desire/suggestion.. would the request be to have them use page manager to handle their node view menu callbacks?

thanks Crea

You could borrow or copy Page Manager's "override anyway" flag.

function _revisioning_view($node) {
  if (_revisioning_load_op($node, 'view') == REVISIONING_LOAD_LATEST) {
    $vid_to_load = revisioning_get_latest_revision_id($node->nid);
    $node = node_load($node->nid, $vid_to_load);
  }
  // In node.module, node_page_view() is used to display the current, while
  // node_show() is used for any other revision. The difference between the
  // two is that node_page_view() surpresses the message that tells us we're
  // viewing a revision. That's what we use here because we have our own
  // configurable message.
  return node_page_view($node);
}

Note the last line: Revisioning blindly fallbacks to original node module page callback, even while it could override arbitrary one (including Node Comment's one). This information should be enough for Revisioning module if not to fix then atleast to workaround the problem. This is assuming Revisioning module weight is bigger than Node Comments one.

thanks Crea

I've created a new issue with the revisioning module:
http://drupal.org/node/796470

please chime in on that thread if what i posted could use further clarification

subscribe

Technically speaking, this is not a bug. It's a limitation of Drupal API.

3.x has this "by design" problem as well.

I have added a note to README. There's nothing more we can do about it.