Separating each 'book' for richer features

progress in this patch:

• removed author and license fields from book table
• added child_type to book table- not yet in form except as #value.
• changed schema and code so that the column name "book_id" is used in place of "bid" (which appears in the table {boxes}).
• refactored all load/insert/update actions to book_nodeapi in prepartaion for later stages.
• refactored all book and book_page form elements into book_form_alter in prepartaion for later stages.
• improved/simplified code for breadcrumb
• added menu tab/callback stub for admin/content/book/settings
• book_page nodes are no longer forced to be in a book, and may be added to/removed from the book outline like all other node types

the code's not fully baked, but selecting a default child type for each book is starting to work, and the admin page for seleting book types is halfway there.

chnged all instances of code of check for 'book' type to checking against the types set in the admin interface.

After thinking more about this I think that that the approach of forcing all nodes of a given type to be in the "book" class is not the way to go. The code is already pretty well set to allow individual nodes of any type to be added to the "book" class, and I don't see any real advantage to the per-type approach.

So, here's what's next then: eliminate the book node type. Change the code to check in other ways for membership in the "book" class (e.g. nid == book_id). figure out a UI/workflow for adding/removing nodes into/from the "book" class. This last I'm unsure about and would apprecaite suggestions.

the only downside I can think of to this is that in book_nodeapi($op='load'), it becomes necessary to run two simple queries (or a LEFT JOIN?) instead of one query for every node since there is no way a priori to know (based on the type) that the node is in the "book" class.

Another question- should nodes of the book_page type be requred to be in the book hierarchy?

Note that this is somewhat full circle back towards the existing book module, but will provide a better UI (in terms of moving nodes within a book), the flexibility to desognate an alternate node type as the default child page, and a TOC for each book. In addition, this positions the module to be used by a contrib access control module to set permissions on a per-book basis.

Ok, this is wroking reasonably well now, but needs some additional cleanup and thought about the settings page (perhaps to set default TOC depth, & default child page type for nodes moved into the "book" class).

with this patch, we're back to a single node type being defined, book_page. book_page nodes are just like page nodes - they are only added to the book hierarchy via the "outline" tab or through a link to add a child page. They also serve as the defualt child page type.

A node that's in the book hierarchy can be "promoted" to be a "book" via a checkbox on the node edit form (I'm not sure if this is the best UI- comments welcome).

A node that is a book can be demoted similarly via a checkbox in the edit form and go back to being a regular page in the book hierarchy.

@magico - certainly intersting, but at this late stage I think any added access control needs to be though an add-on module

@OGovinda - the symbols there are just the default Drupal menu symbols. these can be changed in the CSS.

added administrative settings to choose the default TOC depth and child type. The book_page type goes automatically to book_id == 0 (getting back to be more similar to 4.7 book.module), but can be immediately promoted to be a book via the check box on the form.

Also spent a while updating to conform to this patch: http://drupal.org/node/68418, and got hung up on this recent (inexplicable) change to node.module:

$type_url_str = str_replace('_', '-', $type->type);

Please review.

patch #9 doesn't apply becuase I had diff with the wrong CVS tag. Attached patch should apply cleanly to book.module v. 1.387

improved permission checking - prevents users from using the query string to add posts to a book unless the type matches the child type set for that book.

For testing purposes, attached script uses the new form method for node submission to create book pages that are associated with the pre-existing books. Make a few books before running this.

attached patch fixes 2 minor bugs -
1) the "Make this node into a book." checkbox was showing up on the outline page, where it had no effect.
2) ran in the opposite problem with the node type in the node/add/type URL and had to convert back with $type = str_replace('-', '_', arg(2));

Also restores the 4.7 behavior that users without "create new books" permission cannot create a top-level "independent" book page.

use this one instead of #13

updated for HEAD. Moved functionality back into book_nodeapi (per http://drupal.org/node/68418), cleaned up code and comments, and fixed minor bugs in functions select_book_page_parent, and book_page_menu_tree.

For testing purposes, there is a script: http://drupal.org/node/65319#comment-127289 for creating nodes before applying the patch to test the update function.

Attached is a script updated for latest patch/HEAD for creating book_page nodes, including some put into the "book" class.

test site updated with patch#15 and new sample content: http://book.wolanin.net/

the test site seems accessible now- that host is not 100% reliable (I'll be switching as soon as the contract is up next month).

FYI, for those reviewing the code and thinking about how this enables new possibilities. In a subtle way, per-book permissioning is already available in this patch. Here's how: with the new create-content-types functionality in core, you can create multiple simple content types. If you set a particular type as the default child page type for a single "book", then only users with the permissions to add/edit nodes of that type will be able to add/edit pages in that book.

@kpatrickdj - this was a proposed feature for the current development cycle. This patch was not accepted, and as you noticed no longer applies to the current HEAD.

In a few weeks, I may try to resurrect this work into a replacement for the book module for 5.x. Feel free to try to update the patch if you wish.

maybe for 6.x. thinking about a comment on the previous thread along the line of "why not show a full TOC for every page", a better way forward might be to just add 3 new columns to the book table- book_id, child_type, and toc_depth. Obviously, for non-admins the values for a child page would just be inherited from the parent, but this would provide great flexibilty in structuring a book.

http://drupal.org/node/146425