Weight for 'menu settings' on node forms

More descriptive title.

Ok... however, your initial report was very short and unclear. Let's try the title thing again... feel free to change it to something better if it still doesn't fit for you.

Core (without CCK enabled) makes the choice to put the menu settings at a weight of -2, so that it gets under the 'title' field, unlike in D5 where it was amongst the 'bottom' fieldsets.
I don't think CCK should hijack this choice by forcing it back to the D5 position.

When the d-n-d feature for the 'manage fields' screen was initially committed, along with the ability to move non-CCK fields around, the position for 'menu settings' could be customized. As a result of the UMN usability session, it's been removed as this 'menu settings' 'field' was deemed confusing. It now stays at -2 no matter what, which is not too good, though.

I think we should reintroduce it on the 'manage fields' screen, but I'll wait for Karen's opinion, since she was the one to attend the UMN sprint :-)

I don't know what to do with it.

When it showed up on the 'Manage fields' screen as a separate item at the UM usability session, it confused everyone, including the Drupal team, since it's not a 'field'. So I'm not sure that's a good solution.

Moving it to the D5 position when that's not where it is in D6 makes no sense either.

I thought at one time I had added some code to keep it below the title, wherever the title got moved to. Maybe that got lost (or maybe I don't remember right). And maybe that's no better.

And of course, fixing it at -2 is pretty wrong, too.

I suppose the least problematic solution is to go back to having it a separate item that can be moved around, so you can put it in either the D5 or the D6 position yourself. But I suspect we'll get a bunch of issues asking what the heck that thing is. Maybe we can add some descriptive text to explain it somewhere. Like put an asterisk after the name, 'Menu*', then at the bottom of the page add an endnote for the asterisk that says something like '* The menu field allows users to set menu options for the node. It is positioned right after the title in unaltered node forms.'

So what if we label it 'Menu settings' or 'Menu settings form' (instead of just 'Menu') to make it more clear that this is not an ordinary field. Still with the asterisk and explanation 'The Menu settings form allows users to set menu options for the node. It is positioned right after the title in unaltered node forms.'

The other advantage of making it a movable item is that lots of people don't like the new placement for the menu (I'm one of them) and this will allow you to move it back to the bottom of the page.

+1 for that. I like 'Keeping it under title' too, but I'm afraid it won't stop people from asking themselves 'what is this thing doing in the middle of my fields' when viewing the node form anyway...

I must confess I don't really get why this item was moved out of the 'bottom fieldsets' in D6 to begin with...

I added the 'Menu settings (admin)' item in the list of draggable 'fields' on the 'Manage fields' tab.
Do we need an additional help text ?

Let's try it this way and see what happens. If we start getting lots of 'what the heck is that' reports, we can add help text.

I was thinking that for 'non CCK fields' rows, which do not have 'field type' or 'operations', we have a lot of unused space that could be used to provide additional info if needed.

Ah! Yes, that makes sense. Something that explains that these are things provided by core might be really helpful.

OK, I committed some code to support displaying descriptions in there.
The actual description texts still need to be written. Suggestions ? :-)

I'll take a look...

What do you think of the following as descriptions?

Subscribe. Sometimes I really wish the English word "widget" won't exist... or there is something appropriate in other languages. Only to say for German - this could be nearly nothing and everything and something and if it is not such context sensitive like here - you are in troubles how to translate :-). However no problem in these strings...

My reason for using 'widget' is that first of all it is already a CCK term, and second those are not simple form fields but more complex subform elements. I don't know if it's a good way to describe things or not, though, that's why I posted it here for discussion.

I've been keeping this patch alive, but notice it wasn't marked as a patch. My text is at least better than leaving it as a bunch of TODOs. I'll change 'widget' to 'form' and commit it. This will obviously involve string changes. I'll find the string change issue and mark it there, too.