The primary problem is caused by items on the content-type form that can not have their weight changed. For example, title, taxonomy and menu -- although they appear on the "manage fields" section -- have a fixed weight of -5, -3 and -2 respectively. You can appear to drag them around on the form, and their weight values do change on the form, however, their actual weight values are not changed on the content-type's submission form.

Because the drag&drop form behaves as though title, taxonomy and menu can have their weights changed, it will reassign them to a different weight and assign the -5, -3 and -2 weights to other fields, causing a disconnect between what the user sees on the "manage fields" form and what appears in the content-type's submission form. There is almost nothing you can do to prevent this from happening... any time you reorder a field that is under the taxonomy or menu fields will cause the form to reissue the weights for taxonomy and menu to -4 and -3, or placing a field above the title field will reissue title to -4.

This causes the user (me) to fiddle around forever trying to get the fields to appear in the correct spot. At first I thought, "Yay! I can actually move these fields!" and try as I might, no matter how I rearranged them, they would stay in the same order relative to themselves, while all my other fields seemed to jump around at random. This caused the weight values for my fields to start going up into the 30's and 40's, causing the next problem.

Other items appear on the submission form as well and have their own weights: revision information, authoring information and publishing information (including any other contributed module that adds to this). When the weights of the fields go up high enough from fiddling around, the "revision information" item can end up at the top of your submission form. Yuck.

At this point, it is impossible for the user to correct it, and the only non-intrusive solution available is to disable JavaScript so you can edit the weight values manually on the "manage fields" form. I am finding there is no other way that I can rearrange my fields because the form continuously assigns the weight of the taxonomy and menu fields to be right after the title field.

CommentFileSizeAuthor
#20 cck-reorder-356158-20.patch2.26 KByched
#13 cck-356158-13.patch2.44 KBmarkus_petrux
#12 cck-356158-12.patch2.44 KBmarkus_petrux

Comments

denislabonkink’s picture

denislabonkink commented

Subscribe.
Have the same problem.

seutje’s picture

seutje commented

subscribing

even after turning off JS and manually (with firebug) editing the greyed out fields to rather high numbers, they would still appear somewhere in the middle on the create content page

luckysmack’s picture

luckysmack commented

subscribing

Same issue. no matter what i try i cant get the "title" of a node type to return to the top unless i remove all custom cck fields and then all is fine. adding another cck field in the orders get mixed again withoug trying to re-order them.

rupl’s picture

rupl
he/him
Primary language English
commented

Echoing the same problem.. While managing CCK fields for a custom content type, system-provided fields (taxonomy, menu, location) seem to creep higher and higher with each re-sort using the drag and drop JS.

Disabling JavaScript and manually renumbering the field order did not fix the issue for the system fields.

seutje’s picture

seutje commented

it appears like the custom weights are stored in the db (variables table I think), but the stored info is not or wrongfully used when the add node or edit node form is built

it does however handle it properly when building the manage fields screen

bartclarkson’s picture

bartclarkson commented

I turned off javascript, and numbered the items sequentially (including the greyed out boxes). Submit. Turn javascript back on. Worked out for me, because there weren't all that many fields. For the complicated content types, it remains an annoyance that certain system elements intersperse the cck.

markus_petrux’s picture

markus_petrux commented

I'm wondering if the problem happens on the 'Manage fields' section, in the Node Edit form, or both?

PS: Marked the following issue as a dup on this one: #347126: Setting Field Display Weight Above Title Doesn't Work

seutje’s picture

seutje commented

happens on node edit form and on node display, manage fields sections acts like it should afaik

markus_petrux’s picture

markus_petrux commented

happens on node edit form and on node display, manage fields sections acts like it should afaik

hmm... that helps to analize the problem, thanks! :-D

Let's see... weights for non-cck fields are applied in CCK at nodeapi(view) and form_alter() time. This is subject to load order of the modules. So if a module loads after CCK, then its fields cannot be affected by the code in CCK that alters their weights.

