Weights on cck fields in the $node->content array are not properly set :
currently $node->content is something like :
Array(
[body] => Array(
[#value] =>

whatever

[#weight] => 0
)
[field_field1] => Array(
[0] => Array(
[#value] => whatever_1
[#weight] => -3
)
)
[field_field2] => Array(
[0] => Array(
[#value] => whatever_2
[#weight] => 3
)
)
)
The '3' and '-3' weights only apply inside their respective [0] sub-array, meaning they are not operative
The body field do not appear between field_1 and field_2 as it should, but below them.
The fact that (cck) fields themselves are correctly ordered is in fact because they are appended in the right order (_content_field_invoke honors field weights)

Everything works OK if we get the weights out of the [0] array.

The attached patch does this.
I did not committed this because I'd like to check with Karen first.
In particular : do we really have to deal with field modules returning arrays on $op = 'view' ?
Not any one that I'm aware of does. They all return a 'flat' themed output, enclosing the multiple values.

CommentFileSizeAuthor
field_weights.patch922 bytesyched

Comments

yched’s picture

yched commented

I really meant to add [pre] tags...
The sample $node-> content in my previous post is

Array(
    [body] => Array(
        [#value] => whatever
        [#weight] => 0
    )
    [field_field1] => Array(
        [0] => Array(
            [#value] => whatever_1
            [#weight] => -3
        )
    )
    [field_field2] => Array(
        [0] => Array(
            [#value] => whatever_2
            [#weight] => 3
        )
    )
)
karens’s picture

karens commented

I set it up this way when I did the initial 5.0 port and I tested at that time whether the weights were honored even if they weren't the top level item, and they were. This was, I believed, because we're using the FAPI engine which always picks up the lowest level item unless '#tree' is set somewhere higher up the array which should mean that only the lowest level value should matter. But maybe something has changed since then in core -- or maybe I mis-tested somehow :-). I personally would prefer to keep the option for a field with multiple values to return an array of values because it really appears to me that FAPI 2 is designed with the capability to handle multiple level arrays in views in the same way it handles them in forms and it would be nice to preserve flexibility in case that option is needed in the future.

yched’s picture

yched commented

From quick tests on forms, it seems this code 

$form['a'] = array('#type' => 'textfield', '#title' => 'a',
  '#weight' => 0,
);
$form['wrap']['b'] = array('#type' => 'textfield', '#title' => 'b',
  '#weight' => -3,
);
$form['wrap']['c'] = array('#type' => 'textfield', '#title' => 'c',
  '#weight' => 3,
);

always lead to a, b, c in that order, no matter which value of '#tree' I may set to 'wrap' or to the entire form.
And adding $form['wrap']['#weight'] = -1; leads to b, c, a.
So it really seems weights apply separately for each level of the array.

Well, I'm committing this, it makes the current implementation work.

As for the 'view' op return values as arrays :
Why not indeed keep this possibility, since the render API does support it anyway...
I'm not sure this 'freedom' is not adding confusion to the somewhat blurred 'multiple fields' area, though.
My feeling is that we should recommend _one_ way to handle multiple values - be it, in this case, 'group in one flat html output', or 'return an array with one output per value' (but in that case, where do we call theme('field',...) ?)

AAMOF, my more general feeling is that I wish more of the multiple values handling was hardcoded into content.module, and not left out for contrib field modules to deal/mess with - but this is most probably outside the scope of this current issue...

yched’s picture

yched commented
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)