Similar to #2856363: Path alias changes for draft revisions immediately leak into live site.

Steps to reproduce:

Enable book module and configure it for article content type.

Create a node and publish it.

Create a new draft revision of the node, adding it to a book outline from the node form.

Note the node immediately appears in the book outline.

The same will be true to changes/removals from book outlines when editing nodes as draft.

There are really two bugs here:

1. Data loss/integrity due to side effects from saving drafts.

2. Access bypass on sites that have more complex workflows restricting access to publish actions, since this allows people who wouldn't be able to publish a draft to affect the published site.

Proposed resolution


1. Prevent changes to book outlines when saving revisions as drafts.

2. Add revision support to book module.

(or the first as a stop-gap and the second as a follow-up task).

A further consideration once we get to workspaces is admin/structure/book - if you're in a workspace you'd expect that to only make changes in the workspace, at the moment it'll change things on the live site.

Remaining tasks

User interface changes

API changes

Data model changes


catch created an issue. See original summary.

catch’s picture

Issue summary: View changes
mxr576’s picture

I think this is not a newly discovered bug just no one created an issue for this yet, rather everybody tried to find an alternative solution and get rid of book module.
I had also realised that this is just an another drawback of book module's a few months ago. After that I tried the impossible on a D7 project by combining Revisioing, Entity menu links and Book modules. (Not speaking of OG Book module.) TL;DR. I gave up after a while, because I saw how much work would it be to create a proper and working solution. D7's Book module depends too much on menu system which makes things really really complicated.
I also tried to find an another solution, like Tree module, but it is in highly unstable state so I end up with a custom soution.

To be honest, I was really disappointed when I saw that Book module is ported to D8 without any improvements. I had no doubt that it has the same limitations as in D7 and because of that using it an a project has more drawbacks than benefits in 2o17.
That is why I get thrilled when I saw PreivousNext's new module a few weeks ago, called Entity Hierarchy which leverages nested sets to make hierarchy generation faster by using entity reference fields. (Similarly to Tree module) I knew this could be a perfect replacement of Book module.
What a coincidence, I've just started to enhance this module today to become a perdect replacement of Book.

cilefen’s picture

Issue tags: +Triaged D8 critical

@alexpott, @catch, @cottser, @xjm and I considered this issue and agree this is suitably a critical priority bug for the reasons stated in the issue summary: data integrity, and an access bypass.

pwolanin’s picture

The non-support for revisions in book has been evident for a very long time and I'm pretty sure I've closed issues in the past as "works as designed".

The only critical piece here would seem to be blocking a non-published revision from adding to or changing the book hierarchy.

I don't think it's possible or sensible to add revision support for elements of a hierarchy at the individual node level, but it would be more feasible at the level of a workspace.

If you think it's possible to integrate with individual node revisions, please explain the data model to me and how that would work as revisions are published or reverted. The taxonomy tree is represented by {taxonomy_term_hierarchy} which is not revision aware either.

Note my proposed (not accepted) core conversation was to be about some of this:

cilefen’s picture

The only critical piece here would seem to be blocking a non-published revision from adding to or changing the book hierarchy.

Indeed. The priority is a reaction to that, not necessarily a blessing of the proposed solution.