screenshot: http://prntscr.com/45p9m

downloaded latest dev release and did a updb via drush and it seems to be stuck on:

Initialized Drupal site default at sites/default [notice]
Executing uc_credit_update_7000

Comments

longwave’s picture

How many orders do you have in your database? That update may take a long time if you have thousands or more.

Island Usurper’s picture

I think that's the output I'd expect when performing a batch update through drush. It does 100 orders at a time, so even on a small site it could make many lines of output.

Poieo’s picture

I could not get the latest dev release to complete the update cycle either. It spun for over 5 minutes (through the update.php UI) and never completed "7000 - Remove credit card debug mode".

Only have about 50 orders in the system.

patoshi’s picture

i just let it run for a good five minutes this time.. and it just loops. here is the log via drush updb -v:

screenshot: http://prntscr.com/47ogw

longwave’s picture

Status: Active » Postponed (maintainer needs more info)

What version of drush? I just tested on drush 4.4 with two databases, one with under 100 orders and one with over 100 orders, and both completed successfully. I can't reproduce this with the update.php UI either.

Can you try with drush -d updb and upload the output as a text file?

pkchoo’s picture

My issue isn't exactly the same, but it might be related. I'm upgrading to ubercart 7.x-3.x-dev from ubercart 7.x-3.0-rc2 and during the update.php process I receive this error at about the 2nd update (out of 7).

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://mydomain.com/update.php?id=51&op=do StatusText: OK ResponseText: Fatal error: Class 'UbercartEncryption' not found in /home/clients/websites/w_admin/public_html/admin/sites/all/modules/ubercart/payment/uc_credit/uc_credit.module on line 746

I did run the update.php again on the dev site and it showed 5 (6? i forgot now) updates and it did successfully complete it. I'm not comfortable relying on running the update.php again on the production site just in case something is not updated properly.

I also do have the Encryption key path set up, but I am currently not using credit card checkout, only Paypal at the moment. Maybe some of my settings are interfering with this process?

Is there a work around for this?
Am I correct in playing it safe and not running update.php again after receiving the above error? Or is it actually ok to run update.php again on the production site?

Thank you.

longwave’s picture

I think I know why #6 occurred but I don't think it's the same as the previous issues. The UbercartEncryption class was moved since rc2 and Drupal won't be able to find it without clearing cache, which doesn't happen until later in the update process. I think we can commit a workaround for this, though.

Anyway, yes it is safe to run update.php again (but you should always make regular backups of your production sites anyway, just in case), and hopefully it won't occur on the second run. Let us know the results either way.

pkchoo’s picture

@Longwave,

Thank you for your reply! I will go ahead and update it again and will continue with the second update.php after the initial ajax error. On the dev update, the second update.php ran successfully :)

Thanks again!
Joe

seanr’s picture

I ran into the issue in #6 while trying to update via drush. It does not clear cache on a failure, so the solution was just to run drush cc all and then rerun drush updb.

OldAccount’s picture

Had the same error as #6 trying to run update.php on 7.x-3.x-rc3:
Fatal error: Class 'UbercartEncryption' not found in C:\web\sites\all\modules\ubercart\payment\uc_credit\uc_credit.install on line 42

Cleared the cache and it ran successfully without any errors.

tr’s picture

The error means the Drupal class registry contains stale information. Flushing the caches does rebuild the registry, so that's why your solution fixes the error. Running update.php also rebuilds the registry, but not until after the problem occurs. That explains why the second run of update.php doesn't show the error.

This seems to be a core bug, and I would venture to guess there's already an open issue for it somewhere. (EDIT: Indeed there is. For reference, it's #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap).

Regardless, this is way off the original topic. If you would like to discuss "Fatal error: Class 'UbercartEncryption' not found" please open a new issue.

Please keep the rest of this thread about uc_credit_update_7000().

longwave’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

The newer error is being dealt with in #1367538: "Fatal error: Class 'UbercartEncryption' not found" when upgrading to the 7.x-3.0-rc3

Tentatively closing this, if the original loop is still a problem, please provide drush -d output as requested and reopen.

dgtlmoon’s picture

Curiously, just a question about if it's a problem how you're testing for the number of entries to repair

Could it be the way you're testing for 'max' is incorrect?

mysql> SELECT COUNT(order_id) FROM uc_orders WHERE data LIKE '%cc_data%';
+-----------------+
| COUNT(order_id) |
+-----------------+
|            7377 |
+-----------------+
1 row in set (0.01 sec)

mysql> SELECT max(order_id) FROM uc_orders WHERE data LIKE '%cc_data%';
+---------------+
| max(order_id) |
+---------------+
|         13279 |
+---------------+
1 row in set (0.02 sec)

So therefor this test might not capture all the items because progress could be greater than max very easily.

  if ($sandbox['progress'] < $sandbox['max']) {