This sounds like two issues, but it's fixed by the same patch. After spending some time in the debugger, it looks like there's still a fair amount of work to be done in exporting rules to a feature -- this is related to #597334: Rules always appear overridden and #597326: Updating feature creates duplicate rules, along with #573586: Fix features integration.

However, a bigger problem is that if you add a rule to an existing feature, you're likely to clobber some of the existing rules, because the rules export cannot detect what rules it previously wrote. This is because the rules_features_export_render function appears to get called with different arguments.

Sometimes (during a diff, or when coming up with names for exported rules) $data (the second parameter) is a numerical array of rule names. Other times (during actual export) $data is an associative array with keys containing the rule names, and values that are the actual exported rules. This function handles the second case with correct results, but not the first. Because it's called with the first variation to determine the name of the rule to export (using rules_item_rule_export), the renaming of a rule to the exported feature name doesn't see the existing rule names, and so your newest export always gets named $module . '_1', clobbering the previous one.

Here's a quick hackish patch that detects what type of array $data is, and loads the $export array appropriately. This probably breaks rule_sets and rule_categories--I've only tested with actual rules (where it does seem to work).

CommentFileSizeAuthor
rules.patch1.9 KBfreelock

Comments

gordon’s picture

Status: Active » Needs work

I have taken a look at this, and it works on the detail view but the front page of features still says it is overwritten, and the diff shows it as changed.

fago’s picture

Status: Needs work » Fixed

I just overhauled the features integration, see http://drupal.org/cvs?commit=338456. Please test the dev snapshot generated this night - it should be fixed there. If not please reopen.

Status: Fixed » Closed (fixed)

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

jazzslider’s picture

Status: Closed (fixed) » Active

Hello!

Using Rules 6.x-1.2, released on March 26, 2010, I'm still experiencing this exact problem. Here are the conditions:

1. My existing feature includes five different rules in the exported category; for the sake of argument, let's call them rules A, B, C, D, and E.
2. Install and enable that feature on a given site; then, create another rule (let's call it rule F) in the same exported category.
3. Re-create the feature (using the web interface; I haven't tried it with drush). There will still be only five rules: F, B, C, D, and E.

So, for whatever reason, rules export is still exporting new rules using old names.

I'm curious, though, why you've chosen to rely on automatically-generated machine names for your rules instead of allowing the user to specify them? Most other features-integrated modules allow the user to pick their own machine names; doing so in rules's case would circumvent this problem entirely, as you wouldn't ever have to automatically generate a name at all.

Either way, I just wanted to confirm that this problem isn't fixed; if I get some time, I'll try to look a bit closer at why this is happening …but in the meantime, I'm hoping others will look into it as well :)

Thanks!
Adam

fago’s picture

Status: Active » Closed (fixed)

There is already an issue for that, so closing this one again: http://drupal.org/node/756888

jazzslider’s picture

Sound good; glad to see it's been fixed :)

Meanwhile, I went ahead and created another for machine-readable names on rules, since that kind of stands apart from this specific problem (although the current lack of user-authored machine-readable names definitely contributed to this issue in a roundabout way). Please check out #874802: Allow user to specify rules' machine-readable names, as with rule sets if you're interested in such things.

Thanks!
Adam

mitchell’s picture

Component: Features integration » Provided Module Integrations

Moving to "Provided Module Integrations" component.