Create a new revision is is a decision fork for the user. Assuming that they should do this and therefore expanding it by default adds visual noise, increases cognitive load and presumes we know what they want to do.
If the user wants to create a new revision they will check the box and create one. Let's not nanny them.

Here's what it looks like now:

image

Here it is collapsed:

image lost

Much cleaner and simpler.

Comments

tkoleary’s picture

Issue summary: View changes

added image

tkoleary’s picture

Issue summary: View changes

added image

tkoleary’s picture

Issue summary: View changes

resized

tkoleary’s picture

Issue tags: +Spark
larowlan’s picture

Issue tags: +Novice

Tagging

wim leers’s picture

I don't see clear differences?

tkoleary’s picture

@Wim Leers

Page loads with "Create new revision" unchecked

wim leers’s picture

None of the screenshots show that. Also, this is a configurable default, not an enforced default!

You can configure it for each content type at admin/structure/types/manage/article → Publishing options → Default options → Create new revision.

Please also take into account the implications beyond visual noise of having this disabled by default: it will mean that by default, Drupal will not protect the user against accidental mistakes, by creating a new revision each time!

tkoleary’s picture

You can configure it for each content type at admin/structure/types/manage/article → Publishing options → Default options → Create new revision.

Yes it's a configurable default but it still has a default in the content type, which is enabled.

Please also take into account the implications beyond visual noise of having this disabled by default: it will mean that by default, Drupal will not protect the user against accidental mistakes, by creating a new revision each time!

Sure, that's great, but we can accomplish both ends by:

  • Keeping revisions enabled
  • Putting Revisions in a summary and details wrapper called "Revisions and logging"

Now we reduced cognitive load and steered the user away from bad practice at the same time.

Bojhan’s picture

I think the correct fix is not to separate this out in another collapsable item, but only opening this by default when a revision message is required. By default its not in core, therefore it will stay collapsed. A patch for that should be simple, and resolve Kevin's concerns.

tkoleary’s picture

Not really because then we would need yet another checkbox for the user who wants to add a message right?

Bojhan’s picture

@tkoleary No, essentially - unless the "message" part of the revision is required. It will not collapse by default. Which means that it will still make a revision, but its not open by default anymore unless the message part is required.

tkoleary’s picture

@Bojhan

Oh, excellent. In that case your solution in #9 is perfect

wim leers’s picture

I don't understand #9.

The revision log message has never been required. There is no way to make it required. Plus, when it's optional, the user should be able to enter such a message anyway.

So how then will the user be able to enter a revision log message?

Or are you arguing that there should be a new setting besides the "Create new revision by default" setting, called something like "Require a log message when creating a new revision"?

Bojhan’s picture

I am arguing for the latter, adding that checkbox. Since its optional, you can always expand it - I don't see any trouble there.

There is already something like this on d.o, when you change a docs page.

wim leers’s picture

#14: how would you expand it if it is invisible?

d.o docs pages just "hide" it in a fieldset, that is open by default? How is that hidden by default? Surely we don't want another fieldset?

I'm extremely confused. Clear before vs. after mocks would be most helpful.

wim leers’s picture

Issue summary: View changes

resized

andriyun’s picture

Issue summary: View changes
Issue tags: +DCDN
andriyun’s picture

Issue tags: -DCDN +dcdn-sprint
tvn’s picture

Issue tags: -dcdn-sprint
shumer’s picture

Status: Needs work » Needs review
StatusFileSize
new1.21 KB

Patch for review

clebu’s picture

@shumer: There is a small typo: '#title' => t('Add log messge'),

peterg.griffin’s picture

Status: Needs review » Reviewed & tested by the community
peterg.griffin’s picture

Status: Reviewed & tested by the community » Needs work

Typo still exists: '#title' => t('Add log messge'),

peterg.griffin’s picture

Assigned: Unassigned » peterg.griffin
Issue tags: +drupalcampfi
peterg.griffin’s picture

