Jump to content

malfunction

Level 2 Member
  • Content count

    265
  • Joined

  • Last visited

  • Days Won

    2

malfunction last won the day on February 22

malfunction had the most liked content!

Community Reputation

47 Excellent

About malfunction

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. 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.
  2. 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....
  3. What, you mean the community thread where the guy from Plesk says "don't do this"?
  4. 😂 You must be new around here...
  5. 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.
  6. 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 😐
  7. 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.
  8. 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%' }, }, });
  9. No conclusion given here, did this ever get written? I could sure use it.
  10. 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.
  11. 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.
  12. malfunction

    Marketplace SSL expirys query

    That's OK in theory, but in practice GeoTrust will issue the renewal certificate for a period that's 1-2 months longer, so after several years the billing date and the expiration date will be six months apart. Which creates angry customers wanting to know why you are billing them in January for a certificate that doesn't expire until July, and consequent support workload. There should be a sync process similar to domain management.
  13. That's funny, mine still says this: Your PHP version 7.0.24 is supported by WHMCS. Your PHP version is actively supported by PHP for both bug fix and security releases. Which of course is not strictly accurate as since PHP 7.2 stable was released right on time a couple of days ago, PHP 7.0 is now in a "critical fix only" mode and is no longer in active support. Hope WHMCS are enjoying their nap. Added: Oh, I see you're the other side of the dateline from me. So I guess my admin panel, together with everyone else's, will throw a similar warning tomorrow when it gets to be December 3 (2 year anniversary of PHP 7.0 release) over here. Perhaps a warning about unsupported PHP versions being displayed to 100% of users will encourage the release of at least PHP .7.1 support in WHMCS.
  14. malfunction

    WHMCS Cron Job Activity Email

    Yes it is, pretty much worthless. If only they had spent the time they used to stuff their logo in there on considering how to actually make the report more useful to users... Instead we have chase around all over the place to find what got suspended, terminated, cancelled, what failed etc. There was frequently actionable information in the old cron report, now it's just fluff.
×

Important Information

By using this site, you agree to our Terms of Use & Guidelines