Always export in the same order

This issue is actually being experienced on multiple levels of the exported rules, here is an example to explain the first scenario:

Lets say you have a feature called 'test_feature' and you want to add two rules to it.

1) Edit the rules, and add the category 'test_feature'
2) Go Create the feature, and add in the rules in the test_feature category.
3) The resulting feature creates a file test_feature.features.inc with an implementation of hook_rules_default(), containing the two exported rules:

  return array(
    'rules' => array(
      'test_feature_1' => array( ... ),
      'test_feature_2' => array( ... ),
    ),
  );

4) You unzip the feature and install it in your site.
5) You remove the 2 hand-made rules, in favor of the newly created ones from the feature.
6) You edit the Second rule, make some minor change in a text string or something.
7) Note that the modified rule is moved to the top of the list in the web interface, and now has a status of Modified.
8) Re-create the feature, to include these modifications in your rule, expecting perhaps a one-line change...
9) Download / unzip the new feature only to find out that the entire rule list is reorganized, with the SECOND rule, before the FIRST.

  return array(
    'rules' => array(
      'test_feature_2' => array( ... ),
      'test_feature_1' => array( ... ),
    ),
  );

Deleted, double-post.

Even if this first scenario was fixed, there is still a second issue that are causing trouble. The order of array keys inside each exported rule's actions also easily get rearranged.

On one export the order is like this:

        '#actions' => array(
          '0' => array(
            '#weight' => -1,
            '#info' => array( ... ),
            '#name' => 'name_of_an_action_provided_by_module_x',
            '#settings' => array( ... ),
          ),

But on a subsequent export, after some modifications from the web interface, the order changes:

        '#actions' => array(
          '0' => array(
            '#name' => 'name_of_an_action_provided_by_module_x',
            '#settings' => array( ... ),
            '#info' => array( ... ),
            '#weight' => -1,
          ),

These may seem like trivial issues but they create DIFFs and commit records that are really really impossible to read/understand/walk through. If there were a way to sort alphabetically these things that dont depend on array key order, we could make predictable exports, and easily track changes between subsequent exports.

@DamienMcKenna

So your patch fixes the internal sort of each element inside the first level of each rule that is exported. But this doent sort the overall listing of rules. For some reason, when you edit test_feature_2 rule, it is still getting inserted before test_feature_1 in the export. In function rules_categories_features_export_render() I put a print_r($export); between the call to rules_export_items, and features_var_export() and sure enough, only the changed rule got printed, which means to me somehow features_var_export() is integrating the changed elements into the pre-existing elements somewhere else.

Here is a further enhancement on your patch that handles scenario 2, where the #actions and #conditions of specific rules would appear out of order.

Oops. maybe this patch will actually work.

retest.

Working on a new version...

> Does the order of action in a rule really change once it has been created?

I haven't seen the order of (multiple) actions gets changed between exports, but if you look at the patch we are not sorting the actions themselves, which are always exported in natural order with string keys as ascending integers from zero (eg $rule['#actions']['0'], $rule['#actions']['1'])

We are instead ordering the internal elements in each action. #3 explains the situation that happens quite frequently. For instance, I often see that the #weight variable gets pushed to the first array index, without any explanation, or anything having been changed in the interface page for that action at all.

Good point about recursively applying. and admittedly, i havent tested any of the logical operands in chaining conditions to see how those would be affected by export.

I'm on the fence about making the element order consistent for the entire module (eg when the element is edited), instead of special casing it just for exports, because running recursive ksorts might be unnecessarily more processor intensive, causing longer page loads while administering Rules from the interface. Whereas the sorting on export is an infrequent task that is expected to take a little while to complete.

I stumbled back across then once I updated to 6.x-1.4 and the patch from #9 no longer applied, so I cleaned it up (based on feedback from #11) and updated it to apply against 6.x-1.4.

After applying this patch, edited rules are now back to exporting in the correct order. :)

Granted there are additional concerns about recursive chains etc that remain untested, but since this isn't a 'destructive' patch, is there any opposition to getting this enhancement into the codebase?

First attempt at using git for the patch, applied against -dev