Updated: Comment #0
Note: I'm leaving this assigned to myself so I can do some more research and fill in the TODOs in the issue summary.
Problem/Motivation
In 2001, code was added to automatically save a revision to book pages so that updates didn't overwrite the previous content.
I don't think it's necessary to force a revision anymore, because administrators can now configure content types so new revisions are on by default (TODO: find issue/commit where that was introduced), and if this is done, non-administrators can't override the setting (TODO: find issue/commit where that was introduced).
Furthermore, under certain conditions (e.g.: when non-administrators save a book node where "Create revision" has been set for the content type as a whole), two revisions are saved. While this isn't necessarily a bug, it is unexpected (Drupalism / makes people say "WTF?") and currently causes problems with the Workbench Moderation module in D7 (
#2153103: When saving a revision of a book node, a second revision is created at the same time. →
) .
This is a weaker argument, but it was removed in
#146425: improve book module: use nodeapi and menu API →
only to be put back because it was desirable for Drupal.org (whose use-case might not necessarily be the same as other sites). It's not clear whether it was originally committed to fix difficulties on Drupal.org specifically... at the very least, we should re-evaluate if it still serves a useful purpose and whether it makes sense to keep it in Drupal core, or if it really should go in the
Drupal.org customizations module →
.
Proposed resolution
Stop saving an extra revision for book nodes.
Remaining tasks
- Re-evaluate if saving an extra revision is necessary when book nodes are edited by non-administrators.
- Determine if it belongs in Drupal core or
Drupal.org customizations →
.
- Write any patches.
- Evaluate whether a patch to Drupal 8 should be backported to D7, and if so, write the backported patch.
User interface changes
None.
API changes
None.
More history
Forcing non-administrators to create a new revision upon saving a book node was added less 24 hours after revisions were first added to Drupal. Originally, the new revision was created in the book_save() function. This later changed so that the book_validate() function set the new-revision-bit instead. Eventually, _validate() functions changed to _execute() functions in
#36791: node_validate is called twice →
, then got changed again into _submit() functions in
#39576: Replace execute with submit →
.
It was almost removed in
#68418-8: Clean up node submit hooks →
, but got re-introduced when the commits related to that patch were rolled back in
#68418-33: Clean up node submit hooks →
(note the commit message doesn't provide much info on why it was rolled back). That issue eventually got marked "Works as designed" and never went anywhere further.
In
#138706: FormAPI 3: Ready to rock →
, rather than modifying the node object directly, it was set as a $form_submit value.
In
#146425: improve book module: use nodeapi and menu API →
, the book module was refactored and it was changed from a form value in _submit() function back to a direct modification of the node object in the presave operation of book_nodeapi(). The conditions under which a new revision would be saved also changed so that the book ID also had to be non-empty.
In 2008, book_nodeapi($op = 'presave') was changed into book_nodeapi_presave() (the nid in the commit message appears to be wrong). In
#302207: DBTNG: book module →
, a log message was added to the revision. In
#383066: hook_nodeapi_X => hook_node_X →
, hook_nodeapi_presave() was changed to hook_node_presave().
In
#1723892: Support for revisions for entity save and delete operations →
, adding a revision was done with $node->setNewRevision(); instead of setting a new-revision-bit.
#2218691: Move the current user out of the node API chain in book →
(RTBC at the time of writing), aims to change the revision from book_node_presave() into book_node_builder() (which is added to the $form['#entity_builders'] array).
Other notes
I originally came across this problem while trying to teach someone how to use Workbench Moderation on their site in Drupal 7. I noticed that people without the "Administer nodes" permission had their changes stomped, but only when editing book nodes.