Any node may be included in the book. But alas, it may appear only once. Thats so unDrupal. This request is to allow the same node to appear in multiple places in the book, similar to the vocabulary system.

Comments

moshe weitzman’s picture

Kjartan says that the plumbing is in place to handle this. We just need to alter the UI

moshe weitzman’s picture

I've done a bit of hacking on this with good success. Hopefully some one else can finish the job.

As a proof of concept, I changed the primary key in the book table to a normal key. Then I added a row in book table for an existing nid with a different parent. Everything displayed as expected (including printer friendly), so thats a good sign.

In order to complete this task, we need the following:

- break down current book table into book and book_hierarchy. The nid field should appear kin both. The parent field should move to the hierarchy table. Then change all queries to use the right table. Also write a conversion script for existing sites.
- adjust _form() hook we allow multiple parent nodes to be selected
- handle the form() submission so we can save multiple parents for a page

nernst’s picture

Is the code for your experiment in the sandbox? I'm interested in a related feature, allowing the same node to appear in multiple books (the inverse relationship, I suppose). Seems simple enough to do, using, as you say, a two table approach to indicate book hierarchies e.g. node 345 has parent 222, node 345 has parent 499, etc.

Neil

moshe weitzman’s picture

i didn't write any code. I just changed one index in the book table and added a record manualy (as described in this issue) ... you get to finishing the job. see my 'next steps' paragraph.

nernst’s picture

Ok, I'll give it a shot. I think the book_hierarchy table should also contain 'weight', however, so that people can specify the weighting per book and not per node.

shane’s picture

Has this feature died? Is anyone still working on it? Just was curious if anyone had made any headway on this. I like the book module a lot and use it extensively. Would love to see it "updated" to be as flexible as the rest of Drupal. TIA.

mcduarte2000’s picture

Still nothing?

I also needed this so much...

puregin’s picture

Title: Let node appear mutliple times in a book » Let a node appear multiple times in a book

Correcting the title. Djun

jorisx’s picture

So this is not working yet...
I've just posted a question about this: http://drupal.org/node/93870

It would be graeat to have this feature working :-)

add1sun’s picture

Version: x.y.z » 6.x-dev

I'm very interested in this feature getting in. Specifically I am thinking about it in terms of the d.o handbooks. Some recent discussions around some new paradigms for documentation has introduced the idea of leading a new user through the documentation based on specific goals they may have see Create First Steps Handbook issue and SoC Getting Started guide request. An example of this is the SoC Getting Started with Drupal Dev guide. The intention of the new guide would be to highlight and give context to areas of the handbook that would be most pertinent to someone familiar with PHP and coding but not Drupal. Instead of rewriting material that is already well covered in the existing handbooks, the plan is to link to those "outside" resources. The problem with this though is that as someone reads the Getting Started guide and they click a link, they are then taken out of context and plopped down in the book that the resource resides in. This disrupts the "flow" that a child or sibling page would provide. If those pages could be assigned to both their "main" book (e.g. CVS) and also to the Getting Started book, it would provide a real tool to be leveraged by the Drupal documentation team.

If folks think this is a worthwhile effort, I'm willing to try to picking this up and making something happen with it.

Tresler’s picture

I have t wonder, if we're talking about weight and multiple parents for book nodes, does it make sense to just have a "Book" vocabulary created when a new book is created. Then instead of a book heirarchy table, we just use what we have.

I'd envision this working similar to the way you can put a single image in multiple galleries with image.module by manipulating the "Images" vocabulary.

Not sure how book module works currently (I think its CCK as of 5.0?). This would also involve putting an entry into the taxonomy system for every new page, but I think that can be the key (not the title, obviously).

thoguhts?

Senpai’s picture

I'd have to say that a taxo entry for each new book page would become exceedingly tedious, given the amount of new teaching materials I'm planning to create with this tool when it finally gets done. The drupal.org First Steps guides are impossible to correctly implement without this new tool, however, so I hope it gets done soon.

Mac Clemmens’s picture

Version: 6.x-dev » 5.1

is "Let a node appear multiple times in a book" evolving at all? I think it would be a great idea. Can it be done by installing CCK?

StevenPatz’s picture

Version: 5.1 » 6.x-dev

Features go in development.

add1sun’s picture

This issue will probably have to wait until the larger changes to book/outline in core are determined at this point. There are ideas on those changes but so far not a concerted effort at this point to get it into 6.

StevenPatz’s picture

