Jump to content

niels

Member
  • Content Count

    143
  • 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. When I create a child theme, consisting only of theme.yaml and no other files, the Stripe gateway settings complain that Required Template Changes are Not Found. My theme.yaml contains only this for now: name: "My Website" author: "Me" config: parent: twenty-one Of course I want to make more changes to my theme than just create a theme.yaml, but it's unclear why Stripe breaks at this point already or how I should fix it. It is my understanding that WHMCS will look at the parent theme for all files not present in the child theme. And when I play with the theme itself, it does indeed work that way. But the Stripe settings don't seem to pick up on this? EDIT: the cart theme is standard_cart, unmodified.
  2. Looks like their website is back. And my paypal billing module works again. Worrying that the module de-activates so quickly though. I assumed there would a longer period where it retries to contact their website before invalidating the license.
  3. MyWorks' various websites seem to be down and their paypal billing module is failing for me as it cannot verify the license. Are they gone for good? or am I just unlucky to run into this during a temporary outage?
  4. Did you (or anyone else reading this) ever figure out how to do this? WHMCS continues to create renewal invoices, even with the "skip --CreateInvoices" parameters. In my crontab: */5 * * * * php7.3 -q /home/www/myanuson/crons/cron.php skip --CreateInvoices
  5. 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.
  6. 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.
  7. 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.)
  8. 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.
  9. 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.
  10. 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.)
  11. That's unfortunate. Thank you for confirming - I'll proceed with a re-query in the hook.
  12. 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.
  13. 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.
  14. 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?
  15. 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.
×
×
  • 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