Move collapsed groups to bottom of content creation form

I'm not sure why but the patch wouldn't apply cleanly for me. It needed me to manually specify the file to be patched. I've attached a reroll of it that changes nothing in the code, just in case others have the same problem. :-)

As to the patch itself, I like it with one caveat. I'm not entirely sure how the filter system works, I confess, but it applies primarily to textareas. Therefore, it makes sense to me for the filter selector to be immediately after the textarea to which it would apply rather than "somewhere down the page" as this patch would put it.

Does that make sense? Or did I miss some memo about how the filters are handled in 4.7? :-)

The filter selector (filtered html, php code, full html) logically belongs to the textarea (because it only filters only the textarea). After applying this patch, the forum topic edit form looks really weird.

I'm in favour of the groups moving somewhere out of the way. I've not used WordPress in a long time, but I remember they put these kind of fields below the submit button, as they are so rarely changed.

Annotated screenshot attached.

Exactly, tangent. :-)

Look at the fieldset labeled "Input format". It has a single set of radio buttons in it, which apply only to the big textarea above. However, said radio buttons are now far-removed from the textarea to which they apply, and collapsed by default. That's a problem. They should be placed with the textarea, since that is what they apply to.

As I've said elsewhere, I think we're getting far too carried away with the coolness of collapsable fieldsets. We should not be defaulting them to collapsed unnecessarily, yet we seem to be doing so more and more. That's bad.

+1 for moving the comments, attributes, and authorship fieldsets down and collapsing those. They're rarely used and make sense anywhere. -1 for making the input filters removed from the textarea and for collapsing it by default needlessly.

1. Makes the filter module "Input format" fieldset not collapsible and with a weight one less than the body field so that it follows directly after.

I wasn't saying that it shouldn't be collapsable. Most fieldsets should be collapsable. But it shouldn't be collapsed by default.

There's actually a discussion of this in another thread right now:

http://drupal.org/node/30038

OK, actually tried the latest patch now. :-) A few comments.

1) Overall, I like.

2) As I said above, I'm in favor of the input format fieldset being collapsable, just not collapsed by default.

3) If we're collapsing everything already, I'd be in favor of putting the log into a fieldset and collapsing it. Honestly, I doubt I'll ever use it.

4) With path alias now not having a proper label before it, it should be a lot easier to put the $base_url before it to deal with the UI issues discussed a few weeks ago. :-) Something to think about once this patch goes in (and I hope it does).