Version: 6.x-dev » 7.x-dev
gmasky’s picture

Title: Let a node appear multiple times in a book » Let a book page appear in multiple books

I am trying to link a book page to multiple books.

Can this be done and how?

With categories, I can link a node to multiple categories.

Thanx

glass.dimly’s picture

Version: 7.x-dev » 5.x-dev

Gee, this is a really important feature. I hope somebody really smart is making this so, and if they were making it so, it would be great to have a module that would do this.

How have people been working around this in their sites?
-Jeremy

Update: here's the work around for 5.x: http://drupal.org/node/93870#comment-883186

mooffie’s picture

Version: 5.x-dev » 7.x-dev

By marking this 5.x you're effectively killing this issue. 5.x gets no new features.

mikeschinkel’s picture

Version: 7.x-dev » 5.7

What's the rationale for not allowing 5.x to be updated? I've got a 5.x site that needs this (and can't be upgraded because needed modules are not ready for 6.x) and depending on how hard it is I might be willing to code it.

Nick Lewis’s picture

Version: 5.7 » 7.x-dev

The policy is to not add new features to previous versions of drupal, only security/bug fixes can go into versions older than 7.x. Its not that we don't care about users in previous versions, its that we are trying to do the most with the limited development resources we have. Drupal 5.x is a stable release -- adding new features would destabilize it (it would, for example, screw up sites that had custom work done to their book module). Destabilizing what we call a stable build is a great way to ruin our reputation.

I feel ya on upgrading pains -- but that said, I learn a lot of new things about drupal everytime I upgrade modules -- its good for building ninja skills. When you begin to get comfortable with 6's apis, you will never look back to the dark days of 5.x....

As far as this patch is concerned, I think book pages should be able to reference pages in other books (e.g. 'related pages') in core, but I don't think a book page should be able to have two direct parents. The breadcrumb/pathauto/display issues + duplicate content penalities in google + interface complexity make it impractical. You'd need to add weights to parents, as well as children to make it work -- lots of moving parts. Having a second class relationship available to cross link content would be a great idea however, imho. That's sort of what taxonomy does -- but taxonomy is more like a bucket, where as a book should look like a pyramid by design.

tierecke’s picture

But is it going to go into Version 7?
If not then I guess that people won't be so loyal to the destabilization principle...

It's such a basic feature!

bsherwood’s picture

+1 subscribing.

It's been a couple months, any word on this?

ezra-g’s picture

I wonder how we would accomplish this now that book.module uses the menu system to store book hierarchies. Would we have multiple menu links for the same book page?

svihel’s picture

Subscribing

pxlar8’s picture

subscribing

domidc’s picture

The trees module which is similar to the book module, it does not allow a node to appear multiple times in one book but it does allow a node to appear in multiple hierarchies.
http://drupal.org/project/trees

pxlar8’s picture

Subscribing.

WorldFallz’s picture

Version: 7.x-dev » 8.x-dev

didn't make it into d7 either.

Nick Lewis’s picture

I disagree that's a basic feature - i actually think its a feature that confuses matters.
How does it help visitors to have 2 books that may or may not have the same pages?

How does a visitor feel if they are looking for information and start going through books only to find that these books have the same pages and or not...

I believe a book page should be a book page in the physical sense. I could see a feature for citing related book pages - but i feel like having a book page in multiple parents 1. complicates the interface 2. encourages bad practice 3. is a sign of needing to rethink how you organized content.

I'm open minded about this just saying it sounds like something that encourages a people getting themselves intro trouble and you can always copy and paste... and i haven't heard a valid use case for the feature.

jspotswood’s picture

Here is an example which I am currently experiencing which would benefit from this feature.

I have two books, one called "About" the other "Contact Us".
The About book contains content about the organisation including information about the executive and office bearers. Now the people in these roles change every year or so, thus the content is not static.
The Contact Us book contains information on how to contact people in the organisation including emails and phone numbers. The email addresses can be made generic, so it does not matter which person is in the role. However the phone number information relates to home phone numbers of specific people in the role (potentially changing every year).
Now I HATE having duplicate information on a web page (must be the SW Engineer in me). Thus I would prefer as people move in//out of roles to only change this information in one place. However the information really belongs in two places (more specifically two different books). While I can simply reference the content using a link, it would be cleaner to have the node with the name and phone of the executive and office bearers within two different books.

I do recognise that with proper website organisation, that this functionality requirement should only need to be used infrequently. However its implementation would allow for cleaner websites in certain appropriate use cases.

zchandler’s picture

Subscribing

effrenatus’s picture

Here's another example:

I'm working with a professor who is trying to collect epidemiology course material. He would like to allow multiple authors to contribute content, and then allow editors to assemble content into courses. Re-use of book pages would be fantastic for this purpose. This project seems to need a way to create pages outside of the book context, and then a method for browsing content for the purpose of assembling books ex post facto. End-users should be directed to a URL that renders a single book, ignoring the larger body of content, so that a book becomes its own Web site.

I'd be overjoyed if someone could explain how this can be done in the current Drupal environment. My small team of Drupal newbies (we're all students, trying to learn this as we go) feels a bit overwhelmed.

