Jump to content


Senior Member
  • Content count

  • Joined

  • Last visited

  • Days Won


malfunction last won the day on July 20 2019

malfunction had the most liked content!

Community Reputation

7 Neutral

About malfunction

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. malfunction

    WHMCS Security Advisory 2020-01-28

    Completely useless steps provided to determine if you have a problem on IIS; https://www.example.com/path/to/whmcs/vendor/composer/LICENSE isn't going to do anything at all without a file extension or a specific rewrite rule and the "verification tool" just returns a blank white screen and nothing in the php_error_log. None the wiser after that 😐 so just removed authentication from /vendor anyway. Probably be alright I suppose.
  2. malfunction

    SCA compliance vs 7.8 Bugs

    We heard the same and, given that for us the majority of transactions are non-European, we found it easy to make the decision to defer the update and just deal with a few declines as and when they occur. Given the number of apparently quite severe bugs in 7.8.0 7.8.1 7.82 the risk to our business is far less that way. The ability to reliably charge our customers is the most important function of WHMCS and anything that inhibits. that is seriously bad news. We use Stripe with PayPal as a backup. Can't say it was unexpected, this is exactly what you get when you leave the new version until the last minute and don't alpha/beta test properly. Which is the normal routine round here of course 🤬
  3. malfunction

    Stripe Changes

    You keep saying that, but fail to understand that issuing a stable release at 23:59 on September 13th isn't a sane solution for the user base. Even if a stable release shipped five minutes from now it would still be too late. Beta this month means a bug infested GA release end August, followed by a point release early September. That gives us absolutely no time to test anything, no time for the very complex template updates many of us have to do (often involving third party developers out of our control), no time to port other mods/hooks/extensions/whatever, no time to deploy in an organized fashion that protects the absolutely business critical function of collecting money from our clients. We'll just have to throw it out there and hope for the best. WHMCS will all stand around patting themselves on the back and rearranging their superhero capes, having 'beat the deadline', while the long suffering user base gets to pick up the pieces 🤬
  4. There you go then, official confirmation from the Head of Support that WHMCS is awesome and everything is fine. Except that it isn't 😐. The clue is right there where he says "This works best in EasyApache environments.", which translated means that they couldn't care less about non-cPanel environments and make little or no effort to test for them. They say "As yet we've been unable to reproduce on stock CentOS7 repos we set up for testing this". Must have been some pretty thorough testing I'm sure, but it took me all of ten minutes to place the test file that @ju5t kindly provided on a handful of production CentOS & CloudLinux servers (both dedicated and virtualized) and every one produced an empty array. Peversely, it works well on Windows Server, but WHMCS don't support that any more. PHP version 5.6 through 7.3 OS CentOS 7.6 & CloudLinux 7.6 (both dedicated and virtualized instances) OS Version 1810 / Vladimir Lyakhov CURL Version 7.29 because that's the latest version in the CentOS 7 repo, deal with it Output from Test Script Empty array They say "The `mysql_charset =utf8` line is standard on all installations since v5.3 (released in 2013) so most people should have it." OK, screw those guys that don't have it. My primary install is older than that. I supposed we should be pleased that "Case CORE-13267 has been opened to investigate how this error could be negated for installations with an latin1 charset." (like mine) because it looks like they didn't test for that either.
  5. Yes, exactly right, same here. For what its worth I believe Plesk 17.9 will bring an officially supported cURL update to 7.63, but that's still at the preview stage and I wouldn't consider it for production for a couple months at least. So for the moment we're left with the latest version from the CentOS repo which is 7.29 as you know. Of course if WHMCS actually did any meaningful testing before they threw this stuff out there....
  6. What, you mean the community thread where the guy from Plesk says "don't do this"?
  7. 😂 You must be new around here...
  8. But what if we use MarketConnect as a customer facing SSL sales tool but don't actually source the certificates from there because the service is so monumentally awful? Now our customers will get unwanted advertisements for external services we don't want to offer? My bad, I guess I walked right into that one and will have to remove MarketConnect completely now 😐. It was a semi-useful feature in the customer UI, handy sales pages, simple presentation in the cart checkout flow, upsells if desired. Sales did increase and people often chose more expensive certificates than they might have previously. But the rest was unusable, so we reverted to fulfilling manually using the failed module actions page as the trigger to do that.
  9. Exactly this ^^^ A cURL call with verifypeer and display the response isn't exactly a cutting edge feature (although WHMCS still manage to foul it up with inadequate testing), just a thinly disguised attempt to drive more MarketConnect SSL business to them in cases where users are silly enough to use it. Of course if it actually did something useful, like look for SSLs that are present in client accounts and sync the renewal dates like they do for domains, then it would be different. After all, evidently they did name it "SslSync" so the unwitting might even be led to believe that's what it does. But as of now it's just worthless fluff that apparently doesn't work properly, can't readily be switched off and is generally opaque 😐
  10. malfunction

    Unable to get Apple Pay to work

    I'm using a third party cart template and while I was prepared for problems as a result, yes, it worked right out of the box and I was successfully able to make an order and pay from my iPhone. The only fiddly part was the Apple verification file thing, but everything else was just as expected. My checkout is very light with soft gray tones and a big fat black ApplePay button right in the middle might lead folks to conclude that was the only thing available, so I'm going to have a play with the CSS (thanks @brian!) and see if I can get a 'White with Outline' look that's in line with Apple's style guide https://developer.apple.com/design/human-interface-guidelines/apple-pay/buttons-and-marks/buttons/ From the Stripe docs theme: 'dark' | 'light' | 'light-outline', // default: 'dark' I had expected a simple theme switch somewhere to cope with different colored checkouts (WHMCS would have thought of that, right?) but I can hack the CSS if I need to.
  11. malfunction

    Unable to get Apple Pay to work

    The default dark ApplePay button is a rather overpowering and overshadows the other options in our template; how can we change to use the lighter options? elements.create('paymentRequestButton', { paymentRequest: paymentRequest, style: { paymentRequestButton: { type: 'default' | 'donate' | 'buy', // default: 'default' theme: 'dark' | 'light' | 'light-outline', // default: 'dark' height: '64px', // default: '40px', the width is always '100%' }, }, });
  12. No conclusion given here, did this ever get written? I could sure use it.
  13. malfunction

    Trail period for products

    OK, well maybe not always a mistake, but in my experience it's generally better to hide something for a while and see if they will pay, rather than just deleting everything at the first possible opportunity. The latter makes for fed up customers and extra support workload So, just another WHMCS disappointment, I guess. You think you have some useful product trial functionality but when you go to actually implement it you discover that it's just half baked and not properly thought out.
  14. malfunction

    Trail period for products

    from the related feature request: "Once the trial period if the customer does not pay for the service, the account will be suspended." WHMCS response: "I'm pleased to be able to advise this is possible using the Auto Terminate/Fixed Term option under the product Pricing tab." Actually I don't believe this is is possible, SUSPEND being the operative word. Whatever the product is, if the trial customer has spent a bunch of time building/configuring/whatever with his trial product, he's not going to be real impressed if his work gets deleted on termination. Much better to be a bit softer, suspend for a period in the hope he will convert to paid once he sees the product is deactivated, then terminate later if he doesn't. Just trashing it at the first opportunity because he wasn't quick enough to make the first payment is not the way to begin a profitable relationship. Auto deletion of accounts without some sort of grace period is ALWAYS a mistake.

Important Information

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