6
Answers
Vote up!
2
Vote down!

User not created for anonymous orders; email not sent

Hi,

I've got a site running Drupal Commerce that isn't creating a new user for anonymous orders, and isn't sending a confirmation email to those anonymous orders once the checkout is complete, even though there are Rules set up to do both of those things.

I've got Drupal Commerce 7.x-1.7, running, Entity 7.x-1.1, Rules 7.x-2.3, Drupal Core 7.20. The store on my site is running fine for users that already have accounts on the site: they are able to place orders, and they receive a confirmation email once the checkout process is complete. All orders are being processed through PayPal; users are directed to PayPal for payment, and then back to the site once payment is complete. All good.

But if an anonymous user places an order, a couple of things seem to go wrong. Anonymous users placing an order are prompted to enter their email address—unlike registered users—which is a good thing. They are able to complete the checkout process. But after they've done so, they don't receive a confirmation email for their order, and a user is not created for them.

I'm still a bit new to Rules, but at first glace it looks like the rule "Create a new account for an anonymous order" is set up correctly. I haven't added any custom fields to to site user accounts (per
this post
). The log shows that the order has been created, along with a variety of PayPal API and server messages that all look ok.

commerce_paypal_ec also shows these two messages in the log:

IPN validated for Order [order#] with ID [id#].
IPN for Order [order#] ignored: this operation was accommodated in the direct API response.

And that's about all I've got, so far. Anyone out there run into anything similar, or have any ideas? Thanks.

Asked by: zgreen
on May 31, 2013

6 Answers

Vote up!
0
Vote down!

Hi,

I'm having a similar issue. We saw our first orders come in which created accounts as expected, then all of a sudden we're getting none. I'll post if we determine any specifics.

Cheers,
John

Answer by: housser
Posted: Sep 5, 2013
Vote up!
0
Vote down!

I found the issue in my case, was that I had a separate rule that executed "When an order is first paid in full" that changed the order status to "Processing" (as it was strange to look at orders that had been paid in full - for events - as still "Pending").

Seems as though when we skipped the status to Processing a few of the other rules weren't triggering.

Answer by: housser
Posted: Oct 2, 2013
Vote up!
0
Vote down!

I found the issue in my case, was that I had a separate rule that executed "When an order is first paid in full" that changed the order status to "Processing" (as it was strange to look at orders that had been paid in full - for events - as still "Pending").

Seems as though when we skipped the status to Processing a few of the other rules weren't triggering.

Answer by: housser
Posted: Oct 2, 2013
Vote up!
0
Vote down!

Does anybody know how to solve this ? So far I'm having the same issue...

In my case sometimes the new user is created and sometimes not. And sometimes a previous user is assigned to a new order due to same email account input (by the rule: Assign an anonymous order to a pre-existing user) but sometimes not.

I wonder if the developers of Commerce are aware of this long lasting problem...

Answer by: Al
Posted: Jan 20, 2014
Vote up!
0
Vote down!

It's not an actual bug - it has to do with the order in which rules are processed. I get it - but it is NOT the most intuitive thing. While Commerce is a powerful platform, it requires a lot more configuration to be really useful out of the box.

Set the weight of the rules so that things like creating the user account are 'lighter' (lower number) than anything that will update the order status and you should be all set.

Answer by: jpamental
Posted: Feb 3, 2014
Vote up!
0
Vote down!

I am having the same issue. The rule apparently used to fire, as a search among some old test emails show the exact wording (text) that is in the commerce_checkout.rules_defaults.inc file.

However, the rule no longer appears to be firing.
Is there a file where I can set a dpm() call to debug and see if the rule is firing, and then narrow down which of the comparison operations is failing?

Jerome Wiley Segovia
Posted: Apr 12, 2016