Changing the order and thus weight of cck and node fields

I'm sorry, you're not being clear. Please rephrase, describing precisely :
- what are the actios you take
- what is the result you expect
- what you get instead

It is not CCK that assigns the -1, it is the core tabledrag.js script that handles drag-n-drop, and generally generates negative weights

The problem here is indeed that the node contains other non-cck 'fields', whose weight stays untouched (generally >= 0), and thus do not play well with reorderable fields. CCK does provide a hook_content_extra_fields() that other contrib modules can use to have their 'fields' reorderable by CCK's 'Manage fields' tab. So the real solution here is to file a feature request against Biblio.

Documentation for the hook?

/**
 * Implements hook_content_extra_fields()
 *
 * CCK hook to allow sorting of the domain settings field.
 */
function domain_content_extra_fields($type_name = NULL) {
  if (!empty($type_name)) {
    return array(
      'domain' => array(
        'label' => t('Domain access options'),
        'description' => t('Domain-specific settings for posts.'),
        'weight' => 1,
      ),
    );
  }
}

Correct?

Correct (except the = NULL part in the arguments should not be needed, a valid content type should always be passed to the hook.)

content_form_alter takes care of altering the weight of node form elements it finds. This means that if your form elements are added after content_form_alter(), you'll have to set the right weight yourself (you can retrieve it using content_extra_field_weight() ).

I still need to properly document this :-(

The code above seems to work just fine. I'll probably leave the NULL check in just for paranoia.

skyredwang has provided this workaround.

"Here is my solution: disable javacript on the manage fields page, then manually type into weights."

Here here. Many thanks GeoffPalin for this amazing tip.
For anyone wondering how to do this... use FireFox, go to Tools->Options->Content and disable javascript. Reload the page. Change the weights, then re-enable it and submit the form. Voila!

Subscribing - you just saved my bacon!

Subscribing, but why is this closed. Shouldn't this javascript workaround be solved somehow?
Greetings, Martijn

Agreed! The "Title" field of the node apparently sets the base for all other weights and you can't edit the weight of that field (grayed out) even with javascript turned off. I'll go searching for where those weights are stored in the database and see if I can get out of the jam I'm in now as the save/preview buttons are floating around based on those other weights.

Follow-up. Turns out YOU CAN EDIT the weight of a grayed out "node module form" field, so don't let the normal user interface convention of grayed out fool you like it did me. :) The whole issue here is the save/preview buttons get inserted into the $form when the weights hit 0. Might be kinda cool to have a slider (or a buttons-here field) on that manage fields screen which sets the "zero weight base" mark for placing buttons or calculating integer offsets up and down from that base. I know some folks use multiple save buttons on some forms, but for us noobs who don't know where the internals are stored it would sure be easy to get this pesky weight problem solved.