Jump to content

D9Hosting

Member
  • Content Count

    246
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by D9Hosting

  1. Just to update the thread for anyone else who comes across the same error - I've fixed the issue by disabling Cloudflare on the domain running our WHMCS installation. Neither Gocardless, nor Cloudflare have any idea why Cloudflare would be interfering with the API callbacks but at least things are working again!
  2. Just wondering if anyone else has noticed problems with this module receiving callbacks from Gocardless since August 11th? I noticed a few days ago a strange lack of direct debit payments being received and on checking in our GC account any callback sent to the module is generating the following error: 498 Token expired/invalid I've generated new live tokens and webhook endpoints, re-uploaded all the module files but the issue remains. There is nothing showing up in the WHMCS module log, and in the gateway log all I am seeing are lots of entries saying: Callback verification failed (Invalid Token) : Payment requests and setting up new mandates still work fine, it's just the payment callbacks that aren't working. I've got a ticket open with the creator of the module but so far haven't had a response. I did also open a ticket with GC who said: Anyone got any idea what the issue could be? From our end nothing has changed since it stopped working so it's a bit of a head scratcher and for now we are having to go through and manually cross reference all paid invoices in GC with those in WHMCS and mark them as paid.
  3. We've got one client who is managing to trigger this error every time he orders something yet it looks to be fine for everyone else. The error he is getting is related to the capatcha on the checkout page (using invisible recapatcha) so for now I've just disabled the capatcha for that page.
  4. Add us to the list of users seeing this issue in 8.13. Just had a PO'd client get in touch with us because he "paid" us for an order that we had no record of.
  5. We've seen the same problem sporadically with both Six and a custom template. The "please complete capatcha" message shows for a few seconds and then it disappears and the domain search results show up. I figured it could be due to us using Cloudflare on the domain but gave up trying to fix as it's not a total system breaker and just another WHMCS quirk.
  6. I liked this section from the blog post that mentioned the exciting features they were working on for a future release: More marketplace bloatware to look forward to, but who knows, maybe we are in the vocal minority and most users are requesting this?
  7. Common <> Good For major changes like this you need to ask the users of your software for feedback BEFORE you go ahead and implement yet another "feature" that makes our lives harder.
  8. You're too good for this community, problem solved! Thanks so much for the help, I'll buy you a beer.
  9. I do actually get the "Email Sending Failed - Email message rendered empty - please check the email message Smarty markup syntax" error message, but the line of code it mentions in the logs is any line that has this in it: I like the sounds of the hook idea rather than wasting more time on this, I'll send you a PM.
  10. Hi @brian!, Thanks for the quick reply. Still no luck I'm afraid: $smarty_security_policy = array( 'system' => array( 'enabled_special_smarty_vars' => array( 'session','foreach','section','block','capture','now','get','post','server','request','template','const','cookies', ), ), 'mail' => array( 'php_modifiers' => array( 'strstr', ), ), ); Generates the following error when sending an email : PHP function 'strstr' not allowed by security setting Just going back to what you mentioned last week: This was triggered when I first noticed a security policy error that was being triggered by a custom template using "$smarty.session". To fix this I set a security policy as per the WHMCS docs to allow the session variable. I then noticed a ton more errors when accessing various pages in the admin area relating to WHMCS system variables - server, capture, etc. It was at this point I got in touch with WHMCS and they advised I now needed to add all the variables used by WHMCS to the security policy and not just the variable I wanted to allow. So it looks like as soon as you create a security policy to enable a certain variable using "enabled_special_smarty_vars" anything that was previously being used when there was no security policy in place needs to be specifically added. WHMCS did say they were working on a more "graceful" way to handle this in the future but I wont hold my breath.
  11. Hi Guys, Thanks for the responses. Unfortunately the newly formatted code doesn't work either: $smarty_security_policy = array( 'system' => array( 'enabled_special_smarty_vars' => array( 'session','foreach','section','block','capture','now','get','post','server','request','template','const','strstr','cookies', ), ), 'mail' => array( 'php_modifiers' => array( 'strstr', ), ), ); With the above code the template which uses $smarty.session works fine but the email template containing "strstr" throws up the security policy error as before. If I remove the system security policy leaving just the email policy the emails work fine. I have a ticket open with WHMCS but don't hold out much hope. As a workaround and before I spend a morning editing custom email templates, is there perhaps an alternative I can use to "$smarty.session.cart.promo" in /orderforms/configureproduct.tpl to pull the promo code used (if any) by the client? Figure it will be easier to edit that one file rather than a ton of email templates!
  12. Apologies for bringing an old thread back from the dead but this issue has reared its ugly head again in version 8.13. We had an issue with a smarty variable in a custom template file triggering a security policy error so WHMCS Support suggested adding this security policy to our config file: // Smarty enable special variables policy: $smarty_security_policy = array( 'system' => array( 'enabled_special_smarty_vars' => array( 'session', 'foreach', 'section', 'block', 'capture', 'now', 'get', 'post', 'server', 'request', 'template', 'const', 'strstr', ), ), ); This fixed the issue with the template not working but now we are getting a "'strstr' not allowed by security setting" error when trying to send any email that contains this: {if strstr($client_credit, "GBP")}Blah blah blah{/if} The original security policy we had in place to allow "strstr" is still there but doesn't work if we also have the new "'system'" security policy in place, it works fine if we remove this leaving just the original security policy but ideally we need both the custom template and the code in the email to work! FYI our full security policy is listed here: // Smarty custom email based template policy: $smarty_security_policy = array( 'mail' => array( 'php_functions' => array( 'strstr', ), ), ); // Smarty enable special variables policy: $smarty_security_policy = array( 'system' => array( 'enabled_special_smarty_vars' => array( 'session', 'foreach', 'section', 'block', 'capture', 'now', 'get', 'post', 'server', 'request', 'template', 'const', 'strstr', ), ), ); Any ideas how to fix or if not, is there another workaround we could use to display conditional data depending on the currency used by the client?
  13. My colleague just spent her entire lunch break trying to find where the domain pricing page had gone 😬 It may seem insignificant but the thing I noticed straight away was the lack of the system time at the top of the page as that always comes in useful when checking through the logs and tickets. Thank god for Brian!
  14. Just an update for anyone who has the same issue. We've just updated to WHMCS v8 and the "Add payment method" button is (rightly) no longer shown to the client, so whatever the issue was got fixed in the upgrade. ......now to get used to the new admin area menu where everything seems to take far more clicks than it should to get to where you want to go.
  15. Hi Brian, Thanks for the reply. I think it must be the MyWorks PP module causing the issue as Nifty have said their module wouldn't trigger the pay methods link so I'll migrate away from the PP module and see how it goes. Just to confuse things even further, when I try to add a card from the admin area I get a message saying no active gateways support this, which suggests that none of the active modules should be triggering the pay links feature on the client side so who knows!?
  16. We've come across a potential quirk with the pay methods page and wondered if anyone else is seeing the same thing. After reporting the issue to WHMCS they are blaming the MyWorks PayPal Billing module but I haven't seen any other users reporting the same thing which is a bit strange. To reproduce the error go to Billing > Pay Methods > Add new card > Enter any test card data and submit After doing this we are seeing this error (full error is stripped but you get the picture): Oops! Something went wrong and we couldn't process your request. Please go back to the previous page and try again. Error: Call to a member function getDisplayName() on null in /home/user/public_html/vendor/whmcs/whmcs-foundation/lib/ClientArea/Account/PaymentMethodsController.php:0 Stack trace: **unable to insert anymore as the community software is throwing up an error!** This happens with all clients, new or old, regardless of the default payment method they use. We are running WHMCS v7.10 and the issue is there on the default Six theme and also after removing all custom hooks. The gateways in use are: - Sagepay repeats - Myworks PP billing - Nifty Gocardless - Bank transfer One thing I was curious over is what gateway WHMCS is trying to attach cards to that are added via the Pay Methods page because AFAIK our card module (Sagepay repeats) doesn't allow you to add a new card without an associated invoice/payment (or it didn't prior to pay methods being instroduced) so I wondered if this could be the issue and if the PP module is actually a red herring?
  17. I sent them a ticket 2 or 3 weeks back to ask about the compatibility with the latest WHMCS version and I got a reply back the next day saying it should work fine. Disappointing to hear they have stopped development as it's a much better solution for taking PayPal payments compared to the default WHMCS PayPal module.
  18. Have a look in the hooks folder and get rid of any hooks you aren't using. We saw a similar issue a few weeks back when any invoice action would lead to a time out and it turned out there was an old quickbooks hook trying to connect to a non-responsive API which was causing the timeout.
  19. You could just disable the "Auto CC Processing" option for the client and then set the "Override Auto-Suspend" value accordingly. You'll just need to remember to reactivate the CC processing in a couple of months.
  20. You might have more luck if you use this 3rd party Gocardless module rather than the one shipped with WHMCS: https://in2computing.com/nifty-products/direct-debit-gocardless It allows you to define when an invoice should be marked as "Paid" in WHMCS - either when it is created, submitted, confirmed or paid out. It sounds like the WHMCS module is only trying to mark invoices as paid when they have been "Paid out" in Gocardless. There's also a handy feature that allows you to initiate the direct debit x days before the due date which is very handy as it stops invoices from going overdue.
  21. Thanks for the info. We were one of the early complainers about this new "feature" and are still running v7.6.2 to avoid having it forced upon us. We hadn't come across a way to actually stop the sync from running so this is very useful to know 👍
  22. As far as I am aware this has always been the case, and not something specific to v7.9.
  23. We contacted Gocardless RE supporting the USD currency and they stated that this should be available by mid 2019. We too have customers that are billed in a non-local currency, so I'd be interested to hear what response you get from Gocardless @N8Solutions
  24. Domain name suggestions on the admin home page just to rub our noses in it 😂
  25. Just a quick Monday morning vent.... We've recently upgraded to v7.6 and who suggested it would be a good idea to bring back domain suggestions on the admin area Whois search tool!? All it's done is slowed down the load time of the page whilst it brings back domain suggestions that I can't imagine any WHMCS admin user ever looking at. The Whois tool in the admin area is (was!) used as a quick way to check nameservers, expiry dates and other domain info. It's not used to suggest potential domain names for customers, they can do this in the customer facing domain checker. Can I suggest that when implementing new crud like this, you add the option for us to disable it?
×
×
  • 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