'Create new revision' setting for content type isn't used in node edit form

Behavior is general, not specific to alpha1.

I'll take a look at this.

This is actually only an issue for users with the 'administer content' permission. The problem stems from the use of #states to automatically check the 'Create new revision' box when a revision log message is entered. Unfortunately #states also merrily unchecks the checkbox when the log is empty, which always is initially.

I propose two alternative solutions to this:

1) Simply remove the #states entirely from the process. This restores D6's behavior and auto revisioning node types will have 'Create new revision' checked as expected. Patch.

2) Replace #states with a more sophisticated script that never unchecks the 'Create new revision' checkbox, but does automatically check it if the log is filled in. Patch.

Personally I prefer option #2 as it is the most in keeping with the intent of using #states and has the most natural behavior.

Had a discussion this weekend that convinced me this issue is a performance regression and should therefore be reprioritized critical.

Happy to help:)

You might also want to look at #728090: "Revision information" can have incorrect summary; it's a similar issue, but it's new to D7 rather than a regression.

I ran into this
this is what I was about to open in an issue:

if a site-builder sets up a content type with "Create new revision" he/she is expecting that a new revision will be created by default regardless of editors having administer nodes permission
but if the editor have such permission and doesn't navigates to the revision log, then the checkbox will be unchecked (if JS is enabled on his/her browser)
which is an inconsistent and undesirable behavior

+      //Check the create new revision checkbox if it exists, isn't already checked, and the log is filled.

Please add a leading space for the comment.

I'm not qualified to review js but option #2 seems preferable.

Option #2 with a leading space in front of the comment, per catch's request.

Last patch got some Windows line ending somehow, rerolled.

@kpander - Should this be marked reviewed?

Wrap comment, it exceeds 80 characters

Wrapped comment.

A couple of white-space issues in this patch. But anyway...

I guess we should take a step back. Is this behavior correct after all?

The checkbox only appears for administrators. The current code tries to auto-enable the checkbox if the log message is non-empty. That's a nice little tweak, but we do not have such magic anywhere else in Drupal (yet). I didn't even know that this code here exists.

Therefore, to fix this bug, we only set #states if $node->revision is not enabled. In turn, this means that when $node->revision is enabled (by default or not), there is no magical auto-enabling at all.

However, I'm not sure whether I like/support this behavior in the first place. So dropping that #states property entirely is a valid option 2).

Agreed, removing #states entirely is a perfectly valid fix to this issue. Ultimately it's just a question of what the default behavior should be.

If we just drop #states, my previous patch should be usable. If we want auto-checking/unchecking then I'm happy to clean up any remaining white-space issues and roll another patch. I just need to know which approach we want to take.

Setting back to "needs review" to stimulate discussion.

There you go.

sorry, I forgot about progressive enhancement modularity form alteration clusterfuck.

So this one it is.

Looks good.

Committed to CVS HEAD. Thanks.