kay_v’s picture

Hi all -

Worth noting that the question is not about content creation or storage; it's about content access. Reasonable that site owners have the freedom to provide content access from whatever location they wish on their site, no matter how they created the content. (Er, what's so special about Books that they should have an iron-fisted hold on the pages within them?)

Fortunately we have the Views and CCK modules.

@effrenatus, you might add two fields to your content pages: a "book title" field and an "order in this book" field. Set the number of values for these fields to 'unlimited.' Then, if you know how to use Views arguments, it's a pretty simple matter to assemble your multi-sourced books based on these fields.

If your team isn't ready to tackle arguments, for now you can create a new "display" in Views for each book title, filter on the "book title" field and sort on the "order in this book" field. You can build the various Book-like menus with Views attach. (And why not convince your authors to write their pages as very short snippets of info? with a little more work you can let registered users assemble and save their own study guides - your team would never have to buy their own drinks again).

Sounds like an interesting project. Best of luck with it, and give a shout if you need additional insights.

Kay
ownsourcing.com
Drupal training

kay_v’s picture

@jspotswood, have you experimented with User Profiles? It's part of core, and lets users update their own contact (and other) information.

Once the contact info is in the profile, you can access it with Views. Not sure how you are building the pages you mention, but if you are creating lists of people, there's a good argument for creating User Profiles, even if the people are not users on your site (or at the very least, create a node per person with individual fields), and create the various displays of the info with Views.

Hope that helps, and feel free to get in touch if you need more info.

Kay
ownsourcing.com
Drupal training

dennishu’s picture

I'm building a training site with similar requirement as #33. The problem with using View as mentioned by #34 is that all the hierarchy in a book will be lost, I assume. And I think #21 is right, it's not a good idea to have multiple direct parents for a single, which will confuse the system too much.

My current thought is to have a "clone" feature for nodes. I can create a node and specify it's a clone of another node. Their relationship will be stored in a clone table. Then using hook_nodeapi(), any change made to the master (or one of its clones, if you will allow) will be cascaed to all its clones.

mariusz.slonina’s picture

