Component order may be incorrect on cloning components (when components have identical weights)

I'm not sure either of the things you've described are bugs. The API has changed significantly, and it seems that your code simply isn't compatible with the new changes. I'd suggest removing the code you have (especially any CSS affecting Webform) and writing it again. As noted in the submission guidelines, I don't provide help with custom code written on top of Webform. If either of these problems exist in Webform without code modifications (no patches either), then I'll be happy to help where I can.

Thanks alextronic, updating the title to reflect the issue at hand. If you can provide a set of steps to reproduce the problem I'll have a look.

I need more information on how to reproduce this bug. There shouldn't be any difference between fields created with 2.x and 3.x, both have simple "weight" properties stored in the database to keep them ordered and these aren't changed in any way between the two versions.

Please reopen if instructions on how to reproduce this problem can be provided.

I can consistently produce this behaviour in 6.x-3.6

1) Create a new webform node
2) Add a textfield labelled start
3) And one labelled end
4) Add a fieldset labelled middle and drag it to be in the middle
SELECT cid,pid,form_key,name,weight FROM `webform_component` where nid =18 order by weight;
cid pid form_key name weight
1 0 start start 0
3 0 middle middle 1
2 0 end end 2

5) Add 3 example components and set them as children of middle.
6) Add parent field-set for middle fieldset (this is as user demonstrated)
SQL query: SELECT nid,pid,form_key,name,weight FROM `webform_component` where nid = 18 order by weight;

nid pid form_key name weight
18 0 start start 0
18 0 middle_parent middle-parent 1
18 7 middle middle 2
18 0 end end 3
18 3 example_1 example 1 3
18 3 example_2 example 2 4
18 3 example_3 example 3 5

7) Clone middle fieldset n times
8) Note here components displayed as expected both in webform edit view and in node view
SQL query: SELECT nid,pid,form_key,name,weight FROM `webform_component` where nid = 18 order by weight;
nid pid form_key name weight
18 0 start start 0
18 0 middle_parent middle-parent 1
18 7 middle middle 2
18 7 middle_1 middle 1 2
18 7 middle_2 middle 2 2
18 7 middle_3 middle 3 2
18 0 end end 3
18 3 example_1 example 1 3
18 8 example_1 example 1 3
18 12 example_1 example 1 3
18 16 example_1 example 1 3
18 3 example_2 example 2 4
18 8 example_2 example 2 4
18 12 example_2 example 2 4
18 16 example_2 example 2 4
18 3 example_3 example 3 5
18 8 example_3 example 3 5
18 12 example_3 example 3 5
18 16 example_3 example 3 5

9) Clone one of the cloned fieldsets (here I clone middle 2). The components are displayed as you’d expect in webform edit view -> middle, middle 1, middle 2, middle 3 middle 4.
11) However when you view the form onscreen the ordering is now middle 1, middle, …2, …3, …4

SQL query: SELECT cid,nid,pid,form_key,name,weight FROM `webform_component` where nid = 18 order by weight;
cid nid pid form_key name weight
1 18 0 start start 0
7 18 0 middle_parent middle-parent 1
3 18 7 middle middle 2
8 18 7 middle_1 middle 1 2
12 18 7 middle_2 middle 2 2
16 18 7 middle_3 middle 3 2
20 18 7 middle_4 middle 4 2
2 18 0 end end 3
4 18 3 example_1 example 1 3
9 18 8 example_1 example 1 3
13 18 12 example_1 example 1 3
17 18 16 example_1 example 1 3
21 18 20 example_1 example 1 3
5 18 3 example_2 example 2 4
10 18 8 example_2 example 2 4
14 18 12 example_2 example 2 4
18 18 16 example_2 example 2 4
22 18 20 example_2 example 2 4
6 18 3 example_3 example 3 5
11 18 8 example_3 example 3 5
15 18 12 example_3 example 3 5
19 18 16 example_3 example 3 5
23 18 20 example_3 example 3 5
12) Comparing the sql results from the two sets of clonings doesn’t show an obvious difference in how the new item is being added. Still an identical weight as the parent. Matching weights for its children.

I can't explain the behaviour yet. But I can demonstrate it...

