Leaderboard

Hi Community, Anyone help me regard this when our client is the visit our invoice in our website prohosty.com then Rupees Symbol is working Fine See this screenshot http://prntscr.com/myl1j4 and if client download invoices then rupees symbols change into "?" symbol see this screenshot http://prntscr.com/myl1r8 Please help to fix it

Thanks for Support ❤️

basically, you need to change the font used in the PDF invoice from the settings... https://help.whmcs.com/m/troubleshooting/l/705073-troubleshooting-question-marks-in-pdf-invoices-quotes

@hostwing are you using a bridge or theme plugin at all?

Some problem facing bro

Same Issue 😫 Please give Me Solution

Ensure that WHMCS admin -> Setup menu -> General settings -> other tab -> "Allow Client Registration" is checked. If it is already, make sure the register.php file is actually there.

Yes, but how you implement it depends on how you are connecting to the SaaS app from WHMCS and how fast you want them to be billed for their usage . For example, you could use a server / provisioning module to connect to the SaaS, get usage and use AddBillableItem API to be invoiced when you set. So, say their usage is 106 SMS since last checked and for each SMS is $0.01. The billable item would then be $1.06. You could also do straight invoice generation, but doing that on a daily basis might be a bit much. With the billable item,. you can set it to their next invoice for example so they only get one invoice a month. A custom field could be used to track their usage and bill off that. Another option would be to use the internal classes and deduct from the $credit amount and record it with a addtransaction API call. However, I think the billable item approach provides a better record tracking. On the SaaS side, if you want to have hard limits, you could do an addon module for the connecting the two systems and have the addon module query for paid for usage and then limit if needed. You could do external API calls also, but personally like to have API access as limited as possible and so passing through an addon module would be the best option.

Welcome to WHMCS.Community lsmxplore! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.

the option would exist within the API, but WHMCS cannot do this currently. I don't want to shatter any delusions here as I know you've already just posted a request on another matter, but generally feature requests can take 5 years for WHMCS to complete... and i'm not saying that 5-year wait is an exception to the rule, it's the norm. i'd totally agree with @inteldigital here - they could do it (if there was sufficient demand, inclination or $$$ for them), but they won't do it. I agree with that too... feature requests are all well and good, but even if they get completed, they will take years to ever get to that stage... so they're more for "wouldn't it be nice if WHMCS could do this one day" type ideas... the minute you need WHMCS to do something NOW (or even soon), then you have to throw money at it by getting a developer in... maybe if you caught WHMCS during a beta period and it was a minor tweak, it *might* get done - or apparently having a quiet word at a trade show (which is where some of the recent nonsensical ideas were supposedly born!)... but for something like this, it would likely need a significant number of votes to get considered and it would take years to generate those numbers (and that's assuming that others could even find the request in the first place). FWIW - even if WHMCS could do this, i'm not sure that I would use it as you can easily use Nominet Online Services to get a list of domains on your TAG(s), export the .uk domains from WHMCS and compare the two - I already do this at the start of each year... I couldn't really do it in WHMCS anyway as I have a large number of .uk domains that aren't included in WHMCS. the usual suspects who rear their heads only when you post in Service Offers & Requests? 😛 and before you ask, this is not a project for me Matt! 🙂

Welcome to WHMCS.Community jessicahansonpro! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.

Welcome to WHMCS.Community abjwebhost! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.

Another way would be to use a global variable. $CONFIG['SystemURL']; These 2 options will return the URL without the slash at the end. This will return the URL with the slash at the end. https://domain.whmcs.com/

as you have found, $companyurl will work (which is the value from general settings -> general -> domain), but $systemurl isn't passed to the template - therefore, there are three solutions that I can think of off-hand... manually hardcode it in the template (as you have currently) - if you're not going to change your systemURL frequently, then there's probably no harm in doing that. use the Class documentation to obtain the setting... use WHMCS\Config\Setting; $systemURL = Setting::getValue('SystemURL'); adding that code to the top of the invoicepdf.tpl, anywhere after the <?php and before you want to use the variable, will work... when you want to output the System URL setting, you can just use $systemURL in the template wherever you want. similar to 2, you query the tblconfiguration database table direct using Capsule... use WHMCS\Database\Capsule; $systemURL = Capsule::table('tblconfiguration')->where('setting','SystemURL')->value('value'); again, adding that code to the top of the invoicepdf.tpl, anywhere after the <?php and before you want to use the variable, will work... when you want to output the System URL setting, you can just use $systemURL in the template.

Hey all, I've noted this thread in the internal case log and have asked internally if we can look at the priority on this one 🙂

Solved. The issue was on WHM side. The packages were exceeding the limits of the Hosting plan.

@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.

perhaps by reading the PHP manual. http://php.net/manual/en/function.checkdnsrr.php

Thanks for the information One More Question Please help Solve It

I make an addon but I don't know how to encrypt php license file. please help

Any Method to encoded then if I lose. ?

Yes it's really difficult to get back your orginal file

If I encode then how I get back original file

Invoices need some tweaking but will only show Email address and no names. Yes, I would like to be able to save the email as both email and firstname at the time of client creation.

Hi @ju5t, CURLINFO_CERTINFO is used to obtain the certificate information for display. If this is empty, you're correct that WHMCS will also be unable to retrieve certificate data. Thanks for your feedback regarding the help article on that point, I have passed that on to the documentation team. The Help > System Health Check status page has a version check to advise on the appropriate version of cURL to return this data. We are also tracking the specific environments with this flaw. As yet we've been unable to reproduce on stock CentOS7 repos we set up for testing this. But please do keep that info coming: PHP version OS OS Version CURL Version Output from Test Script In 7.7.0 we added PHP path detection logic to the cron command on the Setup > Automation Page, to help users in EasyApache Multi-PHP environments specify the same PHP binary for web and the CLI. In 7.7.1 we fixed an illegal mix of collations error which was reported. This specifically applied to older installations of WHMCS made where the server's default database charset/collation was not utf8. The Collation error now being discussed is unrelated to certificate validation; it would not prevent the SSL check on page load or cause false positives/negatives. But does stop the checks being performed in the background by the daily automation tasks. The `mysql_charset =utf8` line is standard on all installations since v5.3 (released in 2013) so most people should have it. It's presence is recommended. Case CORE-13267 has been opened to investigate how this error could be negated for installations with an latin1 charset.