Conflicts w/ Book.module

ooops...

Since this is supposed to basically replace the book module, using them together is not currently supported. Ultimately there's no reason why they shouldn't play nice together though, so when I get time, I'll rename my variables so as not to conflict with book. That's a reasonably high-risk operation and will need lot's of testing, so it probably won't happen right away.

How the hell is this happening anyway? What is causing it? Seems weird to me...

FYI if this is doing most of the legwork of Book.module, you might also want to check out custom_pagers, which can provide similar functionality to the book navigation stuff. Not exactly, but similar. It depends on CCK (and sometimes Views). Very good though.

Looks like book is checking for the presence of $node->parent to determine if a node is a book node (rather than looking at $node->type. So in theory, if I change the name of my $node->parent variable to $node->nh_parent book should ignore node hierarchy nodes. Unfortunately this variable name is pretty well baked into the module, so changing them is a somewhat risky think to to.

Renaming issue for ease of finding

per your last comment, i did a find/replace-all of whole-word "parent" => "nh_parent" in all files and it seems to have fixed the problem.. if it breaks, i'll tell you.

Thanks, let me know if that works out. And if you're able to upload a patch (http://drupal.org/patch) of your changes against the latest dev, that may help others in the same situation.

Thanks
Ronan

Hello, has anyone done the patch for D6? I tried renaming from parent to nh_parent but there was a problem installing node_hierarchy_views module... There was nh_children, nh_parent and nh_defaultparent in .install. So I'm not sure how many collision could be out there.

Please, if anyone has done something about it, tell us how to patch it... I've using Book and tried to do breadcrumbs and Paths and it was a real pain in the ass... A whole day wasted...

I'm interested in this module, but I need Book, too. Will it get fixed?

Subscribed!

Just out of curiosity, what do you need from Book that NH doesn't provide.

Since Ronan's intended this to be a replacement for Book, and IMO it offers a superset, it might be helpful for future development to know what people feel is missing. . .

first off, thank you very much for your module. For me the issue would not be that NH does not provide excellent functionality in comparison to the book module, it's an issue of usage. For my case I would be using the book module for content/posts only, i.e. for user manuals, for users to collaborate utilizing book. But I am looking into NH to "attach" bug reports, support issues, "custom comments" (although it would not be a comment, but a node) for node types. Also, I am running og with subgroups for og which utilizes book hierarchy to outline parent/child relationships with groups, so any conflict with the book module will probably cause issues. Below is a specific usage example, if you have any advice or suggestions, it would be much appreciated:

-------------------------------------------------------

In the case of bug reporting, here is what I wanted to achieve, and hope this is possible with your module.

Want to be able to attach/create a relationship between all content types and a content type="support issue". I am using flags to tag any node with a "bug report", then using flag actions to do two things:
1.send it to a "site support" nodequeue for admins to review.
2. redirect users to create a "support issue" (content type) in order to get specifics of the problem.

So what I need is to be able to create a relationship between the node flagged as "bug report" and the "support issue" (content type) node created with the specific info. So that each node can have "bug reports" attached to them. I would like admins to be able to view the "support issue" nodes(content type) in a separate tab for each flagged node. This way we can just go directly to the problematic node from our nodequeu and view the associated support issues all on the same page. Also, I would need to restrict access to viewing bug reports to admins only. After seeing if this is possible, the last thing on the list is to figure out how to redirect a user back to the original node after submitting the support issue. Basically I want to set this up to make it as easy as possible for admins and users, especially when testing a new site.

Also, I am running organic groups, subgroups for organic groups(utilizes book hierarchy/outline to set parent/child groups) views, panels, cck, nodequeue, flag - not sure it that is an issue or not.

I'm just a user, but I'd say that what you're looking at doing is wa a a a ay beyond the intention of NH. I would think something based around nodereferences (node relativity, node family, node hierarchy?) or even taxonomy might be more flexible - somewhere I saw a module that automatically creates a taxonomy term for every created node of a certain content type (in your case "support issue").

For what it's worth (about 2 cents), I can't speak for the OG subgroups (based on book, wild!) but I'd also suggest seeing if perhaps you could split your site up where the data model lends itself to that so you don't have so many interlocking dependencies between so many disparate modules. For example, your static book pages sound like they could stand alone. Easy to share user tables with multi-site config. . .

"somewhere I saw a module that automatically creates a taxonomy term for every created node of a certain content type" - sounds like the NAT module - http://drupal.org/project/nat

I haven't been able to duplicate this bug, with current versions of NH (6.x-1.2) and Book (6.9).
It's possible that changes in book.module already took care of the bug (at least for 6.x).

I suggest changing to 5.x or closing the bug (unless I'm doing something wrong and the links are not showing for some other reason).

I have a quite similar bug. In my case, the nodes organized with node hierarchy are listed in the "select parent"-dropdown-menu of nodetype "book" even if they are NOT nodes of type "book". I think this is also caused by the "isset($node->parent)" thing in the book module.

I started patching the book module, but because this is core and node hierarchy is not, it would be more useful to patch the nh module.
Anyone done that already (renaming "parent" to something else in nh module etc)? If not, I'll try it myself and post my results.

Copy & Pasted: This issue pertains to the 6.x-1.x branch which is now legacy and is over one year old. If this issue is not applicable anymore, please consider closing it. Otherwise, please update this issue appropriately. Will be closed in two weeks if no response.