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

Many thanks. Unfortunately, that didn't solve it for me, even after remembering to run update.php after module updates. :o( And I updated to latest dev version of ubercart after 3.1 didn't fix.

I did notice that the cloned (and some deleted) rules in rules_config mysql table were still there, referring to now non-existant tax IDs in uc_taxes table. I deleted the obsolete rules records manually with phpmyadmin 3 to tidy up. Did this before your reply, hoping it wwould fix problem (it didn't), so don't know if upgrades you mention would have tidied up for me or not. Maybe you could check your mysql tables/records and reply, for others, so they know if manual tidy-up is necessary on rules_config records, in addition to rules and entityAPI updates. For others reading this, in future, the relevant record names are obvious - puts tax ID on end of field content as underscore then the ID number (e.g."uc_tax_33" in this case, ref's uc_tax_config table with record indexed by tax ID number 33). If there are any other tidy-ups needed that I've missed, pls reply - I couldn't see anything else relevant in the rules table. I don't think these manual deletions would have affected the fix as the records were orphans/widows. ??

I could try to cure symptom by deleting all tax rules and starting again, but is a lot of re-work if this doesn't work, plus would be nice to resolve properly for our fellow drupal users.

Any more thoughts? Are there any screen prints it would be helpful for me to provide?

Best wishes

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'];
}
elseif ($tax = uc_taxes_rate_load($item['data']['tax_id'])) {
// For old orders that don't have all the tax info, all we can do
// is preserve the rate.
$tax = clone $tax;
if (!empty($item['data']['tax_rate'])) {
$tax->rate = $item['data']['tax_rate'];
}
$taxes[] = $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).

p.s. in the code snipped, the actual line causing the error is, of course "$taxes[] = clone $item['data']['tax'];"

replied as 2 and 3 - forgot to hit reply button. Not sure if it notifies you of my comments unless I hit the reply to yours, so hence this msg. :)

UPDATE: 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.

Ah, thanks, didn't realise it was different module. Will copy comments over there when I get a moment, thanks.

Was uc_recurring. I've switched off the module and all is fine. Was a good idea, but in testing, it billed a 75p download test-customer a little over £20,000! (Very profitable for me, but not sure I'd get many customers!) I believe it was due to a clash with OG's global permissions that controls per-field level access. If the UC customer does not have access to any one field in the UC product, UC Recurring sets up a rogue recurring fee (which was not defined as a feature) with a repeat interval of 0, so it repeats as fast as the processor can repeat it. :S Once I re-set the correct access to the OG product field and cancelled the rogue recurring subscriptions, all was fine until I forgot to go and tick the boxes for the next added field when modifying an UC class/content type and tried to buy something with it! Anyway, detail is already in the UC recurring module issues list for others to see and get help from, as per the good old Drupal tradition!

Best wishes