Fatal error: __clone method called on non-object in /<server>/modules/ubercart/uc_taxes/uc_taxes.module on line 400

UPDATE:

I finally got around to downloading a PHP editor so I could find the line numbers!

The error occurs in the section of code:

// For orders no longer in checkout, only the saved tax rates can apply.
elseif (isset($order->order_status) && uc_order_status_data($order->order_status, 'state') != 'in_checkout') {
if (isset($order->line_items)) {
foreach ($order->line_items as $item) {
if ($item['type'] == 'tax') {
if (!empty($item['data']['tax'])) {
// Use the rate stored in the line-item.

$taxes[] = clone $item['data']['tax'];

So, I figured it was related to a reference to a tax rate related to the original bug (which I'd fixed in theory by downloading latest rules and entity api modules). The offending tax rate being referenced in old orders.

I went to my ubercart orders list and found a massive number of recurring payments related to the order. Attachment payments.jpg shows the next recurring fee was order number 686, but attachment 'recurring error.jpg' shows order 685 was in fact the next created recurring fee and that it creates 687 through to order 1711 at which time (just now) I cancelled the recurring payments (see 'cancel error.jpg'). As you will see, on cancelling the rogue recurring payment that had appeared out of nowhere (no recurring fee set on product - it was recurring minute by minute forever), I got another error (notice: undefined index: cancel callback in uc_recurring_invoke() (line 732 of //modules/uc_recurring//uc_recurring.module).

I then went back to the UC orders list to do some of the attached screen shots and when I returned to the user's recurring fees page, the error had gone (a one time only error then?) - see 'cancel error now gone.jpg'.

As to what caused this, I had set up thirty tax rules, all with 'order total' being checked between two amounts (i.e. using condition 'lower than', then an 'AND', then another condition on the AND 'greater than', to add the tax only if the order total was between two values. All other orders seemed to work. Not sure this is related, but only other thing I can think of is I had added a new field to a content type that was associated with an Organic Group, and I had forgotten to go into OG fields permissions to give the OG administrator access to that field. This cause various errors that it took me a bit of diagnosing to track down. All were cleared, but the lack of access to a single field during processing seemed to cause all sorts of my drupal modules a headache. Maybe this inaccessible field in a product caused the UC tax module to trip a recurring fee when it shouldn't have? That's all I can think of for now. I am deleting all the hundreds of orders created by this error and expect the problem to go away when I'm done.

I would recommend some kind of check added to UC to ensure there really is a recurring fee set up on a product before adding thousands of them! :)

Will add more if I find out any thing relevant, but if anyone knows if I can delete orders a bit quicker, in blocks, would appreciate the tip!

Best wishes all

The original order was for a product type that did not have recurring payments set up on it (i.e. features tab had no recurring payments on it and it wasn't a product that would have such recurring fees anyway).

UPDATE 2: A quick way of stopping all the rogue recurring fees is of course to go to admin/store/orders/recurring as admin and click the cancel button for each record with an interval of zero (0).

This also (for the time being) seems to have stopped the error on line 400 as well, although my order history is now full of hundreds of cancelled recurring orders!

They recur because the interval is zero (recur as fast as your PC/MAC/whatever can process orders!

It is zero because the recurring order appeared by error - i.e. it wasn't set up by a person following any kind of rules, so no actual values entered such as non-zero interval value.

I suggest a safety update would be to edit the php to stop a recurring order (reject it) if the interval is zero.

Had another look at the PHP but sadly my php isn't that good yet and I've not found the relevant code. If I do, before someone that knows what they're doing around ubercart php sorts it out, I'll post my attempt at resolving.

I believe the error was caused by the use of OG 7.x-1.x which allows field level access control. Where I had a field that was not accessible to the buyer, UC recurring would set zero interval. Solution was to avoid inaccessible fields in UC class/product. Then you would remove all rogue records. Cancel button worked for me, but you could remove the records from the sql db directly - just be careful of widow/orphan records. Search db for each key field value before deleting, to work out the tables and records to remove.

Hope that helps?

Den33775

P.s. the cancel button doesnt work until you deal with the inaccessible fields in the relevant class/product.

(i.e. the cancel button wont stop the endlessly repeating zero interval orders from being added, it will just cancel that bad record/order. But ensuring all fields are accessible to the buyer does stop the endlessly repeating orders from being generated on new orders. For existing orders you need to cancel the very first order, I think (vaguely remember), then all the rest. Taking the web server offline and doing it in the db is quicker if you know what you're doing, but see advice above on searching for record keys to avoid widow/orphan problems first.