Allow specificying order of components or depdency between components when reverting/rebuilding

Sounds like a possible solution to #1063204-86: Adding a new permission causes integrity constraint violation. I like the component dependency idea.

This is basically the patch from #1063204-79: Adding a new permission causes integrity constraint violation with a minor issue fixed. Whilst it doesn't actually provide a way to order the components, it does adjust the component order to make user_permission last which fixes quite a few issues related to incorrect component ordering.

This can be an issue when using UUID Features. For example if you're using UUID Features and exporting an entity bundle, that bundle may get created before the fields are attached. (This is happening on our situation.)

It would be a hacky work around, but what if alphabetical sort was used so all uuid_* components technically run last and we have some predictability on how components are built?

Or use drupal_sort_weight() sorting on components, new comment to follow.

Could use weight attribute using drupal_sort_weight().

When declaring hook_features_api():

/**
 * Implements hook_features_api().
 */
function image_features_api() {
  return array(
    'image' => array(
      'name' => t('Image styles'),
      'feature_source' => TRUE,
      'default_hook' => 'image_default_styles',
      'alter_hook' => 'image_styles',
      'weight' => 0,
    )
  );
}

This way components can be given a custom weight. Should probably introduce a features_api_alter() so users can alter the weights as needed.

+++ b/features.module
@@ -1109,3 +1110,22 @@ function features_get_deprecated($components = array()) {
+
+/**
+ * Sort the components array to put the user_permission component at the end.
+ *
+ * @param $components
+ *   The array of components (component_info) from features_get_components typically.
+ *
+ * @return array
+ *   The array of components after sorting.
+ */
+function _features_sort_components($components = array()) {
+  $key = array_search('user_permission', $components);
+  if ($key !== FALSE) {
+    unset($components[$key]);
+    $components[] = 'user_permission';
+  }
+
+  return $components;
+}

This could load the components array and sort properly then.

I tried the patch from #2 but in my case it failed. Perhaps its outdated?

patch -p1 < 1997412-features-component-order.patch
patching file features.drush.inc
Hunk #1 succeeded at 720 (offset -1 lines).
patching file features.module
Hunk #1 FAILED at 933.
Hunk #2 succeeded at 1196 with fuzz 2 (offset 87 lines)

AlfTheCat, the patch is highly outdated. There's been Features 2.1 and 2.2 since this was last discussed, in which component locking was introduced (I believe.) So a lot of things shifted around. Shouldn't be hard to re-roll.

Please consider whether the approach in #1216224: Provide documentation about feature component processing order that's already supported by Features would fit your needs.

I have created a new patch against 7.x-2.5. It's the same patch provided by mrfelton, it just adds the changes into the correct lines.

Rolling a new patch against today's 7.x-2.x-dev

I'm a bit confused on this one. I like the discussion about how to solve this generally, but the patch seems to only "fix it" for permissions. Can we get something that is a bit more general purpose than this? I hate to have hard-coded exceptions like this.

I'm a bit confused on this one. I like the discussion about how to solve this generally, but the patch seems to only "fix it" for permissions. Can we get something that is a bit more general purpose than this? I hate to have hard-coded exceptions like this.

Hi mpotter,

I think in this case the only part that needs to be fixed are permissions. Permissions should be the last thing to be reverted in a feature. As comment #3 states, there can be a number of scenarios where permissions attempt to revert before entities are created.

Adding a general weight option though would be fine too. I guess putting in something on the features settings page with either checkboxes or a draggable weight list?

I'm closing this in favor of #1814122: Allow components to be ordered by weight because there we already have a patch.