Form appears below Submit button

I've actually run across a couple modules where this is the case, and I actually did this intentionally.

My _assumption_ (but you know what they say about those) was that sometimes, settings for the node types are put under the submit button because they won't be used or changed as often as other settings on the same page, and doing so keeps the admin from having to scroll way down before being able to hit "Submit"

So I left it that way, because the area those settings (for usernode) take up is large, and if all someone wants to do is adjust the standard settings they might hate scrolling all the way down past a bunch of stuff just to hit Submit (I do).

I know there's the collapsible element groups - perhaps I should see about using those instead.

This patch 'fixes' this issue, using the '#weight' parameter.

I disagree on a 'collapsible'. Collapsibles should *only* be used for values that have no real interest. Pieces of forms that come with good defaults. Only if you want to change them, you can open the collapse and alter it. See it as an 'advanced' feature.

However, this patch changes the behaviour by adding a simple weight.

Sorry for the big patch, but I fixed your identation too, you used spaces and tabs mixed!!

Bèr Kessels: Thanks. I thought I had managed to catch all the instances of tab indenting - but as I've worked, old habits die hard. That shouldn't be something that someone else has to fix - apologies.

My concern about the patch you submitted though is that it puts usernode info at the very top of the form - I honestly don't think that usernode is something that should be given higher priority than the standard node form fields. But that's something that could be adjusted easily by changing the weights, I'm sure.

I've decided, after some careful thought, that usernode fields should indeed not be below the submit buttons. Scrolling aside, I think it's just not good user interface. I will consider your input about collapsible groups. I guess what would really make the difference in whether to use them or not would be whether most users of this feature are going to need those settings very often (for more than one or two node types).

On a side note, I'm really looking forward to CCK. I hope that's ready to use "for real" very soon. I'm especially interested in the category attachment fields. I already use something similar for user profiles, (allowing users to choose a list of nodes by category that can be linked to their profile - such as for interests, hobbies, etc.) but I'd much rather have that in nodes that can be attached to a user's profile with something like usernode.

My main goal with usernode was less about limiting amount of content per user, and more about being able to easily attach flexible, detailed, searchable profile information for users. Things like bios, "About me" pages, and similar (I was inspired by the bio.module, but needed more functionality).

Thanks for your assistance.

Coyote

I wrote a function (currently called array_insert())to solve this problem. I'm trying to get it in core, but in the meantime, you could copy put it in your module as usernodes_array_insert(), then use it to place the usernodes stuff before the "buttons" key.

Doh! Forgot the link to array_insert():

http://drupal.org/node/66183

This seems to be all fixed now. : )