If this was it, then we would have to find a different method in CCK to apply the weights for non-CCK fields.

yched’s picture

yched commented

Ah, I think I got it.

markus_petrux is right - cck can only adjust weights of items that already exists by the time its own hook_nodeapi() and hook_form_alter() run. We can only be sure of that for core 'fields' - at least if the system weights have not been changed, *and* if CCK doesn't live in /modules with core modules, but in /sites/*/modules with contrib modules.

That's why contrib modules that want their 'fields' supported by CCK's d-n-d reordering need to set the weight in hook_nodeapi() / hook_form_alter() themselves, by asking CCK what's the user-defined weight :

$node->content[$view->name . '_' . $info['display']] = array(
  ... 
  '#weight' => module_exists('content') ? content_extra_field_weight($node->type, 'name_of_the_addition') : 10, // 10 being 'the default weight'
);

But of course we can't change core modules to do that.
So I think bottomline is : don't put cck in the root /modules. This is *bad* practice anyway - and I do not see what we could do fix the d-n-d behaviors in such cases.

markus_petrux’s picture

markus_petrux commented

I'm trying to see if it is possible to use pre_render (attached at end, if there are any) to perform the weight alterations of non-cck fields. #pre_render is executed in drupal_render before the elements are sorted by weight.

markus_petrux’s picture

markus_petrux commented
Status: Active » Needs review
StatusFileSize
new cck-356158-12.patch2.44 KB

Attached patch is against latest CCK 6.x-2.x-dev. It use #pre_render for both, nodeapi(view) and form_alter() to apply weights of non-CCK fields.

Since the problem not happened to me, I can't say if it works or not, only that it seems to not break anything, apparently. :)

markus_petrux’s picture

markus_petrux commented
StatusFileSize
new cck-356158-13.patch2.44 KB

Oops! fixed a typo in pre_render function name, sorry.

seutje’s picture

seutje commented

awesomenessnessness... I'ma test this as soon as I get the chance

jpdaut’s picture

jpdaut commented

markus petrux: would you have a patch for Drupal 5? that would be great, thanks.

markus_petrux’s picture

markus_petrux commented

#15: I'm sorry, I'm focussed on D6 development and I haven't used CCK in D5, so I can't tell if it can be backported easily. The concept is simple enough, thougn, imo.

yched’s picture

yched commented

Patch for D5 ? How could D5 need fixing, you cannot reorder non CCK fields in D5 ?

patrick@never.nu’s picture

patrick@never.nu commented

markus_petrux THANKYOU!! That was one f0cked bug to try and go around. Thanks a million.

CobraMP’s picture

CobraMP commented

Patch failed for me with latest 2.x-dev

assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354

yched’s picture

yched commented
Status: Needs review » Fixed
StatusFileSize
new cck-reorder-356158-20.patch2.26 KB

Going through #pre_render definitely sounds like a good idea.
Committed #13 (slightly altered, attached is the patch that got committed). Thanks Markus !

Let's close this, we'll reopen if new issues arise.

yched’s picture

yched commented

ported to HEAD for D7 (that part goes in contrib cck.module). Going to #pre_render is an excellent move in an entity-agnostic model (node, user, "fieldable entity"...). User.module is being reluctant, because it hacks around drupal_render(). Left that as a TODO.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

wickwood’s picture

wickwood commented
Category: bug » feature
Status: Closed (fixed) » Active

I'm so thankful that I found this thread!

I'm reopening with a feature request, because I think it would be helpful for themeing these forms, and probably for other reasons, if the weight field was not hidden. It would prevent guessing and having to turn javascript off. Perhaps this could be even turned on and off from the UI.

markus_petrux’s picture

markus_petrux commented
Category: feature » bug
Status: Active » Closed (fixed)

Please, open a separate issue, where you can link to this one, for example. But if you're talking about this for debugging purposes, then I think the devel module has something that can help here. On the other hand, if you mean to show the weight to users... then I believe this may potentially confuse as it is an input element not related to the date users need to deal with, it is just something related to the data entry method.