5) As someone mentioned, what about putting all of this rarely used stuff below the submit buttons? Or would that be just too weird for Drupal? (If so, that's fine.)

Qualified +1 from me, with the caveats in notes 2 and 3. Those should be trivial to change unless someone else objects.

Mark it correctly...and they will come...

+1 for the feature, couldn't do testing at this time.

Robin

Hey, I've been busy this week and I needed to rebuild my CVS install first. :-)

We could probably argue all night about the exact order of the various fieldsets, but I'd say it's acceptable as it is now. The most important features (input filter near what it filters, nothing above the node itself, rarely used stuff hidden) is all in place.

Code looks clean. I would have broken the field arrays onto more lines, but that's just my preference. Everything complies with coding guidelines as far as I can tell.

+1 functionality, +1 coding style. Let's get this into 4.7!

Committed to HEAD.

Committed partially.

Sorry, but this patch drives me absolutely batty as it does not actually do what it says it does.

Unless weights are set on every single form element aside from title and body (which means lots of extra typing), these optional settings end up showing up smack in the middle of the form, totally breaking continuity (form element weights by default start at 0). Additionally, starting weights for title and body of -18 and -17 are not intuitive... they should probably be something like -15 and -10. This would allow people to interject form elements between the title and body fields (see: book module, where the Parent element used to be between title and body but now is after body.)

Here is a patch which attempts to solve these issues by moving those optional settings below the submit buttons as suggested by Thox. I've placed a 5-weight increment between all of the weights set by node_form, to facilitate form alteration (yes, decimals can work too, but a lot of people are unaware of this).

New weights are:

title: -25
body: -20

preview: 20
submit: 25
delete: 30

node author information: 40
node options: 45
all other nodeapi additions: 50

This has the extra advantage that other collapsed fieldsets on specific forms are kept separate from the optional fields which are part of every form.

Finally, I've removed the fieldset around "log message" in page and book, for two reasons:
1. This is essential, particularly for book.module, and doesn't make sense to leave it in page but not in book and story (which was already like this).
2. Logs were not getting a default value after this patch because it's looking for $node->log, not $node->message. $node->log matches what's in the database, so I changed $form['log'] back to the actual textfield.

Any comments appreciated.

Nice, webchick. I'd still lean towards -5 and 0 for title and body, implying that 'body' is the center point around which all other elements revolve. That way, form customizers could use negative values to stick things between 'title' and 'body', and normal numbers to stick things after body. But I think functionally your patch will fix these issues.

Ok, let's try this one on for size!

Makes the title and body weights -5 and 0, respectively. In order for this to work I had to set the initial counter of form elements in form.inc to 1 instead of 0 (otherwise this would've put the input filter box below the first element to follow body).

No problem, tangent! It's a good idea, just needs a bit of tweaking. :)

New patch. This one:

1. Fixes the location of parent in book.module which was relocated to the top of the form rather than below title with the last patch (though I personally like it better at the top since it jives with forum.module)
2. Removes the log message field from story module, which was accidentally put there during the forms API conversion (pointed out by Thox)
3. Makes the menu and path collapsible fieldsets behave like upload module's.. if there is a value stored there, it will auto-uncollapse it. (also pointed out by Thox)

Couple of screenshots for people that would like to see: (They're slightly out of date because webchick posted another patch which removed the log message textarea, but it emphasises the difference this patch has made)

• Screenshot with all groups collapsed
• Screenshot with all groups expanded

For comparison I also uploaded a screenshot of the "expanded"/advanced wordpress write screen.

And now some general comments:

• We used to have the first three collapsed groups side-by-side above the node form. I prefer them out of the way below, but it might be worthwhile trying to put all their options into one fieldset (or even just the first two).
• When scrolling through a large number of expanded controls, I felt like I should scroll down to save, not up. This is only a problem if enough groups are expanded to scroll the save button off the screen. From that, I look at the WordPress screenshot and wonder if highlighting the "Submit" button would make it stand out better (since more modules = more groups = more buttons to get confused with).
• Chx suggested nested groups. This might work, but nested collapsed groups would be bad.
• I should make a separate issue for this: "URL path settings" does not mix with "URL path alias won't work".
• We still can't quickly scroll down and change something. We have to scan through the available collapsed groups, open the one we want, and then change it.

Oh, almost forgot: +1, that patch works very nicely.

Ok, here is an alternate approach.

Options are now uncollapsed fieldsets, condensed into two collapsible and collapsed fieldsets:

1. Administrative options: this contains Authoring information and Publishing options (only accessible by people with administer nodes privileges)
2. Post options: this contains any extra options added via nodeapi hooks (comment settings, file attachments, etc.)

Both fieldsets are collapsed upon initial page load:

http://webchick.net/soc/node_weight/node_weights_collapsed.png

Then you can open one or both fieldsets if you need to:

http://webchick.net/soc/node_weight/node_weights_admin_expanded.png
http://webchick.net/soc/node_weight/node_weights_both_expanded.png

I think this will help with the "Submit button isn't where I expect it to be" problem, because the user must click on the fieldset title itself in order to expand it, which means he already looked at the Submit button as his eye was glancing down the page, and will also know that he can click it again to collapse it, after which time the Submit button is very visible. (this is the theory anyway ;))

And sorry, Thox, I did not understand this:

> I should make a separate issue for this: "URL path settings" does not mix with "URL path alias won't work".

Oh I see now. The name of the path input box and its description below don't match. I actually think this is good as-is, personally... the box is asking for a path, but the thing you're entering is a path alias. But yeah, please start a separate issue for this because I know it was hotly debated on the dev mailing list a few weeks ago. :)

This new patch seems to be a step backwards to before collapsing elements (which may or may not be bad). I don't like it because it does not appear to let me add controls outside the new "post options" fieldset.

I agree that some controls could appear in a group of post options below the form, but drumm pointed out that other controls (his example was attachments) should/could go back to the top.

Ok. I am not sure what to do about this issue of wanting to stick certain form options in the form, others below it. I discussed this on IRC with chx and he said one way might be to allow Node's $form array to be passed into hook_nodeapi and hook_node for easy alteration. Based on Dries's announcement about 4.7 RC and freezing of APIs, this is not really an option.

Another option would be to rely on some sort of naming convention (for example, naming an element $form['nodeapi_options']['foobar'] = array(...) or $form['nodeapi_author']['foobar'] = array(...) or $form['nodeapi_form']['foobar'] = array(...). Then in node_form, perform a check during adding nodeapi form elements whether the form element's key matches nodeapi_* and if so, stick it in the appropriate place (publishing options, author options, or inside the form itself). If not, then it gets appended to the bottom of the form with the other options.

All I know is that the current weight problems really need to be addressed. :P I don't really care which approach is used, but these fields *can't* appear in the middle of the form where they are currently. This business of how to inject form elements into node_form seems best handled by a separate issue.

Assigning this to myself so I don't lose track of it again.

Unassigning self, won't have time to work on Drupal-ish stuff until about 2006. :( But this does need sorting. Hope someone can pick up where this left off. Patch will need to be re-rolled + re-thought.

Updated patch for HEAD, based on #28, with some of my own tweaks:

• "Title" set to -5.
• book.module "Parent" set to -4.
• "Body" set to 0.
• book and page.module's "Log message" set to 5.
• book.module "Weight" set to 5.
• "Authoring information" set to 20.
• "Publishing options" set to 25.
• NodeAPI addons default to 30 (see below).
• "Preview" set to 40.
• "Submit" set to 45.
• "Delete" set to 50.
• Renames "User Comments" to "User comments".
• Fixes some leftover $nodeapi (to $extra) in taxonomy.module.
• Weight of the vocabulary is now actually considered.
• Removes "Log message" from story; revised it for page.module.
• Default filter_form weight is 0, not -16.
• menu.module form_alter doesn't collapse if an item exists.
• path.module form_alter doesn't collapse if an item exists.

About my changes:

• Users have been trained, for many many years, that the end of a form is signified by the submit buttons. Putting data after the submit buttons will infer, more often than not, that those fields are not affected by the buttons that precede them. Thus, this patch keeps the buttons last.
• We no longer have a NodeAPI 'form' - that has been changed to $module_form_alter. There doesn't appear to be a way to default the weight generated by form_alter calls, so I've had to manually set them to 30 for "User comments", "Menu settings", "URL path settings", and "File attachments".
• There are a number of items with similar weights; same weight items sort unpredicatably; alpha-sorting should be commited. This alpha-sorting is also required to make sure the "Input format" (patched weight: 0) always shows up after the "Body" (patched weight: 0).
• For some strange reason, my CVS picked up on some $Id$ string formatting. I've no idea why this is, but those changes are irrelevant.

Updated to today's HEAD, and no CVS $Id$ thingies.

+1. PLEASE get this in, for my poor sanity. ;) Now all the 'extra' stuff correctly appears at the bottom of the form as it should (before the buttons).

Note: Once in awhile the input format will appear above the textarea for which it's intended, but that's due to a separate issue which you referred to above.

Also, to summarize why this is "a good thing":

- Now that default weights both a) make sense and b) are predictable, it means that the forms API is much more flexible for people to insert extra fields wherever they want when altering a form.
- Contrib modules that add many extra fields no longer have the "optional" stuff sitting smack in the middle of the form.. rather, it's pushed down to the bottom where it belongs.
- The form follows the expected flow without resorting to having to hard-code the weights of all of your fields.

Committed to HEAD. Thanks.