I would leave the single book hierarchy as is, and use current fieldable D7 taxonomy for "books", which gives the power of two worlds. The separate issue is the order of nodes in given term (i.e. nodeorder module, which is not ported to D7 yet) and eventually the author of this specific term (as in proof-of-concept module of mine, https://github.com/mslonina/d8tags). Now, we create a vocabulary "books", and we allow users to edit own tags. And that's it! The user creates an article, and choose a "book" from, for example, autocomplete tags field. With FieldsAPI we can put anything to terms, let's say a cover image or so.

jhodgdon’s picture

This is being worked on at #995370: Want the ability to create multiple outlines/maps (non-core at the moment).

Itangalo’s picture

soobscrybing

jspotswood’s picture

Thanks for the response @kay_v. Although I am a bit late reading your response!
It is good to know about capabilities of the User Profiles, however in my case most of the people never do anything with the website other than read the content provided. So it would be up to me to create and update profiles. I will keep this ability in mind for another website I am currently doing for a different not-for-profit organisation.

Dood59’s picture

subscribed (d7)

Melissamcewen’s picture

subscribing

JuliaKoelsch’s picture

Subscribing. I'm building an e-learning site with Organic Groups. Each group has a curriculum that's built using a book. I'm using a book instead of taxonomy or views because I'm using the Certify module, which depends on the Book module. Some pages of the books will be different, but some will be the same. I'd really like to be able to reuse pages and not force my client to create duplicate content.

camt’s picture

Drupal 7:

I might be able to offer a bit of funding if someone is able to develop this feature. Happy to see if we can work out something for either you to custom develop it for me, then post it back to the community for everyone to share.

I really need this created for a project that I am working on, and don't think the Trees Module will cut it. Our usage is that we are bringing many print publications online (aprox. 150) and some of the do have some shared content. Especially the back page where it has credits and ways to seek more info, this is shared across most, not all, of the publications. It would be great to create this back page once then share it across several of the books.

KenMills’s picture

I would like to share boilerplate pages across books created for each employee within a company. Some pages would be the same boilerplate for every employee and some pages would be personal pages specific to that an employee. Pages would be of varying content types. I plan to add rules and workflow for managing and approving edits.

Nick Lewis’s picture

Priority: Normal » Major

Posted by moshe weitzman on March 6, 2004 at 9:22am
Kjartan says that the plumbing is in place to handle this. We just need to alter the UI

Let that be a warning. Over 8 years ago this issue started...

Bumping priority. This is a very old thread. Today, in the 2012 --- I get requirements like this, over and over again. It's a either a defect or missing feature depending on perspective.

I don't know that the book module is where it should get resolved, but it should be bumped regardless. Is there a better component to assign this to? Perhaps one of the reference modules? (btw, will the real entity reference module please stand up!)

jhodgdon’s picture

For non-core (proposed) solutions, see #995370: Want the ability to create multiple outlines/maps. This issue is about adding the ability in the core Book module for a book page to appear in multiple books.

Anonymous’s picture

I write "installation manuals" for software. Often the same page is required for different software (because the particular instruction is simply the same).

In 2102 indeed, this feature is expected of Drupal. It saves many hours of managing duplicate content.

Another custom Drupal solution is of course: use a custom "book" Taxonomy (with hierarchy) alongside Nodequeue to do it yourself. I started out with Book, but Taxonomy/Nodequeue makes more sense to me now.

jhodgdon’s picture

For contributed module solutions, you might be interested in
#1549580: Track progress of building the Help/Docs System
We should have all the contributed modules for Phase 1 done this summer (except maybe the Workflow part, which you probably don't need anyway).

nbezaire’s picture

Subscribing. Has this moved any further?

We've set up Drupal 7 in an attempt to determine whether it's a viable option for our documentation set. Given the approach we'd like to take with our documentation, this is pretty important. We have a number of topics (nodes/pages) that contain information applicable to 2 or more books. It would make sense to build and update one page that exists in multiple books/hierarchies. Without this feature, we're looking at a lot of overhead.

jhodgdon’s picture

Right now I would say that the only way to do this in Core is to use core Menus to build your "Book" hierarchies (menus are basically hierarchical collections of links, which is pretty much what a book is?), and any generic content type you want to build for the pages. I would personally avoid the Book module, due to this fundamental limitation in how it was originally designed.

Nick Lewis’s picture

+1 to avoiding the book module. It should probably be removed, and replaced with something that enables the same functionality via "real" menu items in a future core release. ( :-/ though that resolution doesn't really help people who currently have this problem).

Wim Leers’s picture

Version: 8.x-dev » 9.x-dev
thejamesjones’s picture

Still not seeing a solution to this. Has there been any progress?

jhodgdon’s picture

If you'll notice, this is now a Drupal 9 issue, since no one proposed a solution for Drupal 8 in the form of a patch. And as far as building a better solution for drupal.org itself, that is now a separate issue (see comment #49 above).

Leeteq’s picture

Could this be done using multiple entities referencing ("representing") a book node?
(by "node" I do not mean a top level node of the "content type" book, but any page of any content type that happens to take part of a book)

mandclu’s picture

Issue summary: View changes

Along the lines of Leeteq's suggestion, I was thinking in Drupal 7 you could accomplish a basic version of this by creating a new content type with an Entity Reference field. Set the display on the field to show the full node contents. Set the new content type to be available for inclusion in books, and then within any book you can embed content (restricted it to the types you specify) that exists elsewhere, including other books.

If you want to get fancy you could edit the template for the field to include links to edit the original node (for users with access) and some other niceties. It would still be cool to have a module that would make this easy and provide all the extra window dressing, but this should be a workable solution.

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Priority: Major » Normal

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Active » Postponed

This extension is being deprecated, see #3376070: [Meta] Tasks to deprecate Book module. It will be removed from core and moved to a contrib project, #3376101: [11.x] [Meta] Tasks to remove Book.

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

This issue may be re-opened if it can be considered critical, If unsure, re-open the issue and ask in a comment.