Attaching document with screenshots.

Since the weights are equal I guess the "bug" might be in

/**
 * Helper for the uasort in webform_tree_sort()
 */
function _webform_components_sort($a, $b) {
  if ($a['weight'] == $b['weight']) {
    return strcasecmp($a['name'], $b['name']);
  }
  return ($a['weight'] < $b['weight']) ? -1 : 1;
} 

Interestingly if I make middle, middle 1 and middle 2 fieldsets. I don't get the incorrect ordering. If I then clone again I do.

Also, if I then drag the fieldset out of the parent. Save and then drag it back in to position it displays correctly. At this point the weight of middle 1 i.e. the first cloned fieldset is set to equal the previous highest weight. the first contained field (in each cloned fieldset) and the next fieldset is set to that plus 1 and so on.

nid cid pid form_key name type value extra mandatory weight
21 1 0 start start textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 2
21 4 3 middle middle fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 4
21 3 0 middle_parent middle-parent fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 4
21 2 0 end end textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 5
21 8 3 middle_1 middle 1 fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 5
21 5 4 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 9 8 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 13 12 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 17 16 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 21 20 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 25 24 example_1 example 1 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 6
21 12 3 middle_2 middle 2 fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 6
21 6 4 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 10 8 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 14 12 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 18 16 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 22 20 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 26 24 example_2 example 2 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 7
21 16 3 middle_3 middle 3 fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 7
21 7 4 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 11 8 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 15 12 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 19 16 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 23 20 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 27 24 example_3 example 3 textfield a:12:{s:13:"title_display";i:0;s:8:"disabled";i:0;... 0 8
21 20 3 middle_4 middle 4 fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 8
21 24 3 middle_5 middle 5 fieldset a:7:{s:13:"title_display";i:0;s:11:"collapsible";i... 0 9

I think that weight change should probably be applied on cloning not just on reordering.

Thanks Paul for your extensive sleuthing. Your description makes the entire problem quite clear. As to the cause of the problem, you identified it in #10. We're using a custom sort algorithm, which is passed into the PHP uasort() function to do the ordering. But as noted in the documentation for uasort:

If two members compare as equal, their order in the sorted array is undefined.

So this means that if multiple components have the same weight and they have the same name, then the order could come out unexpected and inconsistently. The database has the rows in the right order (since that's how they were inserted) but once run through PHP's sorting, they come out inconsistently. In the past we've solved this by adding "mircoweights" (like 2.1, 2.2, 2.3, etc.) when the fields come out of the database to ensure the ordering is consistent even if fields have the same weights.

I was a bit lost looking for where the weights are set on save/re-ordering. If you point me in the right direction I'm happy to try and have the weights update on clone and I'll submit a patch. Webforms is saving my bacon at work right now so I definitely feel like contributing back.

I'm also having troubles with fieldsets. All the children items in fieldsets just became invisible after I upgraded to webform 6.x-3.x-dev. It would be really greate if someone could help me with this bug.

@lexa-s That sounds like a different issue. I appreciate searching instead of posting a new issue immediately, but that sounds entirely unrelated to this problem.

Just looking for an update on #13.

Is increasing the weight of a cloned fieldset the desired behaviour?

I found the way around the problem of cloned elements having the same weight was this:

• Clone some elements
• On the webform, drag one of the cloned elements so that the order of the elements changes - then drag back if you don't want to change the order
• Save the form

This seems to be sufficient to trigger whatever code assigns weights to elements to run, and the cloned elements get their appropriate weights in the database.

Here's my solution, which may be similar to @neilt17's...

Within the cloned field groups, number the child fields consecutively as if they were not contained within a field group. Like this...

Group1: weight=10
Name: weight=1
Address: weight=2
Group2: weight=11
Name: weight=3
Address: weight=4
Group3: weight=12
Name: weight=5
Address: weight=6

This puts Groups 1, 2 and 3 in their proper order when viewing the webform.

This works properly in the 7.x-4.x branch. Unless someone writes a patch and someone else can test and mark it RTBC, I'm closing this issue as there aren't resources for further 6.x development, especially for minor issues.