Jump to content

Troy

Member
  • Content Count

    520
  • Joined

  • Last visited

  • Days Won

    3

Troy last won the day on October 19

Troy had the most liked content!

Community Reputation

6 Neutral

About Troy

  • Rank
    Member

Recent Profile Visitors

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

  1. I've been holding off submitting a dispute so I could try the dispute handling built into WHMCS 8.3. Submitting evidence works great. I put together all the evidence I wanted to submit, got it submitted through WHMCS, and then finally submitted the dispute via the `Submit Dispute` button. A little green "The dispute has been submitted!" message popped up and the `Submit Dispute` button was disabled. Went back to the dispute list, and this dispute was still labeled `New`. Viewed the dispute, and the `Submit Dispute` button is still active. Logged into the Stripe dashboard, and the dispute is still in `Needs response` mode. The activity log at Stripe has several "A request to update a dispute du_xxxxxxxxxxxxxxxxxxxx completed" entries related to submitting evidence, and I can see the evidence I've submitted. I went back to the dispute in WHMCS and hit the `Submit Dispute` button again. Got the popup window warning that submitting the dispute is irreversible. Got the `"The dispute has been submitted!" after clicking Yes, but still nothing happened at Stripe. Ideas?
  2. I had already cleared all caches. For me it turned out to be the third party admin theme (Lara). Updating to the version specifically for 8.3.0 took care of it.
  3. I can confirm the same problem after updating to 8.3.0 today. Ticket #YDE-153158 submitted about this.
  4. Will WHMCS be resolving this in a better manner, i.e. allowing CloudFlare users to re-enable Rocket Loader in an update? I don't currently use CloudFlare, but I would think anything that can speed up WHMCS' page load/TTFB is something that WHMCS should not require one to disable. This discussion alone has me thinking about giving CloudFlare + Rocket Loader a try, but of course I will wait to see how this shakes out.
  5. FYI, the answer itself is encrypted in tblusers, so you can't change it without knowing the WHMCS encryption method or maybe an API call (dunno about that one). Best you can do otherwise is clear the security question directly in the database with update tblusers set security_question_id = 0 where email = "<user's email address>".
  6. I've searched but haven't found any threads discussing WHMCS' cPanel Licensing Module. Is anyone using it successfully with license autoscaling? I find the documentation confusing at best, and have been unable to get license autoscaling working properly. So far WHMCS support doesn't even seem to understand the problem as I'm describing it. If you set up license pricing in tiers using the standard pricing packages (cPanel Admin/Pro/Plus/Premier) autoscaling doesn't work. The client is unable to add an account to the cPanel server once the current license limit is reached, unless a license upgrade is processed. The pricing tab also does not allow one to use one of cPanel's autoscale packages as the basis for your tiers, because then there is no way to specify the account threshold for each tier. I've even tried defining the pricing tiers using cPanel's Admin/Pro/Plus/Premier packages and leaving the underlying license in Manage2 as an autoscale license, but WHMCS doesn't autoscale anything that way either (which I wouldn't expect but I tried it anyway). What I certainly do expect is that if they say the module is capable of autoscaling that it actually is. Why can't we use the autoscale license package (the only type of license that allow autoscaling according to https://support.cpanel.net/hc/en-us/articles/1500011418781) as the basis for tiers with account thresholds that we define? I feel like I'm either extremely dense and missing something simple, or am unable to properly ask questions about it, because WHMCS support is not helping AT ALL.
  7. I usually don't get into these tussles as I see it largely as a waste of time/energy. Usually the disastrous end result isn't changed by such complaints. I do enjoy reading them though! We're a small host with active clients in the low four figures. I've had two owned licenses since 2008 and only used one in production. Our costs are going up 1100% as a result of this increase. Not as bad as some, but enough to hurt. The thing is, if cPanel hadn't done this to us already, I'd probably switch to a monthly plan and continue with WHMCS. When cPanel raised their pricing, I opted to stick with them. When they raised it a second time, I began wondering where it would all end and started at least contemplating a control panel change, but wasn't yet serious enough to take concrete steps to plan such a move. When WHMCS raised their pricing, and I realized that if we switch our owned license to monthly we'll be paying monthly what we paid annually for support and updates, I decided enough was enough. Since we can continue running the current version of WHMCS without support or updates, we have some time to think about the best way to migrate away from WHMCS. However, what WHMCS may not have considered is how their action might be the last straw for people like me who had decided to stick with cPanel. When I look at the numbers, I realize that I can save far more monthly by migrating away from cPanel than I can from migrating away from WHMCS, so my first step will be to migrate away from cPanel. I can cut my control panel MRC in half or better by doing this and save far more per month than I would lose by switching to a monthly WHMCS plan. What I'm wondering is whether WHMCS thought about the impact their decision might have on the cPanel side of the house. In our case, where we might have opted to switch to a monthly WHMCS license were it not for the cPanel increase, we've decided instead to run WHMCS for some time on the current version AND also begin migrating away from cPanel. Without this price increase from WHMCS that wouldn't have happened (or wouldn't have happened as quickly--would have depended on future cPanel price increases eventually pushing us away.) Bottom line is that in our case, this increase will not benefit WHMCS financially, but WILL hurt cPanel financially. I can't help but wonder if this sort of scenario might be playing out for other cPanel & WHMCS customers as well.
  8. Good points for anyone who decides to mess with the registrationperiod value. The rest of it is fine as-is if you don't, but you're right that those two possibilities should be considered before you do. I wasn't sure if the outstanding invoice thing could be an issue, because in my case it would only apply if a client manually renewed a domain name (because of the registrationperiod being set to 1 on a daily basis right before auto-renewal invoices are generated), and I figured WHMCS wouldn't change the registrationperiod in tbldomains until the invoice was paid. However, a quick test confirmed that WHMCS does indeed update the registrationperiod when the renewal order is placed, even if the invoice is left unpaid. IMO that's bad form. It's already bad form to pre-determine that the next auto-renewal should renew for the same term as a manual renewal, but to change the registrationperiod before the invoice is paid is bad form on top of bad form. This makes me wonder...is there a potential loophole that can be exploited by a client? Consider the following: 1. WHMCS is configured to generate auto-renewal invoices 2 weeks before expiration, with the invoice due in 7 days. 2. WHMCS generates an auto-renewal invoice for 1 year. 3. Client orders a 3 year renewal manually before the auto-renewal invoice is due, and either pays the invoice or doesn't. 4. tbldomains.registrationperiod is changed to 3 whether or not the manual renewal order invoice is paid. 5. Auto-renewal 1 year invoice is paid during the daily cron when it comes due. It seems to me that auto-renewal invoice payment under these conditions would renew the domain name for 3 years when the client has only been charged for 1 year.
  9. If you use a supported registrar, WHMCS' Registrar TLD Sync can keep your domain pricing up to date without a lot of effort. However, it does NOT sync the pricing to your existing clients' domains. The Bulk Pricing Updater isn't suited to this task either, requiring many steps to update pricing for different TLDs, billing cycles and domain addons. I put together a SQL query that will set the recurring amount of all client domain names in tbldomains with your current domain pricing, and figured I'd share it for those whom it might benefit. This was written for WHMCS 8.1.3 and MariaDB 10.3. I recommend testing it on a copy of your data, and I make no warranties regarding it's suitability to your particular environment, nor claim that it is free of error. That said, it works well for me. Here are some suggestions for testing this on a copy of your data, assuming you have access to the server shell as root: 1. Export a copy of the relevant tables and import into a work database: mysqldump <your-whmcs-db-name> tblclients tbldomains tbldomainpricing tblpricing > ~/workdb.sql mysqladmin create workdb mysql workdb < ~/workdb.sql 2. Get an idea of the current recurring amount for all your active domains (to give you something to compare against after running the sql script): mysql workdb MariaDB [workdb]> select sum(recurringamount) from tbldomains where status = 'Active'; +----------------------+ | sum(recurringamount) | +----------------------+ | 50029.21 | +----------------------+ 1 row in set (0.000 sec) 3. Create a file to hold the SQL that you can run against the database: nano ~/domain_pricing_sync.sql The SQL to put in the file: SET @idp = (select ssetupfee from tblpricing where type = 'domainaddons'); SET @dns = (select msetupfee from tblpricing where type = 'domainaddons'); SET @fwd = (select qsetupfee from tblpricing where type = 'domainaddons'); update tbldomains d, tbldomainpricing dp, tblpricing p, tblclients c set d.recurringamount = case d.registrationperiod when 1 then p.msetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 2 then p.qsetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 3 then p.ssetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 4 then p.asetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 5 then p.bsetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 6 then p.monthly + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 7 then p.quarterly + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 8 then p.semiannually + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 9 then p.annually + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) end where d.is_premium != 1 and dp.extension = right(d.domain, length(d.domain) - locate('.', d.domain) + 1) and p.type = 'domainrenew' and p.relid = dp.id and c.id = d.userid and p.currency = c.currency; 4. Save the file and the run it against your work database: mysql workdb < ~/domain_pricing_sync.sql 5. Repeat step 2 and see what your total looks like after the update. Once you're comfortable the SQL works for you, you can run it against your production database manually after you update domain pricing, or even schedule it via cron if you want to automatically keep pricing in sync. There probably isn't a good reason for setting it up to run via cron, unless like me you don't like the way WHMCS allows a user to register or manually renew a domain for X number of years, and then assumes the next renewal should be for that same number of years. I personally run this SQL daily via cron, with this line added to the very top of the SQL: update tbldomains set registrationperiod = 1; This way if a client has registered or manually renewed for longer than a year, this will reset the domain to a 1 year registration/renewal with the current pricing for one year. It can certainly be argued that it's a bit of an overkill to run it daily just to keep a few clients' domains who occasionally renew for longer periods reset to 1 year, but I do it anyway. For me it takes a little under a minute to run this against 5,135 domain names. The SQL is written to handle those who use multiple currencies (I do not), and does NOT adjust the pricing for any premium domain names that are properly set (tbldomains.is_premium = 1). It does update ALL domains regardless of status. An additional where clause to only update domains with certain statuses (i.e. where status = 'Active' or where status not in ('Expired', 'Cancelled', 'Fraud', 'Transferred Away')) can easily be added to limit the amount of records updated if you wish. This does not update any open invoices, so it's conceivable a client with an open renewal invoice will still pay an outdated price and have the domain renewed. WHMCS doesn't store the domain extension separately in the tbldomains table, so it has to be calculated on the fly, hence "right(d.domain, length(d.domain) - locate('.', d.domain) + 1)". The assumption is that everything including and to the right of the first instance of a period in the domain name represents the extension. I can't think of a case where this would present a problem, but it's possible and something to consider before deciding to use this. Someone who is more motivated than I could take this concept and build an addon module with more flexibility, such as nice UI providing the ability to only update selected TLDs with selected Status values or some such. Feel free to do so if you are so inclined. Use at your own risk and test thoroughly before running against your production db!
  10. In case anyone else has these questions, here are the answers now that I'm set up in Texas: 1. Sales tax is remitted solely to the Texas Comptroller of Public Accounts, which then remits to the separate taxing locales as necessary. No need for level 1/2 taxes to separate state from local sales tax. 2. 20% of digital services / data processing is exempt from sales tax, so you should only collect 80% of the sales tax for which you will be liable. In my case 8.25% (State of Texas + Dallas City) * 0.8 = 6.6%.
  11. I'm getting ready to set up a second company in Dallas. (Current one is outside of Texas and I haven't had to deal with sales tax.) As I understand it, a Texas based company must charge sales tax for hosting services, (only to clients who are also located in Texas), but 20% of the charge is exempt. Texas sales tax is 6.25%, and Dallas city sales tax is 2.00%, for a total of 8.25% Two questions for anyone who is already in this situation: 1. Do you separate the two taxes (Level 1 and Level 2) or charge a single rate? I assume separating them would make it easier to report the amounts one should remit to each agency? (I haven't formed the company yet so am just assuming there would be two separate payouts, one to the state and one to the city?) 2. To accommodate the 20% exemption do you charge 5.00% state sales tax (80% of 6.25) and 1.60% (80% of 2.00) city sales tax? Reducing the tax rate by 20% is functionally equivalent to making 20% of the entire charge exempt, so I assume this would work out okay, but I'd like to get it right from the get-go.
  12. In version 8 it's viewable on the User tab when you click the drop down arrow for a user and choose the Security Question option. I'm now trying to figure out how in the world an Admin can clear it/remove the security question.
  13. The issue is clients wanting to change their passwords. WHMCS says their password is strong but then cPanel disallows it. Maybe the password strength in the WHMCS settings are for system-generated passwords only? Still it doesn’t seem wise to show the user they are using a good secure password only to then inform them of a failure when they submit it.
  14. Something as simple as MuFFin123# passes the WHMCS check set at 100, but fails cPanel set at 80.
×
×
  • Create New...

Important Information

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