Drupal Commerce is broken with Rules 7.x-2.8

I can confirm this breaks pricing rules. It works fine in the cart. But as soon as you start the checkout process none of the rules are applied. This is with 7.x-2.8. Had to downgrade to 7.x-2.7 and everything is working fine again.

My custom discount rule also stopped working. Downgrading to 2.7 made it start to work, though I think there might be still some glitches - the pricing rule used to be applied right after adding the products to the cart, now it seems it happens after entering the cart.
Contrary from what previous user claimed, for me the rule stopped working altogether, and it got back right after a downgrade. I had a rule using commerce extra rules conditions, and rewriting it for the newer Commerce Rules Extra did not change anything (yes. I did spend a couple of hours not knowing what's on)

v2.8 breaks the pricing rules on my site too. Had to downgrade to 2.7 for the time being. Here are the rule details:

{ "rules_member_price" : {
    "LABEL" : "Member price",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "REQUIRES" : [ "rules", "commerce_line_item", "commerce_product_reference" ],
    "ON" : { "commerce_product_calculate_sell_price" : [] },
    "IF" : [
      { "entity_has_field" : { "entity" : [ "commerce-line-item" ], "field" : "commerce_product" } },
      { "entity_has_field" : {
          "entity" : [ "commerce-line-item:commerce-product" ],
          "field" : "field_member_price"
        }
      },
      { "entity_has_field" : { "entity" : [ "commerce-line-item" ], "field" : "field_member" } },
      { "data_is" : { "data" : [ "commerce-line-item:field-member" ], "value" : "1" } }
    ],
    "DO" : [
      { "commerce_line_item_unit_price_amount" : {
          "commerce_line_item" : [ "commerce_line_item" ],
          "amount" : [ "commerce-line-item:commerce-product:field-member-price:amount" ],
          "component_name" : "base_price",
          "round_mode" : "1"
        }
      }
    ]
  }
}

Same problem here with breaking Drupal Commerce pricing rules. Rule is below, if that's of use.

Is there a way to downgrade without uninstalling Rules? We use rules quite extensively, and it would be a lot of work to rebuild the rules, besides the fact that a lot of our Commerce modules require Rules. I've not faced this kind of situation before. Worse comes to worse, I can revert to this morning's backup, but I've done a lot of work today.

Thanks!

{ "rules_donation_amount" : {
    "LABEL" : "Donation Amount",
    "PLUGIN" : "reaction rule",
    "WEIGHT" : "-10",
    "OWNER" : "rules",
    "REQUIRES" : [ "rules", "commerce_line_item", "commerce_product_reference" ],
    "ON" : { "commerce_product_calculate_sell_price" : [] },
    "IF" : [
      { "entity_has_field" : { "entity" : [ "commerce-line-item" ], "field" : "field_amount" } }
    ],
    "DO" : [
      { "data_set" : { "data" : [ "commerce-line-item:quantity" ], "value" : "1" } },
      { "commerce_line_item_unit_price_amount" : {
          "commerce_line_item" : [ "commerce_line_item" ],
          "amount" : [ "commerce-line-item:field-amount:amount" ],
          "component_name" : "base_price",
          "round_mode" : "1"
        }
      }
    ]
  }
}

donkiely, simply replace the rules module directory with 2.7. i don't believe there were any database schema updates between 2.7 and 2.8 so you should be fine. Don't forget to run the update script after though.

Hey,

the problem was introduced with patch from this #2324587: Rules might be triggered too early in the bootstrap. It breaks invocation of commerce pricing rules. It is little change in

function rules_event_invocation_enabled($enable = NULL) {
-  static $invocation_enabled = TRUE;
+  static $invocation_enabled = FALSE;

Same here. After updating the Rules module from 7.x-2.7 to 7.x-2.8, the checkout price from each cart was cleared to zero!

Reverting back to 7.x-2.7 solved the problem, so in 7.x-2.8 there is something badly broken when using together with Drupal Commerce.

I'm not using Commerce but my rule broke too.

In my case the rule was being triggered through mymodule_init, which happened to be called before rules_init and so rules_event_invocation_enabled(TRUE) was not called.

This patch fixes my problem, hopefully it solves the Commerce issue too.

(There might well be a better way that relying on the hook_init order though.)

After doing my own research I can confirm that it was broken because rules_init hook whas called to late. in my case 5 other functions fired rules_event_invocation_enabled before rules_event_invocation_enabled(TRUE). It worked in 2.7 of course because initialy $invocation_enabled was set to TRUE

Just confirming the rules 2.8 breaks product pricing rules on 2 commerce sites I manage as well. Like neorush, the behavior we see is that the discount works fine in the cart, but at checkout, it's no longer applied.

Downgrading to Rules 2.7 fixes the problem.

Confirming that Rules 2.8 breaks product pricing rules on my commerce sites also.
Downgrading to Rules 2.7 solves the problem.

We lost about $3000 worth of orders in the two days it was failing. Downgrading solved the problem but I have to say this is really bush league amateur work.

I downgraded to Rules 2.7 and now my lineitems works again.
But my order total is still calculated with the default product price.

Marking as critical since Commerce is broken. Reopened #2324587: Rules might be triggered too early in the bootstrap.

I don't have any pricing rules in place but this bug makes Event "Select available payment methods" get evaluated, and its Rules get run, right at the start when adding a product to the cart.

Is there a chance this is impacting Commerce Discounts or Commerce Coupons? We started seeing some weirdness there at the same time as updating Rules to 2.8.

If you are using Drupal Commerce, you should definitely use Rules 7.x-2.7! 2.8 may break a lot of things.

I can confirm the problem for Drupal Commerce and this is truely critical. I was wondering a lot why strange things happened and checkout did not work correctly anymore.

Changing title to make it clear Drupal Commerce won't work correctly anymore with Rules 7.x-2.8.

I haven't been able to get this really fixed.

I downgraded to Rules 2.7 but I am still seeing the event "Select available payment methods" reacted to when I first add a product to the cart. I'm pretty sure that started with this upgrade to 2.8.

Would appreciate any reports of success or failure in rolling back to Rules 2.7.

EDIT: The rollback to 2.7 _did_ work .... I had another simultaneous problem.

For me rolling back worked! Before no product could be added to cart.

I rolled back to 2.7 having noticed a problem in the Select (or other) module for Commerce. I'm guessing this is part of the same issue but have raised an issue on there to be sure https://www.drupal.org/node/2405695

rolling back worked! but thats cannot the solution itt hink

Rolling back to Rules 7.x-2.7 fixed my price calculation issues.

Not sure if this helps you track down the problem, but I found that the rules were firing, but the result was being lost.
If I reload the line item entity from the cache by adding the following code in commerce_cart.module it seems to work.

1100      // Process the unit price through Rules so it reflects the user's actual
1101      // current purchase price.
1102      rules_invoke_event('commerce_product_calculate_sell_price', $cloned_line_item);
+         entity_get_controller('commerce_line_item')->resetCache(array($cloned_line_item->line_item_id));
+         $cloned_line_item = commerce_line_item_load($cloned_line_item->line_item_id);
1103    }

So I'm not sure if its a Rules, Entity or Commerce issue.

Rolling back to Rules 7.x-2.7 fixed the issue I was having with tax calculations not showing up in the checkout display on a fresh site. I will therefore continue to use the 2.7 version of rules with commerce version 7.x-1.11 until things get resolved.

hm, a pity that was not discovered before release. Looks like no one tries drupal commerce with rules dev releases :-(

oh, I see. I checked for criticals before the release, but sadly it wasn't critical then.

Same problem here. Downgrading to rules version 2.7 solved my problem.

I just upgraded to 2.8. Mistakes can always happen, but I cannot understand why this remains so for a month even without a warning on the available updates page or similar.

@TheoRichel The most likely reason that this remains is that almost all module maintainers do this on a volunteer basis. Most of them do not get paid to make updates to modules. Until a project they are personally working on need a feature or update or they have some free time, it likely won't get fixed. I have found that one of the fastest ways to get an issue solved if you are not able to do it yourself, is to message the module maintainers and offer a bounty to get the issue fixed. Depending on the severity it often doesn't take much. The developers that made this module and kindly posted it up here for all to use don't have a responsibility to make sure that every release works for every use case.

Also to fix your issue just downgrade to 2.7 and all should be good.

As to the volunteering part. I do not get paid for my Drupal work either. I am not a coder though, just a site builder. I appreciate the work that goes into programming, and that errors cannot be fixed that fast. But if the owner of some module discovers an error of this magnitude and doesnt even warn others then a lot of sympathy for the volunteering work is lost.
Indeed, as you say developers have no responsibility to make sure that every release works for every use case, but to use that argument when two of the most important Drupal modules apparently clash makes me wonder if you feel any responsibility at all.

Of course I have downgraded and it works again.

Agreeing with @TheoRichel, this issue needs to be mentioned on the project page.

Shouldn't 7.2.8 be moved away from the project page, so others do not have problems with this?
greetings, Martijn

Setting version back to 2.8 ...don't know why @Leeteq changed it ???

Rules 2.8 WILL break your Drupal Commerce site.

Looks like setting

<?php
static $invocation_enabled = TRUE;
?>

Fixed commerce rules for me so the patch at #6 should work for those who dont want to role back

@Channel Islander; I assume the main development goes on in the -dev branch, therefore I changed it. Any special reason why it shouldnt be in -dev? (this issue already have the information in it that it is related to 2.8. That is not lost when shifting it to -dev.)

@Leeteq: If the issue is marked as being in the -dev branch, people will assume that the production release is not affected. But it is.

In my Modules page I still get prodded to upgared to 2.8 and when I click on the 'Release Notes' there still is no mention of this problem. Nor on the homepage. A quarter of a million users. Should we ask for a quote how much it costs to add this one line, after all it is an extra feature.

Not much useful payload here in the comments... :-|

Patch in comment #9 does not work for us here, taxes do not get calculated in Commerce.

I tested the proposed solution in comment #6 and mentionned in #40 and indeed it works, Commerce pricing rules get fired with Rules 2.8 and this "patch" :

rules.module line 1679 :

function rules_event_invocation_enabled($enable = NULL) {
  static $invocation_enabled = TRUE; // TRUE instead of FALSE to make Commerce pricing rules work again
...

But I am not sure if we are looking for trouble making so?

It changes the logic of this function "rules_event_invocation_enabled" that was introduced in 2.8 exactly for that reason :

* Rules invocation is disabled by default, such that Rules does not operate
* when Drupal is not fully bootstrapped. It gets enabled in rules_init() and
* rules_enable().

If we put TRUE, Rules invocation will be enabled by default instead...

@fago What is your take on this?

Thank you

Thanks @LeDucDuBleuet, I can confirm that this fixes the issue. I am using along with Commerce the Commerce Express Checkout (no order review) and Coupon 2.x. and all seems to work well now.

Nice work here - thanks. I can also confirm that #44 enables Commerce Discount and Coupons to function again. Looks to be a duplicate/parallel discussion here: https://www.drupal.org/node/2324587

You're all very brave, hacking a module as complex as Rules and changing a piece of logic that you don't understand from True to False.

Myself, I would be worried that such a hack would have other, unforeseen consequences. Rules is used throughout my sites, not just by a Commerce sub-module or two!

It takes about 90 seconds to download Rules 2.7 and overwrite the 2.8 directory in the modules.

Here's one guy who will be waiting for a fix!

@47, and with such comments, you make it harder to get a fix.

@roball Actually I think that a fix is likely to be provided more quickly with accurate reports of errors, rather than guesswork. Changing code based on someone else's experimentation and applying it to a production site, and then declaring it fixed because your one symptom disappeared, is not very smart, and it doesn't provide good support to other users who come to this thread later. I'm just sharing advice learned over the years. But you are welcome to your opinion.

The solution on fixing the bug the right way is being discussed with this module's main developer at #2324587: Rules might be triggered too early in the bootstrap. It does not make much sense to fill this issue with endless comments, while the fixing process is already being in progress on the other issue.

Agreed that changing the logic is not a fix - rather a clue. The discussion on https://www.drupal.org/node/2324587 looks to have a good pathway to resolution by addressing the trigger point. Might want to have a look over there and join that discussion.

Nobody said this was "Fixed". I personnaly tested putting $invocation_enabled to TRUE on a dev site and I am still using Rules 2.7 on all my production sites. I do not recommend anybody to put $invocation_enabled to TRUE by default on a production site. I did not provide a patch because I really don't think it is a good idea to blindly invert that logic without further looking into this.

That is why I was asking for the maintainer point of view on this...

Also, should we mark this bug as a duplicate of https://www.drupal.org/node/2324587 ?

Not sure if this commerce bug has been link to from here: https://www.drupal.org/node/2224019 adding a unit to the basket shows the price to be $1. Rolling Rules back to 2.7 fixes this. I assume it is the same issue.

Following.

Downgrading for now seems to be a decent and working WORKAROUND.

Also patch here ( https://www.drupal.org/node/2324587#comment-9630729 ) seems to fix things for me.
Can anyone confirm this too, so we can middle us too in that post.

Rolling back to Rules 2.7 worked for me. Will look into the patch referenced node/2324587
Thanks for the pointer Gleach

If you are reading this, and you write software, wait until major versions to change system default values.

Don't want something in version 2.8 to be invoked the way it is in 2.7? Great! Wait until version 3!

Minor updates are not for changing core functionally.

Patch mentioned by @gleach has been committed to rules project. #2324587: Rules might be triggered too early in the bootstrap

-

I also confirm that latest build of Rules 7.x-2.x-dev resolved problems with rules not being fired during checkout process.

Closing as duplicate because committed patch is from other issue #2324587

Just wanted to clarify for anyone following this issue that the fix is in the new 7.x-2.9 release now.

I'm still seeing some discount rules evaluate but not take effect when testing with 7.x-2.9. Downgrading to 7.x-2.7 restores functionality. (Rule evaluates, but price total is not changed.)

We're not having any issues at this time. @#61, do you see anything in the Rules debug log that might indicate why? I believe this issue was about Rules not firing, so if your issue is that the Rule is firing but the pricing isn't taking effect, that is probably a separate issue altogether.

#60 about updating from 2.8 to 2.9
are any database schema updates between 2.8 and 2.9 ??
so i just replace directory?
offcource i ll make a db and directory backup in any case

Thanks

Dear George, it is a good practice to always run database updates after you update a module. Just make that a routine and you don't have to worry about it. And in stead of replacing the directory you could use the Drupal core update manager. That is much more easy. Or even better, use Drush...

Just to confirm that after an update to rules 2.9 this week I am seeing an issue with VAT (UK 20% sales tax) on commerce orders (latest commerce).

This only appears to affect customers who log in when going through checkout so anon checkouts are fine.

All appears fine in the order views - order view, order edit etc (commerce backoffice with quick view) but the payment sent to sagepay is minus the VAT element on the product sub total (shipping VAT is fine).

I will most prob roll back to 2.7 if I cant find another fix...