RMBLR
-
Posts
17 -
Joined
-
Last visited
About RMBLR
RMBLR's Achievements
Junior Member (1/3)
1
Reputation
-
My post was pending moderator review. I think it was because there was the keyword, "H***bill" in it (I added the censor to this myself right now). Just venting, frustrated. Will spend hours doing this manually some other time via the admin area. It's still not clear to me why tbldomainpricing doesn't actually have the pricing for domains, only the TLD list, and why tblpricing has the domain pricing in it, somewhere, in the thousands of available rows. I'm not entirely certain what the consequences would be of deleting the TLD from tbldomainpricing and reimporting it, assuming the pricing for the previously deleted TLD already exists in tblpricing. Don't care to find out. 😀 I'm not comfortable enough with poking around the DB or creating custom queries to complete this task and stand by my statements that I shouldn't have to. 😉
-
Not comfortable giving an unknown 3rd party access to such a thing, sorry. I'll just continue to curse WHMCS for having such a shoddy system for managing domains despite the fact they really try to push those 3rd party registrar integrations on users. Guess I'll either set aside some time to do this one by one via the admin area, of which it'll take hours considering there are over 400 imported TLDs or just buy [some-other-software] and use it for domains specifically and eventually migrate to it once we get our custom modules for other things ported over. Have about 2,000+ domains registered for customers and every other day or so I'm manually having to remove one or two TLDs from the list that they see and purchase that we can't support or process, and refund them. It's a giant PITA and all WHMCS support told us to do was to do it manually from the database with no further instruction. We pay $150/mo+ for a license and can't even get a simple task like removing more than one TLD at a time completed. /rant EDIT: Guess I'm not allowed to mention any competitor billing software but strangers can PM me and ask me for database access.
-
Oh, so the domain pricing isn't in "tbldomainpricing", like one may assume. That table only lists TLDs, despite "pricing" in the name. Domain pricing is set in table "tblpricing", which has over 3,000 rows. This is too much of a mess and headache. I'm not going to sort through two different DB tables, try to mass delete corresponding data, because I can't do it properly through the WHMCS UI unless I select one TLD at a time, delete, let the page reload, then repeat the process 400+ times. Is this literally the only way? Someone make a module and I'll throw money at you because this is a giant pain. I'm still shocked that there is no straight forward method to do something like this.
-
I see no such option, no area where pricing is shown...
-
Additionally, this option won't impact customers who already have active domains with us, correct? We have many many domains sold, so if I mass remove all TLDs from the DB and reimport the ones we can or want to sell, it won't impact customers who have already purchased a .com, .net, etc since we'd obviously import those back.
-
Sorry, I don't understand. Is the pricing not also part of the "tbldomainpricing" table? So I can't just, for example, delete the rows that have the TLDs I don't want and be okay? Or are you saying that if I delete, for example, the row with .com and then try to reimport .com later I will have some sort of conflict? I'm very surprised there isn't a simple, straight forward way to do this from WHMCS directly, especially since they push so many domain registrar and reseller options on end users.
-
So, the tbldomainpricing table in the WHMCS DB. Via phpmyadmin, can just "Check All", then "Delete" safely? Then simply re-import the few dozen or so supported TLDs into WHMCS via https://whmcs-admin-url/utilities/tools/tldsync/import ?
-
I am interesting in figuring out how to do the following. Right now, it appears to only be possible manually, and well, it's a big PITA. 1.) Remove ALL available TLDs. Right now hundreds of TLDs are imported and many of them we can not legally sell or are TLDs that are managed by registries like Radix or XYZ which are horrible registries and deserve no money. The process to remove these any many ccTLDs is very time consuming, as each one has to be removed one by one, with the page reloading between each adjustment. There is no option to simply checkmark multiple TLDs for removal. 2.) How can we disable multiple year domain registrations. The problem is, many domains have a special first year price. If a customer orders a domain for 5 years, it's 5x the first year price even if years 2, 3, 4 and 5 are much higher. This is very problematic and a real pain, as such, we can not allow automated domain registrations as customers will take advantage of this flaw and we lose money on the very low margin domain sales. 3.) In fact, is it possible to just simply remove ALL available TLDs at once? Then re-add only the ones we want? This may be easier than figuring out how to do number 1 or 2 above. The domain / TLD management in WHMCS is very poor as it is, and it makes it very difficult to operate any sort of serious business that sells a lot of domain names like we do.
-
If I update a product's pricing, will this change the renewal pricing of existing customers of that product? I need to increase the pricing of a service addon/configurable option but do not wish to impact existing customers, only new ones. Thanks.
-
Troubleshooting lengthy cron-runs (2 hours, not resource limited, big database)
RMBLR replied to RMBLR's topic in Using WHMCS
Seems like the database is still massive after pruning the last six months of emails as well. tblemails 19504 1598240 KB Before I pruned them, tblemails was 1597216 KB, so somehow removing the last six months of emails INCREASED the size of the database? Doesn't make sense to me. -
Problem: Cron takes forever, sometimes doesn't complete. Output from: php -q /path/to/whmcs/crons/cron.php all -F -vvv WHMCS Automation Task Utility: all ================================== Daily Cron Automation Mode Queuing Tasks ------------- Force run any tasks: ignore "in progress" and "is due" Task queues ready Executing Application Queue --------------------------- 0/34 [â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 0% < 1 sec/< 1 sec 28.0 MiB Currency Exchange Rates 1/34 [â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 2% < 1 sec/< 1 sec 28.0 MiB Product Pricing Updates 2/34 [â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 5% 3 secs/51 secs 28.0 MiB Tenant Usage Metrics 3/34 [â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 8% 52 secs/9 mins 30.0 MiB Invoices 4/34 [â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 11% 52 secs/7 mins 30.0 MiB Late Fees 5/34 [â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 14% 52 secs/5 mins 30.0 MiB Credit Card Charges 6/34 [â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 17% 2 mins/12 mins 70.5 MiB Invoice & Overdue Reminders 7/34 [â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 20% 2 mins/10 mins 74.5 MiB Domain Renewal Notices 8/34 [â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 23% 2 mins/9 mins 74.5 MiB Cancellation Requests 9/34 [â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 26% 2 mins/8 mins 74.5 MiB Overdue Suspensions 10/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 29% 2 mins/8 mins 74.5 MiB Overdue Terminations 11/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 32% 2 mins/7 mins 74.5 MiB Fixed Term Terminations 12/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 35% 2 mins/6 mins 74.5 MiB Inactive Tickets 13/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 38% 2 mins/6 mins 74.5 MiB Prune Ticket Attachments 14/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 41% 2 mins/5 mins 74.5 MiB Delayed Affiliate Commissions 15/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 44% 2 mins/5 mins 74.5 MiB Affiliate Reports 16/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 47% 2 mins/5 mins 74.5 MiB Process Email Queue 17/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 50% 2 mins/4 mins 74.5 MiB Email Marketer Rules 18/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 52% 2 mins/4 mins 74.5 MiB Process Email Campaigns 19/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 55% 2 mins/4 mins 74.5 MiB Credit Card Expiry Notices 20/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 58% 2 mins/4 mins 74.5 MiB SSL Sync 21/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 61% 3 mins/5 mins 74.5 MiB Server Usage Stats 22/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 64% 4 mins/7 mins 74.5 MiB Overage Billing Charges 23/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 67% 4 mins/7 mins 74.5 MiB Client Status Update 24/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 70% 4 mins/6 mins 74.5 MiB Domain Expiry 25/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 73% 4 mins/6 mins 74.5 MiB Ticket Escalation Rules 26/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘â–‘] 76% 4 mins/6 mins 74.5 MiB Data Retention Pruning 27/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘â–‘] 79% 4 mins/6 mins 74.5 MiB SSL Certificate Reissues 28/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘] 82% 4 mins/5 mins 74.5 MiB Update Server Usage 29/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘â–‘] 85% 4 mins/5 mins 74.5 MiB Update Server Meta Data 30/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘â–‘] 88% 4 mins/5 mins 74.5 MiB WHMCS Updates 31/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘â–‘] 91% 4 mins/5 mins 76.5 MiB Run Jobs Queue 32/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘â–‘] 94% 4 mins/5 mins 76.5 MiB Domain Transfer Status Synchronisation 33/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–‘] 97% 4 mins/5 mins 76.5 MiB Domain Status Synchronisation 34/34 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“] 100% 5 mins/5 mins 76.5 MiB Sending Daily Cron Digest email Executing System Queue ---------------------- 4/4 [â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“â–“] 100% 2 hrs/2 hrs 88.5 MiB IMAP connection failed: PhpImap\Exceptions\ConnectionException: ["[CLOSED] IMAP connection broken (server response)"] in /path/to/whmcs/modules/addons/abusemanagerpro/includes/phpimap/vendor/php-imap/php-imap/src/PhpImap/Imap.php:712 Stack trace: #0 /path/to/whmcs/modules/addons/abusemanagerpro/includes/phpimap/vendor/php-imap/php-imap/src/PhpImap/Mailbox.php(1725): PhpImap\Imap::open() #1 /path/to/whmcs/modules/addons/abusemanagerpro/includes/phpimap/vendor/php-imap/php-imap/src/PhpImap/Mailbox.php(1686): PhpImap\Mailbox->initImapStream() #2 /path/to/whmcsmodules/addons/abusemanagerpro/includes/phpimap/vendor/php-imap/php-imap/src/PhpImap/Mailbox.php(469): PhpImap\Mailbox->initImapStreamWithRetry() #3 /path/to/whmcs/modules/addons/abusemanagerpro/includes/phpimap/vendor/php-imap/php-imap/src/PhpImap/Mailbox.php(664): PhpImap\Mailbox->getImapStream() #4 /path/to/whmcs/public_html/modules/addons/abusemanagerpro/hooks.php(0): PhpImap\Mailbox->searchMailbox() #5 [internal function]: hook_abusemanagerpro_fetchimap() #6 /path/to/whmcs/vendor/whmcs/whmcs-foundation/lib/Hook/Manager.php(0): call_user_func() #7 /path/to/whmcs/vendor/illuminate/support/Facades/Facade.php(261): WHMCS\Hook\Manager->run() #8 /path/to/whmcs/includes/functions.php(0): Illuminate\Support\Facades\Facade::__callStatic() #9 /path/to/whmcs/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): run_hook() #10 /path/to/whmcs/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->tearDown() #11 /path/to/whmcs/vendor/symfony/console/Command/Command.php(298): WHMCS\Cron\Console\Command\AbstractCronCommand->execute() #12 /path/to/whmcs/vendor/symfony/console/Application.php(1028): Symfony\Component\Console\Command\Command->run() #13 /path/to/whmcs/vendor/symfony/console/Application.php(299): Symfony\Component\Console\Application->doRunCommand() #14 /path/to/whmcs/vendor/symfony/console/Application.php(171): Symfony\Component\Console\Application->doRun() #15 /path/to/whmcs/public_html/crons/cron.php(0): Symfony\Component\Console\Application->run() Ok, so line items 0-5 seem easy to fix and I've since corrected that issue. A plugin (Abuse Manager Pro) had some incorrect IMAP details but we're not piping emails in from our abuse inbox anyway so I just disabled that function. Line items 6-15, however, are less obvious to me. I searched for a few of them and couldn't find anything specific. Our database is quite large, at 2GB or so... I do prune and clean it up regularly. Not sure what can really be done there since it needs dumped and backed up each day. I just ran system cleanup and pruned it, as well as optimized it and still: Total Tables: 184 - Total Rows: 1561066 - Total Size: 1907888 KB The box hosting our WHMCS install isn't constrained by resource limits nor are any resource limits being hit, other than 100% CPU utilization of a single CPU core when the database is being dumped but other than that, normal CPU usage (all cores combined) average at about 5-10% usage. Not sure if something can be optimized to make the DB perform better. Hardware wise, it's not an issue. Some PHP stuff: PHP 8.1.19 (cli) (built: Jul 6 2023 23:08:27) (NTS) Copyright (c) The PHP Group Zend Engine v4.1.19, Copyright (c) Zend Technologies with the ionCube PHP Loader v12.0.4, Copyright (c) 2002-2022, by ionCube Ltd. php -ini | grep "memory_limit" memory_limit => 4096M => 4096M php -ini | grep "max_execution_time" max_execution_time => 0 => 0 Date/Time also match from the server and my WHMCS install (EST) I have already read: https://help.whmcs.com/m/automation/l/1277110-resolving-a-cron-invocation-frequency-warning https://docs.whmcs.com/System_Cleanup https://help.whmcs.com/m/automation/l/683269-advanced-cron-troubleshooting Any thoughts? Pointers? I'm mainly concerned about the items listed 5-15 in the output of the manual cron run earlier. Thanks!
-
Nothing at all? Surely I'm not the only person in existence to encounter this error. I've got one hail mary in me, and it's going to be a pain to attempt. If that fails to fix the issue then I guess we'll just drop the money on Hostbill and have their team handle the import and correction. We've got a WHMCS Business 1,000 license and this is impacting way too many customers and being too much of an annoyance to not have anyone at WHMCS motivated to help us find the cause of this. I appreciate the help we've been given / common trouble shooting steps but this is costing me time and money to fix and no one seems interested in seeing that it's resolved.
-
Okay, I've had about enough of this issue. I've already gone through everything with support. I've disabled plugins and hooks, reconfigured things, and yet the issue persists to a point where I'm not certain how to proceed. Support has offered some useful tips but are unable to diagnose or provide anything that has fixed it. DETAILS: Problem: Migrated our WHMCS portal to a much larger VM to accommodate growth and to give it more juice since the DB is massive and it likes to crawl or die every morning when the cron runs. Aside from that annoyance, the pricing showed properly and correctly and never without issue. After migration, we ran through the basic checks. Everything worked fine. No errors were present. Things were good. The server environment between the original and migrated install should be a 1:1 match. All dependencies were met and things went smoothly. After a few weeks, we started to notice that anywhere in WHMCS where pricing is shown (whether it be in the admin side or client side, public or private view) that sometimes the displayed pricing doesn't show correctly. For example, if an item is shown as 10.00, if you reload the page five or six times you may see that it is now all of a sudden 12.40, for example. Refresh, and boom, it's back to 10.00. A new customer looking at the product list? Goes to order? Boom, now (sometimes) the price is different than the page they were just on. Add a 10.00 item to the cart and now it's show 12.40 (or something). Go to check out, and it's changed back to 10.00. WHMCS support had this to say in a ticket regarding the matter: It was replicated on their end with our install. Sometimes the incorrect value gets passed to the payment gateway and that is what is invoiced or charged, as well, which is also a big problem as customers think you're trying to get a couple extra bucks out of them which is certain;y not the case, and I'm tired of explaining it's a software bug that is random. Has anyone else experienced this? Any tips for fixing it? WHMCS has reviewed our configs, our phpinfo, etc and has only given suggestions on how to fix but nothing has worked. EDIT: Apache, MariaDB, php 7.4, WHMCS 8.1.X on a Debian 11 VM
-
Premium Domains not appearing in results as premium domains.
RMBLR replied to RMBLR's topic in Using WHMCS
Anyone? -
We've sold hundreds of domains now, but one issue I'm seeing is occasionally someone will try to register a domain that is 'available' but worth thousands of dollars so we do not process their order since it's a premium domain they're trying to obtain at standard pricing. Why is our WHMCS not marking these domains as such in the order process? See our settings in the screenshot attached. This is one of the major reasons why we do not do very large deposits into our domain accounts as we don't want some grifter taking advantage of this. Tonight, a customer placed an order for a domain that would typically be $12 through us but is $2,500+ at the registar. Obviously we canceled the order but this has happened several times and it's becoming annoying. I've tried many different variations of "Lookup Provider" and making sure the "Premium Domains" option was enabled in WHMCS and it just seems like this feature doesn't work, at all? Is there anything else I need to do to have this work properly?
