Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.You know how those cliche summer teen movies always start with the nerdy girl that no one notices, and the first half of the movie is all about the work she does and how she gets ignored by the cool kids? And then she takes off her glasses, and bam! Everyone notices that she's been gorgeous all the time?
That's book module.
Let's take off its glasses.
This patch adds two columns to each book record -- 'children' and 'navigation' and enables the following new display options for each page that's part of a book:
Child page display options
- No display (in which the book outline is only used to generate sidebar blocks and breadcrumbs
- List of titles (the default display for book.module)
- Teasers (outputs teasers for the current book page's children using node_view_multiple(), just like the default front page
Navigation display options
- None (don't show any sibling/parent links)
- Previous/Next/Parent links (the default navigation style for books)
With these two options, book module can be used to build relatively simple dynamic listing pages using nothing but core. For small sites, this can make simple staff directories, product listings, and nicely-formatted topical index pages much much easier to build. It's an incomplete concept -- the idea would require ironing out how to set defaults for children based on the parent's display options, for example. It would make a lot more sense to use the entity field management screen to control this stuff, but book module is a very awkward fit for FieldAPI, as it applies across bundles arbitrarily. Further refinements are definitely needed. In addition, the children of a book should probably be separated out into a dedicated chunk of content, just like comments are right now, but the fact that we use hide() and render() tricks in node.tpl.php to order things makes that very difficult.
But! It's an interesting first stab at adding some very useful functionality to Book module, making it more useful as a general site building tool. Anyone think it's a direction worth pursuing?
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | book_display_options-1050664-19.patch | 7.61 KB | langworthy |
| book_child_display.patch | 7.58 KB | eaton | |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedWhy just teasers? It should allow any view mode.
Comment #2
arianek CreditAttribution: arianek commentedInteresting - subscribing mainly out of interest of how this might impact the online docs for D.o (which are all in book at present).
(Tangentially a tiny bit related - Johan from Node One made a great Book Outline mgmt prototype using contrib in response to #995370: Want the ability to create multiple outlines/maps - video walkthrough is awesome: http://vimeo.com/18460761 - just in regards to improved book module features for D.o.)
Comment #3
eaton CreditAttribution: eaton commentedI think that's a great idea, actually -- one of my early ideas was to implement a separate view mode called 'book index' that would let people customize it explicitly. I didn't end up putting that into this first pass, though -- it will definitely require some discussions about workflow and presentation if people think it's worth pursuing.
It wouldn't have any impact immediately, at least not in the form of this patch. It still defaults to the same behavior/markup/structure as the current book module, just adds the ability to hide the pager-style navigation links, hide the list of child pages, or display the list of child pages as teasers.
The idea was to provide some different options for presenting the information that Book already tracks, rather than muddle with the structure itself. I'm sure there are a lot of other potential enhancements that can be made along those lines...
Comment #4
Crell CreditAttribution: Crell commentedTisk tisk, eaton. You of all people should know better than to use int constants to define a set of options like that. As bangpound notes, view modes would be a good fit here, with "title only" being a new view mode, perhaps? There's already a module somewhere that lets you define arbitrary view modes. *Any* view mode should be usable here. "N is the only number," remember?
Also, the update hooks should now be starting at 8001. :-)
Comment #5
Crell CreditAttribution: Crell commentedOh yes, and +1 on the concept, and ROFL at your introduction.
Comment #6
rfaySo much to be done for book! Love for book! Love for book!
Comment #7
eaton CreditAttribution: eaton commentedWell, the initial plan was to mirror the behavior of the front page as closely as possible: to provide the simplest possible choices that would result in the most flexibility. ;-) The 'titles with nothing but links' mechanism would at least need to be a special case to preserve the existing book.module behavior.
But, as I said, it's just a first pass and it is set to 'Needs work'. ;-) I'm mostly interested in whether people think it's a promising possible direction to pursue for enhancing core. Today, people have to either make do with the 'published' flag or jump to the Views module. Allowing Book to have some output flexibility would make it a good swiss army knife for structural buildouts on small to midsize sites.
Anyone disagree? Agree?
Yes, I'm totally trying to beef it up a bit so that it can be used as part of a more feature-filled Standard Profile later in the D8 cycle. ;-)
Comment #8
rcross CreditAttribution: rcross commented+1
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedEaton: I agree that the outcome is a good one. I'm not sure that book should provide its own view mode, especially if I can choose a different view mode for each display of child pages.
Crell: A "title only" view mode? It could replace node_title_list().
Comment #10
eaton CreditAttribution: eaton commentedInteresting, a title-only view mode might be a little specific, but 'Listing' or some other sort of special purpose display mode that's intended for super-truncated lists might be interesting. Right now, our display modes don't have the flexibility to do that cleanly -- the title is handled by the node.tpl.php file, full stop, end of story.
I do agree that picking from currently available display modes is better than providing a hard coded one, though. Is there a best practice for hiding inappropriate modes like RSS and Search Index from the list?
Comment #12
yched CreditAttribution: yched commented"the title is handled by the node.tpl.php file, full stop, end of story"
Yup, that's the main pain point that was (scarily and intentionally) left out of the 'view modes' work in D7. That's why 'title' is not present as an 'extra field' on the 'display fields' UI page - you can't reorder it or hide it, its position is hardcoded in tpls (was one of the issues for 'title as field').
re : 'title-only' view mode :
Hm. but view modes are currently configurable. Nothing stops me from adding field_foo to the display, and the view mode name becomes plain stupid. View mode names should indicate a context or a 'flavour' rather than hint about actual content.
We might find we have a case for 'hardcoded, un-editable view modes', but I'm not really convinced. In this case, a "terse" view mode, in addition to teasers, might be more appropriate.
One other thing D7 left aside is the ability to have display settings for 'extra fields', similar to formatter settings for fields. Would apply nicely here : pick view mode for child pages, book type by book type.
Should be possible with direct form_alters against the 'display fields' form, but Field UI doesn't provide any ready-to-use construct, like it does around hook_field_formatter_settings_form() and _summary().
Comment #13
yched CreditAttribution: yched commented(Drifting off topic)
I see the 'manage display' page as one of the nicest flexibility wins in D7 (esp. when adding D7 field groups to the mix). Will rocket once a) more things are 'fields', or b) it lets you do more things with 'non-fields'.
Still, it more and more overlaps (but still largely lags behind) the flexibility privided by Views' own 'fields' settings. Convergence ?
Comment #14
arianek CreditAttribution: arianek commented@eaton (re: comment 3b) roger on that. i think i missed the point a bit. ;) will keep following none the less since i end up working with book more than any human probably should!
Comment #15
yoroy CreditAttribution: yoroy commented<3 a more flexible book module. Using view modes would rock. (off topic: I want 'sticky' to be its own view mode as well). I guess improving the pager and the book navigation block are out of scope here, but they'd have to be improved as well.
There's definately room for an outliner tool like this in core imo. Can we come up with some nice example use cases? "For small sites, this can make simple staff directories, product listings, and nicely-formatted topical index pages" is a good start, but immediately rings bells on 'sorting, how?' for me.
Anyway. +1 on this.
Comment #16
yoroy CreditAttribution: yoroy commentedtag
Comment #17
arianek CreditAttribution: arianek commentedRe: #15 Just wanted to make sure y'all were in the loop on the multiple book outline issue http://drupal.org/node/995370#comment-4248512 especially has some pretty related ideas going on.
Comment #18
eaton CreditAttribution: eaton commentedThe simple answer for sorting is (IMO at least) "Click the edit link, and drag and drop the outline items to reorder them." It's a terrible match for big lists of content, but it's really ideal for a lot of things that end up being curated anyways, like small sets of products, staff directories for small businesses, etc.
Comment #19
langworthy CreditAttribution: langworthy commentedThis is just a re-roll of the patch in the OP. Seems to be some issues when updating outlines (settings sometimes don't stick)
Comment #32
fjgarlin CreditAttribution: fjgarlin as a volunteer and at Drupal Association commentedAs pointed out via slack by @smustgrave, closing this issue as a duplicate for #2711933: Book navigation cannot be moved/removed on node display.
Comment #33
drummThe issue summary was incorrectly set to full HTML, correcting it to filtered HTML.