Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
If I create a parent page with content type B, then "add child page" should create a new page of content type B. I would suggest the following code revision to line 54 of book.module. Or a new book module setting could allow a site admin to make this the default behavior.
// $child_type = variable_get('book_child_type', 'book');
$child_type = $node->type;
Comment | File | Size | Author |
---|---|---|---|
#22 | book-add_child-460736_22.patch | 3.36 KB | Samfall |
#3 | 460736_add_child_drupal6.patch | 884 bytes | JuliaKM |
#2 | 460736_add_child.patch | 854 bytes | JuliaKM |
Comments
Comment #1
lzs CreditAttribution: lzs commentedI'm looking for this too. It makes a lot of sense that the child node type should default to the parent node type.
Comment #2
JuliaKM CreditAttribution: JuliaKM commentedI'm running into the same problem. Here's a patch for Drupal 7 to fix this issue. It would be great if we could fix the bug in both Drupal 6 and 7.
Comment #3
JuliaKM CreditAttribution: JuliaKM commentedHere's the same one for Drupal 6.
Comment #4
JuliaKM CreditAttribution: JuliaKM commentedI'm not sure if I should split up this ticket. I'm switching to Drupal 7.x eventhough there's a D6 patch as well.
Comment #5
catchI'm not sure if this would get into Drupal 6 or not - could break current workflows. But it looks like a good change for Drupal 7 to me.
Comment #6
catchIf we do this, we should probably remove the book_child_type variable altogether - both in an update function and anywhere it appears in the UI.
Comment #7
chorrylan CreditAttribution: chorrylan commentedWhat if you want the book root/parent to be a different content type (eg a view or index) to the subpages?
An alternative that supports this might be to create variables of the form book_child_type_{bid}
Then switch the line modified in 460736_add_child_drupal6.patch above to
$child_type = variable_get('book_child_type_'.$node->book['bid'], $node->type);
ie.. look for a book_child_type for the current book and if found use it; otherwise fall back to using the same content-type as the parent;
Unfortunately I run out of drupal/php skills at this point so the only way I know of to set the relevant variable is using sql directly against the database.
Comment #8
catchchorrylan, patches get applied to Drupal 7 first, then backported if relevant. Changing version to Drupal 6 just means that less people look at it.
Comment #9
NaheemSays CreditAttribution: NaheemSays commentedDo we really want it to be this way?
I personally think it is good to have a choice as I have a set up where I have one content type for "covers" and another for the actual content in the book.
Comment #10
JuliaKM CreditAttribution: JuliaKM commented@nbz: I can see your scenario being useful as well. It sounds like you want a catch-all parent category and then have the ability to assign different content types to the book.
My problem is that I have two completely different books. One is used as an internal staff manual and the other is a user-contributed book on climate change. There's not any overlap and it's a pretty big problem is the incorrect node type goes in a book.
It seems like it would meet both of our needs if we could define the parent node type on a book-by-book basis. Is this correct?
Comment #11
chorrylan CreditAttribution: chorrylan commented> chorrylan, patches get applied to Drupal 7 first
: sorry that was entirely unintentional (my first post in this world)
>It seems like it would meet both of our needs if we could define the parent node type on a book-by-book basis. Is this correct?
: Isn't it the *child* node type we need to be able to specify on a book-by-book basis rather than the parent?
The parent is likely to be the one node that conflicts with that type.
Comment #12
JuliaKM CreditAttribution: JuliaKM commentedSorry for the confusion. Defining the child type is what I meant. Ideally, the admin/content/book/settings page would let you change the default child page type for each allowed book content type.
Comment #13
svdoord CreditAttribution: svdoord commentedI'm also in need of this kind of functionality (for D6). Just to make an alternative suggestion that may be simple to implement and suits all needs mentioned above (I think):
In the settings list of "Default child page type", just add another option that says "same as parent page".
This solution doesn't have the workflow issues mentioned above, because by default nothing would change, only when you activate this option. The only case that this does not cover, is when you have different books with different content types, that all have yet another content type for the covers. In other words, this case:
Book 1:
Book 2:
I don't know the implementation details, but I thought that suggestion this might be easier to implement.
Comment #14
fda CreditAttribution: fda commentedThere is something I am wondering about. If the cover page has a field concerning the whole book and which is meaningful only on the cover, we certainly do not want it to be propagated in the future children pages just to be skipped by the redactors on each and every future page, uselessly complicating their work, do we ? And this even more true if we have a lot of fields relevant only to the cover, for instance to be used by some views specifications . What do we do in such a case ?
Maybe this should be the standard behaviour only when parent's page depth is > 1 ?
Comment #15
criznach CreditAttribution: criznach commentedI've just committed a contrib module for 6.x based on the patches above. It adds a setting per node type to selectively override the "book" default parent type.
http://drupal.org/project/book_inherit_type
It's only minimally tested, so please create issues with any feedback.
Comment #16
wernsting CreditAttribution: wernsting commentedI have it installed right now, and so far seems to being the job nicely.
Another piece of functionality that might be nice is if it were possible to change the content type on all child pages which were created before taking this module into use. Something similar to what http://drupal.org/project/flatcomments does for comments.
Comment #17
dugh CreditAttribution: dugh commentedsubscribe
Comment #18
HylkeVDS CreditAttribution: HylkeVDS commentedI often make books with different page types. Personally I'd be happier if "add child" page would just ask me what type of page I want to add. Or at least give me a list of links for the other types on the "add child" page.
The url of the "add child page" is /node/add/?parent= so making a list for all available node types would be easy.
Comment #19
yettyn CreditAttribution: yettyn commented+1
Exactly, why make it more complicated then it really is? Possibly could the parent serve as a default suggestion.
Comment #20
yettyn CreditAttribution: yettyn commentedActully, isn't this exactly what http://drupal.org/project/BookMadeSimple does?
Comment #21
ñull CreditAttribution: ñull commented#18 that is what the module in #20 is doing. But I think that this patch is the most logical minimal behaviour that should be included in core.
Changing version because 7.x-dev won't accept features any more and it is not a bug, or is it?
Comment #22
Samfall CreditAttribution: Samfall commentedHere is a patch that implements the solution suggested in #13 by svdoord. This works great for my site.
It may not be as comprehensive as the method covered by BMS, but it is much better than the default.
Comment #26
leducvin CreditAttribution: leducvin commentedAny chance of seeing this realized in D8 and backported to D7 ? It's been 4 years since the last comment...
The book_made_simple module for D7, which allows you to choose allowed child pages types, is at best minimally maintained at the moment and has a few annoying bugs. For the long term, I would rather have this feature included in the core book module than have to rely on an unmaintained module. There doesn't seem to be an option available for D8.
I feel that child pages of the parent type should at least be an option we can choose to activate. A single content type may not fill the needs of child page of every book (in my use case at least, it does not).
Comment #28
@baux CreditAttribution: @baux commentedI subscribe... I need this feature too...
It does not (usually) make sense to a create a content type different from the one you are looking for...
Comment #33
joel_osc CreditAttribution: joel_osc at OpenPlus commentedI have opened a similar issue and created a patch for D8 which allows the user to configure what content-type should be used for the add child link per book enabled content-type.
Comment #38
quietone CreditAttribution: quietone at PreviousNext commentedThis 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.