Jump to content


Senior Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About niels

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We run 7.9.2 as of yesterday. The last duplicates that I've found occured while using 7.9.1 and 7.9.0.
  2. Problem: When using the Sequential Paid Invoice Numbering feature WHMCS will assign an invoicenum (in addition to the id) when an invoice gets paid. It appears that, when WHMCS receives a lot of transactions at the same time, it will happily assign the same invoicenum two, three or more times. This is not a good thing, for obvious reasons. As WHMCS shows id, not invoicenum, in most places it's easy to go unnoticed. If you're not processing a lot of transactions in batches, the occurrence may be very rare too. The database schema does not enforce uniqueness on the invoicenum column and WHMCS doesn't seem to do any double-checking after it inserts the record either. Solution? Any suggestions how to resolve this? I've considered changing the database schema to require invoicenum to be unique. But this might cause WHMCS to simply throw an error. And it's difficult to test what will happen as I can't reliable reproduce the problem. Related: I found this old thread with a similar problem: Which in turn also links to this issue: But neither have a satisfactory resolution. For all intents and purposes the feature is currently not usable and may get those that are not aware of the issue in trouble with their accountant or worse.
  3. Did you find any solution? Do you have this with all customers? We're having the same issue, but only for some customers. There's no discernible difference between the customers that fail and those that succeed. (No old tokens or payment methods, no theme changes, etc.)
  4. Update: Assuming captureCCPayment(122085) points to an invoice number, I had a look at the relevant client: This client had no credit card stored. (My idea was to delete any cards, if present.) This client did have an additional contact. Deleting this additional contact fixed the issue.
  5. Since updating to 7.8.0 and 7.8.1 the daily CRON crashes due to a failure while processing credit card payments. Credit card payments do work normally on the website. Also, some recurring payments do get processed before the CRON crashes. [WHMCS Application] ERROR: Error: Call to undefined method InvalidArgumentException::getJsonBody() in /home/www/x/modules/gateways/stripe.php:0 Stack trace: #0 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Module/AbstractModule.php(0): stripe_capture(Array) #1 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Module/Gateway.php(0): WHMCS\Module\AbstractModule->call('capture', Array) #2 /home/www/x/includes/ccfunctions.php(0): WHMCS\Module\Gateway->call('capture', Array) #3 /home/www/x/includes/ccfunctions.php(0): captureCCPayment(122085) #4 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Task/ProcessCreditCardPayments.php(0): ccProcessing(Object(WHMCS\Cron\Task\ProcessCreditCardPayments)) #5 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Cron\Task\ProcessCreditCardPayments->__invoke() #6 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Scheduling\Ta sk\AbstractTask->execute() #7 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Scheduling\Task\AbstractTask->run() #8 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->executeCollection(Object(WHMCS\Scheduling\Task\Collection)) #9 /home/www/x/vendor/symfony/console/Command/Command.php(259): WHMCS\Cron\Console\Command\AbstractCronCommand->execute(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #10 /home/www/x/vendor/symfony/console/Application.php(844): Symfony\Component\Console\Command\Command->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #11 /home/www/x/vendor/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(WHMCS\Cron\Console\Command\AllCommand), Obj ect(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #12 /home/www/x/vendor/symfony/console/Application.php(123): Symfony\Component\Console\Application->doRun(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #13 /home/www/x/crons/cron.php(0): Symfony\Component\Console\Application->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #14 {main} {"exception":"[object] (Error(code: 0): Call to undefined method InvalidArgumentException::getJsonBody() at /home/www/x/modules/gateways/stripe.php:0)"} [] <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Oops!</title> <style> body { margin: 30px 40px; background-color: #f6f6f6; } .error-container { padding: 50px 40px; font-family: "Helvetica Neue",Helvetica,Arial,sans-serif; font-size: 14px; } h1 { margin: 0; font-size: 48px; font-weight: 400; } h2 { margin: 0; font-size: 26px; font-weight: 300; } a { color: #336699; } p.back-to-home { margin-top: 30px; } p.debug{ padding: 20px 0; font-family: "Courier New", Courier, monospace, serif; font-size: 14px; } .info { border: solid 1px #999; padding: 5px; background-color: #d9edf7; } </style> </head> <body> <div class="error-container"> <h1>Oops!</h1> <h2>Something went wrong and we couldn't process your request.</h2> <p>Please go back to the previous page and try again.</p> </div> </body> </html> This particular issue aside, I don't think the entire CRON should crash just because a single sub-task fails.
  6. The new Stripe method posts to index.php instead of creditcard.php. Sounds unimportant, but I know some of us override index.php to redirect to Wordpress or elsewhere. Even if you don't do that, the Stripe changes to the templates are pretty extensive too. I wish WHMCS had released these changes as a new Stripe module and a new theme so we could switch at our own pace. (As a non-EU merchant with virtually no EU customers Stripe does not enforce these changes for our account anyway.)
  7. That's unfortunate. Thank you for confirming - I'll proceed with a re-query in the hook.
  8. I have a provisioning module where, in the CreateAccount function, I override the username: This works completely fine by itself. I'm now trying to use the AfterModuleCreate hook to run some additional code without having to change the provisioning module. The hook is called and runs its code as I expect. However, the username parameter passed to AfterModuleCreate is not the one assigned by CreateAccount. All the other parameters come through fine. (But those parameters are not changed by CreateAccount.) I'm guessing that whatever function is calling AfterModuleCreate is not re-querying the database after calling CreateAccount, hence not picking up on any changes that CreateAccount made to the database and passing AfterModuleCreate old parameters as a result. Is my assumption correct? Or am I overlooking something? The quicky-and-dirty fix is to query the database in my AfterModuleCreate hook and fetch the updated username. But I would like to avoid such trickery if possible.
  9. Answering my own question: A client cannot place an order using their own affiliate ID. Makes sense, I suppose. Silently ignoring this is confusing though. An error from addOrder would be preferable, or at least a mention in the documentation for addOrder. To make matters more confusing: I noticed addOrder will accept and assign non-existent affiliate ID's. (The affiliate will show as empty in WHMCS and the Manual Assign button will not show.) This means I should check the existence of an affiliate ID before using it, but there's no convenient API call to do so. GetAffiliates does not accept an affid variable and retrieving all affiliates is rather excessive (10.000+ in our database). Will file a bug report for this one.
  10. I'm using the API to create orders. This works fine so far: clientid, pid, billingcycle, promocode and paymentmethod are all used as expected. The affid however seems to be ignored. For example: $this->post("addorder", "json", array( "clientid" => 1, "pid" => 1, "affid" => 1, "paymentmethod" => 'paypal' )); This creates an order for user 1, product 1, using PayPal. But it does not assign affiliate 1 to the order. (Affiliate 1 is a properly activated affiliate. I can use the Manual Assign feature after to assign the affiliate after the order is created.) Is this a bug? Or am I missing something? Is anyone using this successfully?
  11. The CRON process e-mails all messages outputted by CRON jobs to notify the administrator of possible errors. Your "hack" suppresses this very important feature. If the WHMCS cron.php experiences an error and fails to e-mail me about it, I will never know about it when I use your suggestion. I hope you will reconsider this for a future version. The unwritten but well-known rule is that a cron job runs quietly, and outputs only when it needs to notify the administrator.
  12. Upgraded to WHMCS 7 and still experiencing this issue. Can someone open a ticket from within WHMCS and check if markdown works? I'm having this on two entirely separate installs.
  13. After upgrading to WHMCS 7 I increased the CRON frequency to 5 minutes as suggested by the Upgrade Instructions. I now receive this e-mail every 5 minutes: I thought maybe I was somehow running an old copy of cron.php, but opening it shows the correct 7.0 version: All other files in the crons folder also have the 7.0 header. Did I overlook something? Or are these e-mails every 5 minutes expected?
  14. Hi guys, I'm having some issues using Markdown in support tickets. What works well: * Using Markdown in ticket replies. What doesn't work: * Using Markdown in the first message of a ticket opened by an admin from within WHMCS. It appears that the first message of an admin-initiated ticket is always sent out as plain-text. Anyone else experience this? Thanks!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated