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
Comment #1
longwaveHow many orders do you have in your database? That update may take a long time if you have thousands or more.
Comment #2
Island Usurper commentedI 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.
Comment #3
Poieo commentedI 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.
Comment #4
patoshi commentedi 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
Comment #5
longwaveWhat 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 updband upload the output as a text file?Comment #6
pkchoo commentedMy 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).
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.
Comment #7
longwaveI 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.
Comment #8
pkchoo commented@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
Comment #9
seanrI 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.
Comment #10
OldAccount commentedHad 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 42Cleared the cache and it ran successfully without any errors.
Comment #11
tr commentedThe 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().
Comment #12
longwaveThe 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 -doutput as requested and reopen.Comment #13
dgtlmoon commentedCuriously, 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?
So therefor this test might not capture all the items because progress could be greater than max very easily.