This module builds on the concepts of the original book.module but integrates a more user-friendly parenting interface as well as the ability to assign weighting capabilities to non-administrator users. Those with javascript enabled and permission to create and/or edit book pages will see a new split dropdown scenario with top-level books listed above and member book pages below. This allows users to focus on the book at hand without having to scroll through all pages from all books before finding the correct placement for their page. Those without javascript will see the original parenting dropdown on book page add and edit screens. In addition, a new access control permission is introduced to allow selected users or user groups the ability to see the weights of existing documents through the parenting interface as well as set the weight of the current document. For administrators, book plus also offers the capability of universally controlling the depth of the tables of contents (show one level below current, show two levels, etc.) via administer->settings - now with javascript interactivity!
| Attachment | Size |
|---|---|
| drupal_bookplus-4.6.0.zip | 18.97 KB |
| drupal_bookplus-4.7.0.zip | 21.65 KB |
Comments
Book Plus module
I think that this is a brilliant idea, something that is sorely needed in Drupal. In fact, a long time ago I posted a discussion of the notion of book "leaf depth" on the Drupal site. At the time I was a complete PHP and Drupal newbie and had no idea of how to do such a thing - even now I would hat having to try to invent the Javascript.
However, having taken a quick look at this implementation, I have some suggestions to make:
1) The labels "book" and "parent" within the "Book/chapter relationship" are rather confusing. IMHO, it would be better to say, for example, "Book" and "Parent chapter within book" - better still to say "Parent chapter within book xxx" where the "xxx" changes dynamically depending on your selection of the Book.
2) The inclusion of the "top-level" option in the "Parent" drop-down list seems to me confusing, indeed incorrect. If you have selected in "Book" an option other than "New book" then by definition the page you are creating is a chapter and not a new book, hence "top-level" would be an inappropriate choice.
3) It's a great idea to include a "maximum depth" for a book - but how about making it possible to set a maximum depth per book?
4) Finally, would it not be possible, rather than replacing the entire book module (I hate doing things like that) to create a "bookplus" module which would use nodeapi to create the Javascript that would disable the standard Book parent drop-down, replace it with the other drop-downs, and so on?
Breaking it down...
I agree that the labels "book" and "parent" may not immediately ring with all users. However, the pre-existing label was just "parent," and the way some people structure their documents I don't know of a better term. A node that's five labels deep in the heirarchy is no longer a chapter, nor is its parent...if we use the physical book paradigm. And unfortunately, the Drupal mantra seems to be "don't depend on javascript" as some users have it turned off entirely...so I've tried to use it sparingly (turn off javascript and revisit, you'll see the original structure and terminology).
Only certain permission levels can see the "New Book" option. And like you said, if someone wishes to create a second-tier page, then just selecting the book should place it correctly. However, for continuity with the non-javascript selection format and to have something display in the lower box, "top-level" was recycled. The terminology could be replaced with something else, but then you'd have more disparity between the javascript and non-javascript interfaces. I wasn't the one to make the choice originally, but I could see its usefulness at the time.
"It's a great idea to include a "maximum depth" for a book - but how about making it possible to set a maximum depth per book?" That could definitely be useful, as well as a javascript option to dynamically expand/contract the display (though that'd be more complicated!). One or both of these could be in the next update.
I agree - I hate replacing one module with another that does essentially the same thing. However, nodeapi is only additive, not subtractive (to my knowledge). I know how to use it to add features and options to forms, etc., but I don't know how to use it to interrupt a specific section of output from one module. In addition, for things like the book tree expansion, I don't think there are any hooks that book plus could even utilize (additive or subtractive). The only option was to write a new module, but for the sake of sanity give it the same name (so it could automatically "upgrade" current books instead of requiring a bunch of SQL node type updates and CSS changes). There's always including this code into the main book module...maybe once 4.7 is officially stable and released?
Well that was more complicated...
I recently tried adding the ability to change table of contents depth per book. However, that turned into a real user-experience problem. The only way to do it so that everyone would be satisfied was to include a new "TOC Depth" control column for each book under administer->contents->books. That allowed finite control over how expanded the table of contents were for each book, chapter, subchaper, etc. However, it was overwhelming, and made the state of things unpredictable for new nodes. Should new nodes show a TOC depth of 1 or 150 (do you set a global default, a default per-book, etc.)? What if you change your mind and want all book nodes to have a TOC depth of 2 (the current interface doesn't allow for global changes). If you have a collaborative documentation system and your users see that you can control TOC depth per node, what if they want to wield that level of control themselves? And how do visitors comprehend navigation that has no standard (some TOC's being fully expanded, others being fully contracted, and the rest at some in-between state). It's probably better to just explore the javascript alternative instead as a complement to a global control.
Bug with next link
The next link in this module does traverse the hierarchy back up. For example, in this hierarchy:
book
__child1
____grandchild1
____grandchild2
__child2
the next link of grandchild1 would point to grandchild2, but the next link of grandchild2 would be missing. I believe the intention of the code is to show a link to child2 as the 'next' link of grandchild2.
This can be achieved by changing line 725-727 into the following:
// No direct child: get next for this level or any parent in this book.
$path = book_location($node); // Path to top-level node including this one.
$path[] = $node;
Indeed.
I see that change has also been made in the core api as well (http://api.drupal.org/api/4.7/file/modules/book.module/source). I made the fix here, too. I've also updated the code to include javascript-controlled, interactive tables of contents. The option is now available in the administrator settings area. If you're interested in upgrading, just make sure to check out the readme file.
problems with javascript on Firefox
I've been testing out bookplus (please add it as a project on drupal) and ran into a problem with javascript on Firefox. Where even though the use interactively option is selected, clicking on the arrow results in a clicking noise and nothing else. I should add that Opera and Safari appear to be working and Konquerer sort of works as it expands, but wouldn't constrict.
error in book.js
Thanks for this module. I thought I was going to have to create the same thing myself!
I think the part in the book.js for the 4.7 version that reads :
img src=\"/modules/book/spacer.gif\should be:
img src=\"modules/book/spacer.gif\My site is in a sub-directory and the url to the spacer.gif wasn't rendered properly.
Same problem, different manifestation...
Brad and biohabit - you guys ran into the same thing. The problem is the way the new Drupal interprets paths. If I removed the slash, it wouldn't find the spacer on my install. Consequently, there would be no bullet overlay where I could capture mouse clicks. I've tried to replicate the functionality using only a CSS "toothpick" instead of a spacer image - hopefully that is a more universal solution. Download the zip file again and overwrite what you have to make the change (make sure you backup your old files first, though). As to publishing on Drupal, there's an issue with this being an overhaul (not a simple patch) and replacing a core module...
Drupal 5?
I really liked to use your module with my old drupal 4 installation.
Do you have any plan on updating this module to drupal 5?
Yes...that's the plan.
Yes, I'm currently working on the Drupal 5 version, but I can't definitively point to a date and say "I'll be done then." The module isn't dead, though. Keep coming back - eventually there will be a v.5 posted.
So is it?
...dead after all? Pretty bad if so :(
Just made a dozen of books with nn chapters for each, looked at the dropdown, slowly smoked, said 'yeah...', and came looking for a book parenting module.
Bookplus seems to be the only one. I mean seemed.
Not entirely dead...but definitely in a coma.
Yes, future development for the book module is on hold for me - I was hoping that the official developers would integrate what I assembled, but I guess they did not. In my case, I found that switching systems opened up a lot more possibilities. I moved from book.module to relativity.module with book pages. For a developer, switching to relativity is trivial - it just requires moving the parent-child relationships to the relativity table and renaming the node types. It requires some mySQL knowledge, but allows a lot more flexibility once it's done - unlimited page/chapter associations, multiple children, multiple parents, etc. The issue of the dropdowns for choosing a parent goes away because the interface for associating content is completely different - it doesn't live in the edit screen, it lives in the footer of the view screen.
Thank you
Thank you for the advice on the relativity mod. That book dropdown made me a worse person than I actually am already. Even my cat sits in a far corner and is not talking to me.
As to the why Bookplus was not included -- that's actually strange. It definitely makes the book gui much more convenient. The devs either have no cats or books.