I maintain a CCK field module (viewreference) and someone has reported a problem where they order the field to be below the body, and it works on the edit page, but not on the view page. I don't have this problem myself, so it's difficult for me address.
Has anyone seen anything like this before and would know where to start looking for a solution?

CommentFileSizeAuthor
#3 node_cck_editor.JPG68.32 KBwellard1981
#3 node_cck_view.JPG16.82 KBwellard1981

Comments

danielb’s picture

to clarify; on the view page, it appears above the body instead of below.

karens’s picture

Status: Active » Postponed (maintainer needs more info)

Make sure they're using the latest code. There was a recent fix for a bug that might have caused it. It that's not the problem, we need someone to provide a way to reproduce it.

wellard1981’s picture

StatusFileSize
new16.82 KB
new68.32 KB

I'm seeing a similar problem. Order the fields in Content Types > Manage Fields, but when creating a new node that uses CCK, fields are in a different order. Have included screenshots of the problem.

karens’s picture

@wellard1981 - there is no way I can tell from those screen shots which field in the view is which field in the edit, so I have no idea what order they're showing up.

I can't replicate the problem, and apparently neither can danielb, so it's hard to do anything.

The only way we can do anything with this report is for someone to create a complete, reproduceable example, preferably one that uses only core CCK fields, that shows exactly what fields are in the content type, how they are configured (you can do an export using Content Copy to show us that information). Then we need a screen shot of the Manage fields screen so we can see how that is set up, a screen shot of the Display fields screen, so we can see which fields are supposed to be hidden (ideally you would produce an example that doesn't have hidden fields, but the screen shot can help us know for sure). Also turn off the Content Permissions module temporarily while you create your example to be sure it's not field permissions creating the difference.

The one place I can think of where we might see problems is that core gives the body an empty weight, it's not zero, it's empty. That sorts it differently than if it's zero. But we have to give it a weight in the Manage fields screen for the drag n drop code to work. So if it sorts as empty in the view and as zero in Manage fields, that could create a difference in the way they look.

But we need a complete example of how to reproduce to be sure if that's it.

danielb’s picture

I managed to reproduce this accidentally just now with the Image Field (I don't know if it's core, but it's a module that lets you upload an image in a similar way to the file field).

And yes I was trying to position my CCK field above the title/body.

Sorry I am on a deadline and I don't have time to debug it!! :( :(

karens’s picture

Title: Order of fields differs on view page? » Order of fields differs on view page
Version: 6.x-2.0-rc10 » 6.x-2.x-dev
Category: support » bug
Status: Postponed (maintainer needs more info) » Active

I found a way to replicate the problem, but don't have a fix and don't have time to work on it right now.

This is a bug in the way the Manage fields screen is working. The problem is that the 'body' element in the manage fields screen isn't getting a weight of zero, as it should, but instead ends up with a weight that depends on how many elements are on the screen. In the default situation, the first element is the title with a weight of -5, the next is the menu settings with a weight of -4. If there are no fields, next will be the body with a weight of -3 (!!). If your field has a weight of less than -3, it will fall below the body.

You can try to fix it by dragging and dropping things into the right places and then saving them. In the above scenario, if you add a field and move it above the body, the field will end up with a weight of -3 and the body will end up with a weight of -2 in the Manage fields screen. But if you edit the node and use the Devel module to see what weight all the elements have, you'll see that the body has it's normal weight of zero, not -2.

So something in the way that weights are handled needs some work. We must either reset the body weight to zero in the manage fields screen so the body shows up in the right place, or give the body in the node edit form the same weight it's getting on this screen.

karens’s picture

More information, CCK is trying to set the right body weight, but it is being set on 'body_field' during form_alter() and sometime after that the form gets rearranged and $form['body'] is created as a parent element to the body_field. This parent element has no weight and will not pick up the weight we gave body_field, so it ends up with a weight of zero no matter what it was supposed to be. I can't figure out exactly where this is happening, but I think it may be in the #after_build where the teaser splitter is handled. I think we have to come back after #after_build to set it right again.

No more time to work on this now...

karens’s picture

But the weird thing is that this is the reverse of the original problem -- it should be wrong on the edit page and right on the view page. This is all very weird!

karens’s picture

I think this is the original problem, just a misunderstanding of why the view and the edit forms are different -- it's the edit form that is incorrect, the view is correctly picking up the right weight.

I have tried every way I can think of the alter the node form to set the body to a weight other than zero and can find no way to do it. I have tried using '#after_build' and '#pre_render' and '#post_render'. By '#pre_render' the form element for $form['body'] has not yet been created, so there is no way to set a weight on it. By '#post_render' it's already rendered and it is too late for the weight to have any effect.

I cannot find the place where the top level body element is getting set to zero, nor any way to undo that.

avpaderno’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

I am closing this issue, since Drupal 6 is now not supported.