Jump to content

ju5t

Members
  • Content count

    35
  • Joined

  • Last visited

  • Days Won

    2

ju5t last won the day on March 14

ju5t had the most liked content!

Community Reputation

7 Neutral

About ju5t

  • Rank
    Member

Recent Profile Visitors

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

  1. It is and isn't. As it can have pretty devastating side effects. If the cron isn't working and a customer with ~100 domains opens his/her domain overview, WHMCS will silently launch a DDOS on your server. Most likely consuming all database connections while it runs. A version check isn't sufficient. You need to run an actual check to test this. 7.19.1 was the first version of cURL to include CURLINFO_CERTINFO, yet 7.29 on CentOS doesn't include it. If this is really true your testing processes fail and you need to get people on board who have even the most basic sysadmin skills. To put things to the test I have started a new VM with CentOS 7. Its versions are: 5.4 -- yes, that's the default on CentOS 7. CentOS 7.6.1810 cURL 7.29.0 Output below: # php -q test.php ... Array ( ) An empty array indicates that the CURLINFO_CERTINFO isn't installed. If you want to have a reproducible test, use Docker. I wrote you a simple bash script that will install PHP and runs the test script. If you have Docker running on any machine, this will launch a bare CentOS 7 container, installs PHP and runs the test script all in one go. docker run -it --rm centos:7 bash -c 'curl https://gist.githubusercontent.com/ju5t/e84f7ca83d3e0adc97134ca05ec1c4ca/raw/b9db6a14c5e1055ac97cb0d8b8393c5414375813/whmcs-test-ssl.sh | bash' @WHMCS John it is disappointing how WHMCS handles this. I don't understand why you come up with arguments illustrating that you've done a good job. You really haven't. As I said before, it's time to be honest and open in your communication. But more importantly: start listening to your customers!
  2. The cron only updates 100 domains at a time. If a domain wasn't updated by the cron, it should be updated when you look at the list of domains as a customer or when you open it in the admin area. If that doesn't help there may cached results that you want to get rid off. Results are stored in the `tblsslstatus` table. You can empty it to clear the cache. This is all I know, I hope it helps.
  3. @WHMCS John your reply illustrates the biggest problem of WHMCS. You can't communicate. Not to your customers and not to each other. There hasn't been a single request on requests.whmcs.com asking for this feature, yet it is implemented. This has obviously been fuelled by your MarketPlace partners, not by your customers. And to be fair I wouldn't mind if a feature is useful and works, but you have to be open about it. You're not. And if it breaks, step up and get it fixed. Stop hiding behind arguments that you're not a system administrator. This is a developer at fault, 100%. You're only telling part of the story. You're not helping, at all. I can understand why your customers are getting more and more frustrated. It checks for a 51 error; It tries to get the SSL details for which it needs CURLINFO_CERTINFO. Even if cURL is working on the CLI, your PHP implementation can still fail. But that's not all. If you have a version of cURL on your server that supports CURLINFO_CERTINFO the cron doesn't necessarily work, simply because WHMCS needs a different database collation; which isn't part of a database migration nor of your release notes or documented requirements. WHMCS has been informed about the CURLINFO_CERTINFO problem AND have been given a workaround by at least two of your customers. It has already been reported as a bug. The fact that you keep saying that the 51 error code is what WHMCS is looking for shows that you're not communicating with each other. If you would, the troubleshooting page would have been updated with both the CURLINFO_CERTINFO information and the changed collation requirements would have been communicated, too. Neither is the case. On to solving the actual problem for those who read this too. Copy the following into a PHP file on your server. <?php $domain = 'www.whmcs.com'; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'https://' . $domain); curl_setopt($ch, CURLOPT_CERTINFO, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_NOBODY, 1); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); curl_setopt($ch, CURLOPT_TIMEOUT, 10); curl_setopt($ch, CURLOPT_VERBOSE, true); if(curl_exec($ch) === false){ echo 'Curl error: ' . curl_error($ch); } $certInfo = curl_getinfo($ch, CURLINFO_CERTINFO); print_r($certInfo); ?> If you open it in your browser. The first line should start with: Array ( [0] => Array ( [Subject] => CN = *.whmcs.com [Issuer] => C = US, O = DigiCert Inc, OU = www.digicert.com If it doesn't your version of cURL doesn't come with CURLINFO_CERTINFO. You either need to update cURL or speak to WHMCS to implement an alternative (and keep your fingers crossed). If you need to update cURL tread carefully. Don't use third party repositories, either speak to a sysadmin or to support of the control panel you're using. If it does, try to run the cron manually: php -q crons/cron.php do --SslSync -vvv Are you seeing errors? They will probably be something like: SQLSTATE[42000]: Syntax error or access violation: 1253 COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1' (SQL: select `userid`, `domain` from `tblhosting` left join `tblsslstatus` on concat("" COLLATE utf8_unicode_ci, tblhosting.domain) = `tblsslstatus`.`domain_name` where `domain` != and `tblsslstatus`.`id` is null limit 100) This is because WHMCS made a breaking change. The solution is to add the following to your configuration.php: $mysql_charset = 'utf8'; Be careful as this may break your currency character(s). Head over to Setup >> Payments >> Currencies and save each and every currency you use. Double check if everything works by looking at transactions, invoices. Don't forget the PDFs. Was this so hard to document, WHMCS? Stop hiding. Start listening.
  4. ju5t

    SSL Monitoring does not work.

    It turns out you have to set $mysql_charset in your configuration.php. $mysql_charset = 'utf8'; We had to update our currency prefixes too. € was suddenly displayed as €. You can't use htmlentities such as &euro; in your prefix, as the PDFs generated by WHMCS can't handle it. We got that solved replacing the incorrect value in the database for € or £ via Setup > Payments > Currencies. All we have to figure out now is how to get rid of the ugly hardcoded images WHMCS returns in its AJAX-calls for SSL checks.
  5. ju5t

    SSL Monitoring does not work.

    As per WHMCS' recommendations on https://docs.whmcs.com/Database_Collations we have switched to utf8mb4_unicode_ci. We couldn't at first, as our accounting software depends on longer keys and they were not supported with utf8mb4_unicode_ci on MariaDB 10.1. I've upgraded our test server to 10.2, switched to utf8mb4_unicode_ci, but as (probably) expected--this didn't work. I have recreated the database, reimported data, converted data, all to no avail. It simply doesn't work. Against their own recommendation, WHMCS uses utf8_unicode_ci. SQLSTATE[42000]: Syntax error or access violation: 1253 COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1' (SQL: select `userid`, `domain` from `tblhosting` left join `tblsslstatus` on concat("" COLLATE utf8_unicode_ci, tblhosting.domain) = `tblsslstatus`.`domain_name` where `domain` != and `tblsslstatus`.`id` is null limit 100) This query is also incorrect--it's missing the value after '`domain` !='. This query runs fine by the way when you add an empty string '' to the '`domain` !=' comparison. So, I spent a lot of hours on a feature nobody requested nor needs, that doesn't work. WHMCS is lost, too. Has anyone here got a suggestion that I may have missed?
  6. ju5t

    SSL Monitoring does not work.

    @agarzon, did you ever manage to solve the collation issues? We're having the similar problems, although the error is slightly different. Syntax error or access violation: 1253 COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1' We're using utf8_unicode_ci, which should be sufficient. This only happens in the cron, live updates are working as expected (although return the not so great looking hardcoded image..)
  7. I wasn't aware of this thread but I have asked WHMCS for the exact same solution. We were lucky as we're using DirectAdmin as it can update curl for you. However, we're still running into all sorts of issues. The cron fails silently with collation errors--even though the collation seems to be set right. The ssl check essentially runs a DDoS on your server when the above happens when your customers have 100+ domains. The ssl check is an AJAX-call which returns a hardcoded link to an image. Good luck if you have a custom theme. @WHMCS John, I think you should be much more open in your decision making process, requests.whmcs.com is a wasteland and so far every major release has included a 'feature' that includes new banners in the admin area. I am 100% willing to increase our monthly subscription fee if you would start to listen to your customers, improve your changelogs and documentation, and stopped shipping new features that have not been tested properly.
  8. I've worked with WHMCS long enough to understand the perks of it. For people it's good to have a mind of their own, for systems, not really. WHMCS does things that it shouldn't do. I'm definitely trying to be an optimist here but a realist probably wouldn't bother discussing this at all. Which solution do you mean? Our current integration or overriding the Invoice-model? Your billing extension is 1000% more extensive than what I was suggesting. You can see the work that has been put into it. In essence I want to store invoices elsewhere. I can only assume that each invoice uses the \WHMCS\Billing\Invoice model. This model would have a few methods to initiate a new invoice, save and change it. Of course in reality it will be much more than that. Instead of storing the final result in the database it would be stored elsewhere -- if you could override it completely, that is.
  9. @brian! not sure if you are offended by what I wrote but if you are I'm sorry, it wasn't my intention. In fact I complimented you on how you've helped others. You could consider me a community newbie (point taken about this topic being in the wrong section), but WHMCS definitely isn't. You can't guess that though, I understand. Anyway, I guess you aren't very enthusiastic about my suggestion as you didn't comment on it at all, but that is exactly the kind of feedback I was after. I have no problem with 'hey that is a stupid suggestion'. In that case we'll live with the facts and that's it. If not, I'll take the time to gather what people wrote and put it in a feature request. Even if WHMCS doesn't do anything with it, it doesn't hurt to try. Fair enough, again, definitely not my intention but it's up to you.
  10. @brian! I know the pace at which WHMCS picks up feature requests. And I've seen you saying it to lots of people before too. I know you're trying to help (and frankly, I've seen awesome suggestions from you before) but in this case I'm not after 'hey WHMCS is pretty * when it comes to feature requests'. I just thought about something that could help us as a company and before I even bother to open a request, I thought I'd try it from a different angle and ask some people here first. @egrueda that's what we do at the moment, or similar at least. And you're 100% right that it's quick and easy. It has a few downsides. For example, you have to keep track of which invoice in your accounts belongs to an invoice in WHMCS. You could solve this by setting the `invoicenum` field in the database with the invoice id generated by your accounting software I guess but you would all sorts of hooks to make it clean (e.g. change it before the email goes out, etc.). As you often can't use the original invoice `id` in your accounting software, at least not in the EU as it's not allowed, you don't have much options. WHMCS makes changes to invoices at unexpected times. This feature would allow give you the opportunity to stop that, e.g. block `save()`-commands on existing invoices. Accounting software can process MT940 files. WHMCS can't. This means the old fashioned bank transfer has to be done twice. If you read the invoices from your accounting software in WHMCS, that problem is gone too. WHMCS isn't really ahead of the rest when it comes to invoices and accounting. And I completely understand that it's what they do. That's what accounting software is for. But if I want to send a UBL invoice, I can't. It's often the small things that are useful and WHMCS doesn't have them (and probably shouldn't write it either). Overall it helps to have a single source of truth. There are definitely downsides of using an API-based invoice model too. Downtime of the API being the biggest one. This is also why hooks aren't the best solution. If the API call fails you've lost that invoice. This is one of the reasons for https://requests.whmcs.com/topic/extend-the-module-queue-to-hooks-and-add-ons (and yea, it doesn't get much traction). The other you pointed out already, updates. Although I don't see much difference in writing hooks and all sorts of calls that depend on the internal structure of WHMCS and writing your own model, but you do have a point. And if not that its complexity would take some interest away.
  11. And replies like this kill discussions before they even start. Thanks.
  12. How long it takes for WHMCS to implement feature requests is besides the point. It's impossible for a developer to write this without the ability to override WHMCS\Billing\Invoice. Extending this class is not enough. We could throw development time at it but it would never integrate as neatly as I'm proposing.
  13. Everyone knows that WHMCS isn't meant to be or to replace your accounting software. There is no place for purchase orders, ledgers and other important aspects of accounting in WHMCS. Just to be sure, I'm not asking for it either. But I was thinking, would it be useful if WHMCS stores some data outside the WHMCS database? Invoices for example. If we could store invoices elsewhere and use that as the source of truth that would be helpful for some companies. I still want customers to manage and pay their invoices online from within WHMCS, it would just get its invoice data from somewhere else. You could make your own invoice page instead but that could affect automation settings or potentially stop from working and I don't want that. From a technical point of view we would like to override the WHMCS\Billing\Invoice class and implement the relevant methods for each action (e.g. ::find(100) should search the API of your accounting software instead of the database). A list of the methods it calls throughout WHMCS would help. If you decide to override WHMCS\Billing\Invoice and have other modules that depend on tblinvoices those other modules would be incompatible. I see the risk in that but if you don't override it everything would stay as it is. Before I raise a feature request I was hoping to get some feedback here so I can make the request as detailed as possible.
  14. ju5t

    Backups

    Ah right, sorry, I can see why this wasn't obvious from my initial post. We're offering R1soft at the moment. Every so often though we run into problems. This can be anything really. When it works it's great though I think it's always good to look out for alternatives. In the meantime I've had a look at Acronis but their minimum commitment is above our budget unfortunately.
  15. ju5t

    Backups

    Out of curiosity, what are most of you using to run your backups that integrates nicely into WHMCS?
×

Important Information

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