Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by ju5t

  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. 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. 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. @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. 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.
  9. 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.
  10. @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.
  11. @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.
  12. And replies like this kill discussions before they even start. Thanks.
  13. 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.
  14. ju5t


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


    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.
  16. I'm confused. WHMCS has successfully implemented GDPR in time before the deadline but it still makes illegal changes to invoices after they have gone out to a customer. In 7.5 they have added another feature that does this. The domain redemption feature makes sense in a lot of ways. It should never remove the domain from an invoice when it expired though. I always get the idea that such features aren't given enough thought. This is the second time in under 6 months that a new feature causes problems. I'm really disappointed by this. It would be great if WHMCS would keep EU laws and regulations in mind when developing new features. For example, this means you can never, ever change an invoice after it has been sent.
  17. WHMCS does a decent job when it comes to VIES and MOSS. I think WHMCS' invoice changes have an impact on all companies no matter where they're from. I've illustrated that in my previous post. Companies in the EU will probably be affected more than others. I'm not asking them to implement a feature that's 'more or less the same in all countries', I'm asking them to add a feature that can stop automated changes. It's very specific. I'm not even talking about invoice changes you can make by hand. I don't expect them to create solutions for all rules and regulations local lawmakers find necessary, that would make the scope too large. It's a small change that solves a big problem for companies in the EU but also has its use for other companies around the world. And to be fair, Europe is quite a large portion of the world. It wouldn't hurt to follow some regulations here and there.
  18. Before this explodes into a discussion about when VAT is and isn't due; that's not the point I am trying to make. It's about whether or not WHMCS should change invoices automatically. I believe there are reasons not to do this no matter the country or continent you're from. Most changes are based on the assumption that customers always pay online. As much as I would like this, many of our customers still pay via bank transfer. If you send an email (even it's a proforma invoice) with the amount the customer is due and decide not to notify the customer of an automated change, customers will pay the wrong amount. I believe this can also happen when you e-mail PayPal links in your email. At the moment, customers are not informed and invoices are changed. This isn't a great experience for both ourselves as our customers. I think it makes more sense to create a new invoice for the additional fee(s), link it to the domain in case of the grace/redemption feature and inform the customer as it happens. If you process a bank transfer and the domain is not renewed because extra fees are due, let the customer know. I think that this benefits everyone, companies in the US, India and Europe but more importantly, the customer. I know WHMCS doesn't have a great track record and the general feeling is that most feature requests never see the light of day. For me that's not enough reason not to start a discussion. The more people talk about it, the more attention it may get from WHMCS.
  19. Don't get me wrong, I don't want WHMCS to replace our accounting software at all. And I don't want them to focus on the EU alone either. In essence all I'm looking for is a way to stop WHMCS from changing invoices automatically. The current grace/redemption feature is a great example of how this can go wrong. It will always change the original invoice, no matter if you choose to add the fees to an existing invoice or if you prefer a new invoice instead. Even when you go for a new invoice it removes the domain from the original invoice which is very confusing for us, but more importantly to the customer. I suggested to add a third option that complies with EU law -- and keeps the original functionality intact. We've been using WHMCS since 2010 after having used ModernBill in the years before that. We have been able to work around some of the quirks in the past. I don't think it is up to us to create work arounds for problems affecting so many others.
  20. Sorry, I misinterpreted your reference to proforma invoices in the sentence "It will be official only if it will be paid by the client" and thought you meant normal invoices -- but you are right. Our partial workaround is to export all invoices to our accounting software as soon as they are created. As our accounting software doesn't allow any changes so we've got most things covered. WHMCS can still change the invoices it has issued in its own system but at least we have some reference to fall back on. Customers can still pay too much or too little when WHMCS makes a change (e.g. when they pay via bank transfer based on an email they received while WHMCS has changed the invoice in the meantime) and that's taking up a lot of time lately. Unfortunately, even though this is on WHMCS' radar, nothing happens and we don't have much else we can do at this point.
  21. Wow, your font doesn't come out great on my screen. It's not easy on the eyes. VAT is chargeable at the moment the service is supplied, not when an invoice is paid. This is the case for every European country. I've referenced this article in a previous post but perhaps you've missed it: https://ec.europa.eu/taxation_customs/business/vat/eu-vat-rules-topic/chargeable-event-chargeability_en. A proforma invoice and not paying tax while you're providing a service is, unlike what you state in your post, not legal. You've provided a service that you should get paid for and therefore VAT is due. The current system of changing a proforma invoice into a fiscal document upon payment is not how it is dictated by European law. Even if proforma invoices were the solution (for the record: they're definitely not), they're not common or used at all by B2C or B2B service providers in The Netherlands and would be confusing for most customers. For some it's easy to say that you should teach your customers differently but that's not how we approach or deal with them. We're here to make it easier. The problem is the fact that WHMCS makes changes to invoices at its sole discretion. If a customer cancels a product on an unpaid invoice, this product is removed from the invoice, and that's not allowed. There are other cases too where WHMCS removes items from an invoice, resulting in customers either paying too little or too much. You could argue that proforma invoices can be used as a workaround but that would only be true if you haven't supplied the service yet. This essentially means you would have to suspend all services on the day the service is due for renewal. It's not the most customer friendly solution of all.
  22. Hi @WHMCS John, thanks for your reply but from where I'm sitting this is not quality service. Nobody answered between 7AM UTC and 10AM UTC. This is pretty much our morning gone as we're in the CET timezone. We were unable to raise any tickets as your systems were offline. When we finally could raise a ticket we received a standard reply to acknowledge the problem and the promise that we would be updated once the issue was resolved. This didn't happen. When we asked for an update it took your team 5 hours to respond with a standard text that gets copied and pasted to everyone. The last 2 replies were quick but don't answer my concerns about not wanting to write a public post mortem. I appreciate the fact that you believe support has been improved over the last 6 years and although I don't see this myself and my experiences are flakey at best, that's not the point here. I think your communication has been far from great during this major problem. Not wanting to write a public post mortem like other companies do feels to me as if you want to hide the issue under the carpet to avoid bad publicity. I don't see public post mortems that way, I see them as an invaluable tool to talk to your customers, say sorry and explain how you're going to do better in the future. Again, everyone understands that IT breaks, we've all been through it, but you have to communicate and that's not what you did, at least at the level I expect from a company your size.
  23. Your team didn't respond very fast to be honest. It took hours for them to acknowledge that there was a problem. There has been very limited communication and so far I have been denied an official reason for outage including steps on how you plan to prevent this in the future. Your team is downplaying the problem by using words as 'reduced availability' and 'degradation' for a major problem which I can't really appreciate. Your team also claims that service was restored at 12:30 UTC. We were still experiencing issues at 14:30 UTC. We already had a ticket open about the issue and it took 5 hours to respond with a standard answer. We're all working in IT so we know that things can go wrong. When it does, you need to solve the issue and communicate. You didn't, and still don't, communicate very well. My biggest problem is the fact that you were entirely off the grid when the problem occurred and didn't communicate out in the open when the issue was found. The communication of WHMCS has been very, very poor to say the least and the fact that your team denies to give a proper public explanation feels wrong. Sorry, I'm not impressed.
  24. In this case though, WHMCS is changing an invoice after it has been sent. If you take this to your comparison; it's a self-driving car that forces you to drive 170km/h, and although I doubt there are case laws about this yet, I assume the car manufacturer would be the one to change this (if you can't, and in the case of WHMCS, you have no choice). And I know you can change invoice records one way or another, that's besides the point, WHMCS shouldn't do it by itself. This isn't a binary discussion, it's not a case of true or false, I was merely making a suggestion which you seem to be taking as an offence. If that's the case I'm sorry, but that wasn't my intention. I don't agree. I'm giving feedback on a process that I think should be changed. You have solved it by changing your business process to proforma invoices which is great, as it helps your company, but we have another opinion. You don't seem to see this as feedback but as an attack on WHMCS (or yourself), it isn't. I just want a solution for a problem we've had in the last 8 years. Until now we've been able to work around it by developing custom add-ons that prevent certain situations from happening, but WHMCS keeps on adding features that are able to change invoices automatically. I don't think this is right as EU legislation is very clear about this. As I pointed out before: the change is only illegal if there is no reliable audit trail. Our accounting software doesn't allow you to change invoices. If you do want to make a change it forces you to do so in a way that creates an audit trail. Of course there are always ways around it but as I started this reply, that's not the point. We're not the only ones. It was raised over 4 years ago already: https://requests.whmcs.com/topic/prevent-invoices-from-being-changed. If you or anyone else has any EU laws or case laws that I'm not familiar with please share them, as again, this is feedback, it's not an attack. I'm more than happy to change my feedback if it turns out my understanding of EU legislation has been wrong.
  25. I'm not entirely sure what you're after. My question is not about how to run your business it's about WHMCS offering an option that hasn't been properly implemented. You seem to be looking for answers on how we decide to run our business and you're hinting that we should change that, but that's not what we want. Regardless of how you run your business, WHMCS allows you to make changes to invoices (in your case, for paid services) and that's illegal. It doesn't matter if you use proforma or not, once it becomes an invoice it shouldn't be possible to change it. It really is that simple. Again, we don't want to use proforma invoices, not now, not in the future. We want to be able to send standard invoices, as is currently possible already, and it should not be possible to change them, ever.

Important Information

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