Signups not created - UC_Signup weight should be -1 with some payment methods

"the purchaser may or may not show up on the signup tab for that node (It seems to work about 60% of the time)."

Finding the problem here will probably involve isolating the change that makes things work sometimes but not others.

What payment method(s) are you using? You might see if there's a connection between payment method and signups created.

Another thing to check is whether there are any items in uc_signup_log that are temporary (type = 0).

I just came across this same issue. The problem is with the uc_signup_mark_paid CA predicate and function order in modules implementing hook_order at the "submit" stage, including uc_signup. uc_signup_order assumes it runs at submit time before payment modules attempt to process the order, but since they run at the same time and have the same default weight, it's a crapshoot which one goes first. If the payment module goes first and successfully accepts payment, it runs the CA predicate, which then unsets the signup information before uc_signup_order gets a chance to add the signups and create new users.

The real issue here is that hook_order needs a presave stage. Lacking that, here's a patch putting an update hook in uc_signup.install that sets the module weight to -1. That hopefully won't be too controversial.

This was largely crippling the module, so marking this critical.

Thanks very much for the debugging you've done here.

I'd like to do (and have others do) some testing of this patch before we commit it, and consider how the change in weight could affect the relationship between uc_signup and signup.module.

I hope to test soon. Thanks!

Whoops, looks like someone else (Mattamatic) figured it out a couple months ago in a different thread: #722954: Invalid argument foreach(), line 595 and 630

Interesting. At least one user reported that changing uc_signup's weight to -1 didn't resolve the issue, however that's not definitive either way ;).

Yeah, I saw that in the other thread, but wasn't sure what to make of it. It sort of looks like she got it figured out.

I'll be trying out the patched version for a site-in-progress, so I'll be on the lookout for problems.

Is there any negative effects of using PayPal website payments standard in the 'Sandbox' environment in relation to signups not displaying in the uc_signup. (I have currently set the weight to -1 for the uc_signup in the system table.)

If I choose to pay with check or COD then the signup gets captured properly.

Thank you

ezra-g: Instead of changing the module weights, what about re-implementing the current code in uc_signup_order() as an additional submit callback for uc_cart_checkout_review_form()? We could easily accomplish that with form_alters, and it would give us some control over when the code executes without the uncertainty of messing around with weights.

That's a good idea but wouldn't work for payment methods that send the user off-site, like paypal wps.

This is committed. Thanks, @lesmana for the troubleshooting and patch, and I apologize for the delay in reviewing/committing!

@otisjs01, I'm not sure that the problem you are describing is specific to the module weight and in fact I've seen it happen before this patch was applied. Please see #839640: Provide Better signup locking for more on addressing that problem.

Thanks!

One little glitch: the module weight is not set to -1 when installing the module from scratch. (At least it didn't in my case, and I'm on beta5 which includes update 6000.)

Can the update to the {system} table happen during an install hook? I've attached a patch to show what I mean, and I'll test later, but if anyone knows the right way to do this, then please disregard my patch.

Jeff

According to this page: http://drupal.org/node/110238, the call to set the module's weight can be made during hook_install(), and should look like this patch.

Jeff

Looks good and works in my testing.

Thanks for the patch!

Committed: http://drupal.org/cvs?commit=422312