Need a way to order values in a muti-values field

I'm facing the same issue. But instead of adding a weight column in the content_field_* tables, what about having another table, properties (or whatever), to store arbitrary properties that result in the relationship between node and each value in a multiple value field?

http://drupal.org/node/149708 was marked duplicate

The need for this functionality cannot be overstated. However, I'd almost rather have nothing at all than have to deal with one more of these Drupal weight fields (e.g. menu module, taxonomy, cck etc. ad nauseam). I hate em, I hate em, I hate em.

I cringe every time I give something a weight of -9, "I mean, I'm pretty sure this one is going to be first, but I should be smart and leave at least one space in case I need to go up to 10." It's like a scene out of Spinal Tap.

Then there's this one: "Uggh, I have to add 3 entries to the top of the order, but I only left space for one. Guess I'll have to shift all of these weights down a few… (submit... wait... reload), (submit... wait... reload) — Where am I again? -6 or -7? (submit... wait... reload) Doh, must've been 6 (submit... wait... reload), I could just use 8 or 9, surely that is heavier, but I probably need to leave some space at the bottom in case I need to add any to the bottom later."

Please, no weights. Because it is not about weight, it's about order. This is an important distinction to make. In the case of multiple CCK fields, we don't care how heavy something is, we only care about what comes before and after it.

The fact that my field has a weight of -8 or -9 has no bearing outside of this context, so from a UI standpoint there is no reason why a user should ever need to assign an absolute value here.

As far as I'm concerned, the Views and Panels UIs have already solved this problem perfectly, with the up down arrows. Can't we do the same here?

In total agreement. weights are NOT practical for this kind of thing...

the only way a weight would work is if each time you change one it recalculates all the others on the fly and moves the nearest one plus all lower down (decrements them). This means that a weight is no longer an arbitrary set from -10 to +10. Rather they are the COMPLETE SET of all numbers 0-x or 1-x of the number of nodes (e.g. 133 field instances means there are 133 possible values, 16 instance gets 16 possible values).

At that point you are basically just recording an additional db field ("order") for each cck field.

the interface could use any or all of teh following:

1) dropdowns (refreshes all order dropdowns on every onsubmit)
2) arrows to move up and down (pain in the butt for big order changes unless js based)
3) js drag and drop

Anybody know if there is any intent to do this or if it's just an idea at this point floating in limbo?

thanks

Of course if there is a way to use the existing weight field that is great. Just as long as the UI doesn't force the user to assign non-flexible weight values.

Does the weight field scale to allow upwards of 20 fields without having to resort to another form of sorting?

What do the View and Panels modules use? Do they use the weight fields?

Finally, I will contribute funds for someone to incorporate the e sorting feature — exactly like that currently in use by Views and Panels — for CCK multi-value fields (as long as it works for image fields too). Please contact me with an estimated fee if you are interested.

If someone can clarify what is required here I will either spend money or develop it myself.

I am trying to recreate something like http://www.kinetasystems.com/space4work/ which requires (obviously visible) "sections" (can be done with CCK) which will contain arbitrarily ordered nodes. Node Queue is fine, but not suitable for this purpose. Also, I might want the option to have some of these nodes visible in a menu block, and some only visible in the node teaser display (ie on front page - presumably achieved by a system of checkboxes).

I am suggesting maybe a new module could do this? Something like "CCK ordered node reference" - hereby we can select as many nodes as we wish, using the existing node ref module's filtering system, and order them arbitrarily by weight (using a php and jQuery interface), hopefully without fear of reprisal from Core. CCK-based "sections" could contain an instance of this new ordered reference field, and thus the "section" cck type would act as a stand-alone container for an arbitrary group of nodes. This would trump any current ideas I have of how to achieve what I want.

Alternative ways that I have thought of: nested node queues (using cck, node ref, node queue) - this just sucks, it's complicated and unwieldy (AFAICT); otherwise, I would have to use menus, but again this invokes use of the existing weight system for a backend user that simply "doesn't need this kind of hassle" - it's far too fiddly to administer.

At the moment it looks like I will have to implement CCK sections with unordered multiple node references, and carefully title the nodes so as to get the order I want. Again, ridiculous.

Potentially, I could also use CCK "sections" with Views and Viewfield, but again I cannot arbitrarily order Views, otherwise I would have just done that in the first place :) I guess it would be nice if Views could perform this kind of ordering, but it is a big ask (maybe?).

IMHO, Drupal is badly missing a node tree structure, as a contrib module, if not in core. It's pretty simple, and it would destroy a large number of "bounces" that Drupal gets from the horrific learning curve. (This comment is based on my having zero knowledge of the D6 menu system, but I can't see that it's going to be *that* different). This would give Drupal a clear advantage in building brochureware style sites, as well as those that combine that (bware) functionality with more complex and flexible facets of Drupal, namely commerce, SEO, CCK/Views.

Let's do something?

would be quite nice to get this into cck 2. perhaps add a weight field to backend but let contrib modules add the UI. i suspect UI will be a bit thorny.

Since CCK in 6.x is taking control of multiple values there it should be trivial to get the content module to control the delta in that version. The UI is the issue. What would it look like and where would it be? It needs to be general enough to work for all kinds of modules, not just something specific to a certain situation.

i would start off with a 2 column table where the left column contains weight form elements and the right contains the field's form elements. let modules form_alter it as needed.

oh, and i would add an option on field definition like 'multiple values - with weight field' or 'multiple values - with order'. that is a hint to content module to show the extra column of weight form elements.

I guess we could steal Earl's JS up / down arrows from nodequeue.module ?
Another cool feature made possible by multiples in core :-)
OK, not done yet, but at least it's possible...

Have you guys seen the taxonomy_manager module's UI yet? It has the sickest interface for reordering elements as well as editing them on the spot. If we could implement something like this for multiple node reference fields— well, I would cry.

If you have two fields set to "multiple", you'd want to be able to order individual values relative to all values (in all fields), not just to other values within the same field.

+1 on stilling Earl's JS up/ down arrows. Also the marking in Red of moved fields, so user will know they need to save the form.

Yched has posted something for this at http://drupal.org/node/195268 to do this with drag and drop, so we'll move discussion of implementation over to that thread.