Status: Needs work » Needs review
StatusFileSize
new1.21 KB
pandapowder’s picture

I am at Drupalcon Austin and I'm reviewing this patch.

pandapowder’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

I was going to reroll this patch because it is stale, and I got it rerolled but I'm not going to upload it because after further consideration, I've decided that I don't like the proposed change. I feel that the extra checkbox for "Add log message" Overcomplicates the decisions the user has to make. Whether the log message field is displayed to the user or not, it is not required and adding the extra toggle visibility box just gets in the way.

SGhosh’s picture

Category: Bug report » Feature request
Priority: Normal » Minor

Tried out the patch, it does need a reroll. But it doesn't seem a necessary addition.

What it does is add another checkbox for the user to add a message, but on checking this checkbox it only makes the add message textarea show up. It doesn not even make the revision message required. This infact seems to be an unneccesary addition to what is already present.

Moving this to minor priority.

SGhosh’s picture

But rerolling the patch anyway, for others to try out. Maintainers please close issue if this will not be worked upon.

jacobsanford’s picture

Status: Needs work » Needs review

Triggering testbot on patch in #28. Regardless of any decision to proceed, it would be nice to know if patch is clean.

Status: Needs review » Needs work
andriyun’s picture

+++ b/core/modules/node/src/NodeForm.php
@@ -150,10 +150,24 @@ public function form(array $form, FormStateInterface $form_state) {
+      '#access' => $node->isNewRevision() || user_access('administer nodes'),

Fatal error: Call to undefined function Drupal\node\user_access() in /home/sa08b0b10dc8ddca/www/core/modules/node/src/NodeForm.php on line 157

user_access function deprecated.
You should be use $current_user->hasPermission('administer nodes') instead user_access()
See core changes user_access() got converted to a method on the user/accountInterface

omers’s picture

OK here is the patch with the reroll, the interdiff and looks like that :)

omers’s picture

Status: Needs work » Needs review
andypost’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

The summary is not clear what was proposed!

/admin/structure/block/block-content uses nearly the same widget so it makes sense to unify them

andypost’s picture

#34 is no way, also no reason to abuse a cleaned node form

andriyun’s picture

Hey guys!
To make block "revision information" collapsable it's enough to remove overriden this block in theme seven.
I do not know why it has been done, but file /core/themes/seven/seven.theme contain next code:

  $form['revision_information']['#type'] = 'container';
  $form['revision_information']['#group'] = 'meta';

To make this block collapsed by default need to correctly set "#open" key in node form

andriyun’s picture

Status: Needs work » Needs review
andypost’s picture

StatusFileSize
new28.51 KB

The patch goes wrong way imo too. Also it pointless to scroll down to actually change authoring

I'd prefer to get rid of that element "revision_information" in favour of current approach.

It makes sense to input log message only when creating revision (checkbox checked)

so maybe just move code from seven to default implementation at least?

revision

kfritsche’s picture

Assigned: peterg.griffin » Unassigned
Status: Needs review » Needs work
Issue tags: -drupalcampfi
tkoleary’s picture

@andypost

Yes it makes sense to unify.

And revision should not be a special snowflake but handles as the other collapsed panels are.

Bojhan’s picture

@tkoleary Isn't it a special snowflake because we wish to elevate that one?

vasi’s picture

We're going to look at this at DrupalCon LA.

vasi’s picture

Issue tags: -Novice

It's unclear what needs to be done here, so we're removing the "Novice" tag.

wim leers’s picture

Issue tags: +Usability
wim leers’s picture

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

andypost’s picture

Any reason to have this checkbox when creating a node? this is a first revision anyway!
Also node edit form has revision collapsed by default but should have open when there's revisions already

IS should be updated after usability review

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Component: Seven theme » theme system

Seven has been removed from core. This was discussed in #frontend and markconroy said that this should move to the 'theme system' component. I am doing that now.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.