Leaderboard
Popular Content
Showing content with the highest reputation since 05/30/24 in all areas
-
It's few days I'm experiencing a strange malicious activity, that is the registration of several fake accounts with the following characteristics: all of them use no-existing email addresses, but existing domains ( @palestinedrinks.com, @docomo.ne.jp, @yahoo.com, @aol.com) all of them came from USA IP all of them use plausible US names and addresses they came from different IP, but often belonging to the same IP class (i.e. I blocked 84.32.60.0/24 and 104.165.169.0/24) many (or maybe all of them) after the registration try a password reset (which can't work because they're using a non-existent email account) Not a huge number: just a dozen of them in two days... Anyone experiencing the same issue? Anyone having any idea about the goal of such activity?5 points
-
Thanks, Kai for your valuable feedback. The thing is we remained a long time loyal Hexonet partner because of the wonderful support that was provided by you and your team. You were always receptive to our ideas and feature requests, and improved the modules making them the best ones out there. It's why we knew we will never leave Hexonet despite better pricing available elsewhere. And now, here we are completely lost and abandoned at the moment. We wrote to CNIC asking us to at least give us the same terms as we had with Hexonet. But they came back saying we must pay the new account fees, apply for promos manually for each TLD and get pre approvals, and then follow up on the success of our promo campaigns to be considrerd for promos again, and pay high tiered registration and renewal pricing unless we have a high volume of domains. We did not have to do all of that with Hexonet. What's good for the goose is good for the gander. What was working with Hexonet should work with CNIC. In fact, CNIC being larger should offer even better deal and more support to its partners, but it's completely opposite. Charging account fees, imposing tiered pricing with smaller partners having to pay higher prices, and having to opt for promotions manually for each TLD, and then following up on progress are all counterproductive and serve no purpose whatsoever. These issues will force loyal partners like us to look elsewhere to support our clients. It goes without saying that both promotional and discounted pricing should be applicable across the board and be available to all partners allowing them to support their clients and remain competitive, and there shouldn't be additional account fees on top. We are very sad that we are being forced away from the modules, company and team we loved. Best, FW - RD4 points
-
That's a hook I developed and sold to Hexonet. They've probably expanded it a lot though as this was many years ago. When I asked OpenProvider about it, they said they had a similar feature for WHMCS. If not, I'll just create one from scratch again. It's really dead simple: Intercept the domain registration with the PreRegistrarRenewDomain hook point Be aware that WHMCS will send the "Domain Renewal Failed", so you might want to abort sending this email as well Use the providers API to transfer the domain instead Write logic for TLDs that aren't renewed during transfer - these would to be renewed after transfer That's basically it. It's not even 100 lines of code. I still have the code but I can't share it.3 points
-
Hey, all! Been a few weeks since my last look at this thread. My initial thought was that we would go with DynaDot, but they do not support a lot of the TLDs we already offer. We had also ruled out OpenProvider initially because we had to pay them a yearly membership subscription. However... We've spent the last month crunching numbers and comparing various providers, and OpenProvider looks to be the best alternative. Even though we have to pay a yearly fee, we are saving thousands of euros every year because we get no markup on domain prices. We have been speaking with OpenProvider for the past week and signed up yesterday, getting a nice discount for the first year. Apparently, we are not the first one to contact them regarding the CentralNic migration. If I understood correctly, they have methods to take care of the migration from Hexonet/CentralNic to OpenProvider. Another incentive for us to move to OpenProvider is the fact they we can authenticate our domain and have them send emails on our behalf (such as WDRP messages). This is something I've been requesting from Hexonet for years because we had a lot of clients that were suspicious of emails coming from @ispapi.net, claiming to be sent on behalf of us. Oh, and they respond to tickets very quickly. We don't have to wait days or weeks. Looking at you, CentralNic. Hexonet has just announced that the migration dates have been moved (May 2025 instead of Feb 2025 IIRC). This gives us plenty of time to move everything. Initially, we thought we would actually need to top up our CNR accounts with 75$ - but it looks like that's no longer the case đ My boss is no longer annoyed about the migration. We are gonna save a bunch of money with minimal effort - and we get better service by the looks of it.3 points
-
WHMCS happy to increase the price yet again yet refuse to refund for after overcharging me for years đ It's becoming laughable at this point. As you stated which updates have we seen that users actually wanted? I am starting to route heavily for all "Web Pros" competitors: - Blesta - DirectAdmin Would love to see both take over the industry.3 points
-
We pay a subscription for a software, and for that software to stay relevant the software is supposed to add new features without imposing price increases. In whmcs case, there has been no new features that the community needed, and yet price increases are being imposed.3 points
-
We have a hook to check various data from user upon registering (do not use disposable email address, do not use special characters in address, and so on...) We modified it in order to prevent registering from the USA. Full code is available here: https://github.com/DomainRegister/WHMCS/blob/master/checkuser.php3 points
-
Hi, My name is Thomas. I have been working with the WHMCS system for quite some time. The first version I started off on was version 5.0, after graduating high school I ended up getting a job at WHMCS, now I am currently a full-time college student and I have about 1 1/2 years left before I obtain my bachelors degree in cybersecurity. I currently provide custom WHMCS development and work closely with WHMCS-services to develop new plugins as well as develop my own plugins. Check out my MarketPlace page: https://marketplace.whmcs.com/group/AdaclareLLC More Plugins coming soon, stay tuned. - Thomas3 points
-
When I started using Turnstile, spam ticket submissions stopped.... I don't know why WHMCS is stuck with reCaptcha !!3 points
-
The hook works fine, so for me it doesn't make any difference - the issue with fake registrations has been solved. I'm just saying that since you can see that so many people solved the issue not with reCAPTCHA v3, but with Turnstile, and since you're doing hCAPTCHA anyway (hCAPTHCA vs Turnstile should also be a matter of a couple code changes), you could deliver both. Which feature request came first / second, has more votes etc doesn't make any difference to us users - we're looking for solutions, and the current solution is a hook. Do you want people keep using the hook, or integrate the solution into WHMCS and have everyone happy.3 points
-
I would like to add here that in general the fraud detection and protections are extremely poor in WHMCS and need substantial work. There are multiple workflows that allow bad actors to bypass checks, and do things such as test credit cards (using auth transactions) without hitting any retry limits. Some of these have been brought up before: https://whmcs.community/topic/232237-maximum-credit-card-retry-limit/ This attack is just the latest example of the systems in place not being up to scratch. We've implemented our own additional fraud detection system using the ClientAdd and ClientAreaPage hooks to push people into extra checks and limit credit card retries etc but we shouldn't have to. WHMCS desperately needs to take fraud protection seriously, it's not something to be outsourced, it's not going to solved with a captcha and the community deserves solutions and customisable tools to manage our risks and options on this front.3 points
-
Assuming this won't continue for ever.... weeks or months, we implement this: <IfModule mod_rewrite.c> RewriteEngine On # Check if the User-Agent matches RewriteCond %{HTTP_USER_AGENT} "Mozilla/5.0 \(Windows NT 10.0; Win64; x64; rv:127.0\) Gecko/20100101 Firefox/127.0" # Check if the request method is POST RewriteCond %{REQUEST_METHOD} POST # Check if the URL is register.php RewriteCond %{REQUEST_URI} register.php$ # Deny access by returning a 403 Forbidden status RewriteRule .* - [F] </IfModule> The agent is always the same, so we block it on web server layer. Hope it helps.3 points
-
Here is another one, 17 minutes later. Again, see referrer of register.php, seems they use something on this page to do the rest: cat access_log | grep 5.102.101.157 5.102.101.157 - - [05/Jul/2024:05:17:21 +0200] "GET /register.php HTTP/1.1" 200 6168 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 5.102.101.157 - - [05/Jul/2024:05:17:22 +0200] "GET /cart.php?a=add&domain=register HTTP/1.1" 200 43142 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 5.102.101.157 - - [05/Jul/2024:05:17:23 +0200] "POST /cart.php HTTP/1.1" 200 54 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 5.102.101.157 - - [05/Jul/2024:05:17:24 +0200] "GET /cart.php?a=checkout&e=false HTTP/1.1" 200 20441 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 5.102.101.157 - - [05/Jul/2024:05:17:55 +0200] "POST /cart.php?a=checkout HTTP/1.1" 302 356 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 5.102.101.157 - - [05/Jul/2024:05:17:55 +0200] "GET /cart.php?a=fraudcheck HTTP/1.1" 200 7110 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"3 points
-
The activity is slowly going on... every few hours, a new fake account is created. After the banning of the domains used for emails, "generic" email domains are used (@gmail.com, @msn.com, @icloud.com, yahoo.com) just for reference, I report here the full list of IP used: 84.32.60.0/24 104.165.169.0/24 156.239.55.38 45.146.203.224 5.102.101.151 104.234.211.171 104.165.127.0/24 23.230.167.30 140.99.127.42 23.27.240.2083 points
-
It should be opt in, John. Always. Don't add things anywhere like this without direct opting in during installation. Show it to the admin (with no hopes of removal there, like the marketplace), and have it not appear anywhere in customer facing pages unless the admin agrees and chooses to. Simple.3 points
-
I'm bewildered that this is even a question. Why would you *forcibly* add this without a option to turn it off? WHMCS is used by thousands of web development companies who want to sell their own development services and not push people to use Sitejet. Your motivations here are very transparent - it's just like the debacle with the SSL warning icons. You guys are just trying to sell your own services. It's been years since that "feature" was added and after years of requests there is still no way to turn it off. The answer is simple - stop adding features without giving clients an option to turn them off. Surely this cannot be that difficult of a concept to grasp?3 points
-
The better option is to make this FULLY OPT IN for the admin. Don't enable or display ANY of it ANYWHERE until an admin of the WHMCS installation reviews and decides to offer it. Ourselves, as an example, host the websites we design/create almost exclusively. There will never be a time in the foreseeable future we would want our billing system to advertise a self service web design type application. The WHMCS logic is "add it without asking, and see if the complaints are large and loud enough to make it optional". Not for the first time, as I recall (I'm reminded of the unwanted SSL icons, checks and 3rd party links, for one).3 points
-
Hello @ThemeMetro This is a known issue, and we have published a HotFix. For more details, please review the following. Apologies for any inconvenience. Kind regards, Stephen.2 points
-
Thanks to @Mytihost, I found an elegant solution for this issue. The following hook: add_hook('ClientAreaPage', 1, function($vars) { if (!empty($vars['clientsdetails']['customfields'])) { $customfieldsAssoc = []; foreach ($vars['clientsdetails']['customfields'] as $field) { $customfieldsAssoc[$field['id']] = $field['value']; } return ['customfieldsAssoc' => $customfieldsAssoc]; } }); makes available the value of any client custom field in a template, using i.e. the form {$customfieldsAssoc.17} (where "17" is the id field in the tbl customfields)2 points
-
Hi @Jade D, I have responded to your ticket, but just wanted to follow up here so there's an answer if anybody else comes across this. The underlying issue here is that your web server was advertising a domain other than that registered for your license. This causes the license cache in your install to be invalid, and so your install needs to check in with our licensing infrastructure to validate your license. Since the details we held about your license were different to those being advertised by your web server, your install kept making a request to our licensing API. We rate limit all requests made to our licensing infrastructure to ensure stability thereof for all our customers. If your server sends too many requests, it will be temporarily blacklisted as part of this rate limit. To resolve this, make sure that your web server is only advertising the server_name that we have listed in your Valid Domains. Wait for 30 minutes or so and the rate limit will be removed, then your install will get a response back from the licensing servers that your license is valid and access will be restored. If anybody is unable to get to the bottom of this, please reach out to our support team and we can help!2 points
-
You aren't authenticated in your hooks. The hooks aren't running as you - they're running as the system. WHMCS doesn't offer a native way of logging in as an admin in a hook. If you just want to download the invoice, you can include /includes/invoicefunctions.php and run the pdfInvoice($invoiceId) function.2 points
-
I take it you weren't here when WHMCS yanked owned license update "support addons" and we all lost any updating of those convenient owned and now worthless licenses many of us bought? I had two.2 points
-
Next week we'll test our module. It works like this: You define the old and new registrar modules New registrar should be configured as the default for new domain registrations for a specific TLD When WHMCS attempts to renew a domain, it will check if the current registrar module is defined as the old registrar in the module settings and if the new registrar has been configured as the default for the TLD Use the new registrars _GetTldPricing() function to see if EPP code is required and get the transfer price for the TLD If EPP code is required, fetch it from the old registrar using their _GetEPPCode() function If transfer price is set to 0, we assume domain is not renewed - renewal will need to happen after successful transfer (this part is still WIP) Run the the new registrar's _TransferDomain() function If anything goes wrong, send an email to admins If the transfer is successful, the client receives an email with relevant information and the domain's registrar module is updated. I plan on adding support for registrars that doesn't have a _GetTldPricing() method, but this would require feeding the module with information about EPP requirement and whether domains are renewed during transfer.2 points
-
I have started work on an addon module that can hopefully work with any registrar in WHMCS. You have to define the source and destination registrar module, and the addon module takes care of the rest.2 points
-
Hello everyone. I see that here are some respected figures in the WHMCS world. I made a decision some time ago, it is difficult and complex. I will try not to use anything from WebPros. This is a difficult decision, but I see that everyone shares the same feeling, they do not care about us. Is it extremely difficult to leave cPanel? YES We are working hard to improve DA as well, and we are also working on other open source control panels. Is WHMCS very good and does it solve a lot of things? YES We do not have viable alternatives yet, but I am sure that there are many people who are dissatisfied and very soon an alternative will appear... and when it does... well... An idea... Has anyone ever thought of 'making a clone' of WHMCS? Something that WHMCS modules could be used for? Where WebPros plays, I run. I am not criticizing people, but rather how business is conducted. I understand that we all wake up in the morning to make money. I do not use any pirated tools, it is very complex to stay competitive.2 points
-
Yup if this is the case then its time to move, we are fortunate in that DNS.business have offered us cost price to move domains in so we encourage our clients to migrate at cost and do this in bulk. Will have to get a mail sent out tomorrow and start migrating because this is BS, and I told them (Centralnic) this was a stupid idea a few months back when they engaged with us asking us to move all of our domains over. Despite the monthly amount being marginal, $6 or what ever it was, its about principle. OpenSRS pulled similar sketchy unethical * and we moved from them to Hexonet2 points
-
Update a week later: We still haven't heard back from our KAM, despite CentralNIC promising us a response within last week. CentralNIC failing to keep their promises and charging us a "service fee" means that our CEO has given us the green light to start finding another company to do business with instead of CentralNIC. The price increase for regular domain operations is not what made him make that decision. It's the fact that CentralNIC responds to important questions really slow doesn't keep us updated when they're supposed to introduces a laughable service fee (his words) that has no purpose. CentralNIC should be more than capable of generating a profit since they're not even a cheap provider. The service fee is just a way to grab more money, and I'm pretty sure they settled on $6 per month because that's a low enough amount that 90% of their resellers won't complain. So, unfortunately, we'll most likely move to another provider unless CNR suddenly steps up their game.2 points
-
Yep you can bet your life it's the next "big feature" coming to WHMCS. The all new "Social Bee Marketconnect integration" đŽ2 points
-
I'm fuming. Is this yet another price increase, after the last not long ago?2 points
-
Please, add your votes to that feature request. This is improving registrar integrations in direction to specific ccTLDs and leads to a smoother domain registrar integration and page load improvement. I've seen that topic often enough addressed via customer support on our end (and even here in the community board). Thanks guys! -> https://requests.whmcs.com/idea/hide-register-lock-menu-from-the-domain-which-cant-be-locked2 points
-
bump - if you could vote again please đ2 points
-
Dear Open-Xchange customer We'd like to inform you that an OX Cloud service degradation was detected on 19/09/2024. The teams at OX had seen an issue with LDAP and items like additions, deletions and slow password changes. As of yesterday @ 12:50 BST all is working fine again and no error should come up (is any in the past).2 points
-
Completely agree with @PapaKai. It was definitely a nice thing to be able to go through the source code for the Hexonet module for WHMCS as a developer. Doing certain things in WHMCS is a PITA and I could more often than not figure out a solution to my problems by looking at their code. That being said, I totally understand why they encrypted their code. We've been very happy to do business with Hexonet. Especially because Kai is so easy to get in contact with. If we open an issue on their Github repo, we have a reply rather quickly. Sometimes a fix is uploaded within hours. I remember on one occasion, we had an issue with a specific premium domain. I was asked by Kai if we could do an online meeting, he found the issue and released an update fixing the problem not even an hour later. I've also been in contact with him a few times regarding things completely unrelated to their modules, yet he still provided a lot of useful information. At this point I'm convinced he has written more documentation on the WHMCS code than the WHMCS developers has đ2 points
-
> Hexonet was the best...sadly it seems they've abandoned the Hexonet platform for their CentralNic Reseller, which provides encoded WHMCS modules. So not as flexible as the Hexonet modules of the previous era... @RadWebHosting Our software bundle for CNR (CentralNic Reseller) is developed by the same team (my one). We did our best in regards to aligning the feature level to the HEXONET integration (just 2 minor points are left). We started with the encoding of the HEXONET (aka. ISPAPI) Integration as well a while ago. We are spending resources (and by that money) on making the world of WHMCS a lot better, but are not open to share insights to our code base to others (including competitors!). So, whenever there's something not working / not working as expected / not flexible enough / missing, just open a support ticket and address that. We usually can help with providing a solution (adding a feature / patch / hack or explaining about a whmcs quirk that can be used or by consulting in general). Sometimes, Resellers are even not aware that we already have a solution at hand / built-in or that it is possible somehow via WHMCS in the meanwhile. That's the key - addressing your needs and questions. Otherwise, yes, how should we help out in terms of closed source software?2 points
-
I think in addition to this, most sensible clients realize that using *any* Webpros product is a *huge* risk. Sure Sitejet is included free with cPanel today, but given the recent history that Webpros has of extorting its client base for as much money as they possibly can, I think most of us are very conscious of the fact that there is a good chance that this currently "free" site builder may come with an extortionate price increase down the road.2 points
-
Version 1.0.0
289 downloads
A patch is being provided to add Google reCAPTCHA v3 spam and abuse protection to WHMCS v8.10.1 only. This feature will be included in v8.11 and above. If the reCAPTCHA v3 score is above the threshold, the form submission is blocked and an error is displayed "Recaptcha verification failed: Unknown error" To apply the Hotfix: Click "Download this Hotfix" to the right of this page. Upload and extract the file to your WHMCS installation's directory. If you have customised your admin directory, make sure to upload the contents of `admin` to your custom admin directory. When asked to override files, select yes. Go to https://www.google.com/recaptcha/admin Click + to register a new site Choose the `Score based (v3)` reCAPTCHA type. Enter your domain under the domains section. Click Submit Copy the Site Key and Secret Key that Google generated and enter them in WHMCS. Return to WHMCS and to to Configuration > System Settings > General Settings > Security tab. Enter the Google reCAPTCHA Site Key and Secret Key. Check Shopping Card Checkout and Client Registration under reCAPTCHA for Select Forms. For reCAPTCHA Score Threshold, enter the desired minimum score for reCAPTCHA verification. You can enter a value between 0 (least restrictive) and 1 (most restrictive). For example, `.5`. Click Save Changes Submissions will start to be recorded on the Google reCAPTCHA site, alongside a score for each threshold. Use this information to adjust the reCAPTCHA Score Threshold setting as necessary to block automated submissions. Note: reCAPTCHA v3 adds a new setting "reCAPTCHA Score Threshold" at Configuration > System Settings > General Settings > Security tab. For guidance setting this score, see: https://developers.google.com/recaptcha/docs/v3#interpreting_the_score https://developers.google.com/recaptcha/docs/v3#interpreting_the_score https://developers.google.com/recaptcha/docs/v3#interpreting_the_score2 points -
It would be trivial for WHMCS to remove this or add an option for us to do so. It's been 4 months now without a solution. I think the question of how much they actually care about their client base has been firmly answered.2 points
-
That really means nothing John. That feature request has been there over 1 year, and as everyone here knows, you guys only add features you want to add, not features the users want or need. There are many popular feature requests which still have not been implemented after 10 years.2 points
-
@snake @sahostking After applying the reCAPTCHA v3 hotfix for v8.10, make sure to generate new reCAPTCHA v3 keys on the Google reCAPTCHA site, and enter these into WHMCS. Old v2/invisible keys won't be effective when used with v3. Then set the new reCAPTCHA Score Threshold setting (Configuration > System Settings > General Settings > Security tab). Google suggest a starting score of 0.5. Submissions will start to be recorded on the Google reCAPTCHA site, alongside a score for each threshold. Use this information to adjust the reCAPTCHA Score Threshold setting as necessary to block automated submissions.2 points
-
100% fact. That's the sad reality of a once small company full of passion to a company with shareholder interests and no passion. They are milking it dry.2 points
-
it seems problems like this could be mostly avoided if the email verification actually worked. currently it does nothing, most customers just ignore it. new customers should be INACTIVE until they have verified their email address, and if they do not verify within x days, then the account gets auto deleted. Being inactive until verified would also solve the issue with WHMCS auto increasing your licence fee for fraudulent registrations as well.2 points
-
HI @Remitur We are aware of reports of unusual orders being placed, potentially in an automated way and are tracking this internally. There are some immediate steps which you can take to help minimise the impact of automated orders : First of all, please make sure that "Allow Client Registration" is disabled at System Settings > General Settings > Other (tab) , as this provides an easy way for spammers to create accounts without needing to place an order. Secondly, please make sure that you have enabled "Invisible reCAPTCHA" under "Captcha Type" at System Settings > General Settings > Security (tab) . This is the most secure captcha that is currently integrated with WHMCS. Next, please make sure that you follow and implement all of the solutions provided in our documentation: https://docs.whmcs.com/orders/spam-orders/ Importantly, please make sure that you have implemented a Web Application Firewall and gone through the full configuration process. Whilst we don't recommend any particular provider, the following are some of the most popular: CloudFlare: https://www.cloudflare.com/ Amazon CloudFront: https://aws.amazon.com/cloudfront/ Incapulsa: https://www.incapsula.com/ KeyCDN: https://www.keycdn.com/ We are looking into whether these spam orders are being created by submitting a modified POST request to WHMCS. If that is the case, implementing a well-tuned WAF should mitigate much of the problem.2 points
-
A quick search shows they're assigned to sprious.com. One of the items offered there is "Scraping Robot Top-tier scraping paired with competitive pricing to help elevate your company" Just an FYI. I'd guess they used that to find potential victims and then took the results to attempt exploits. There are cheaper ways with a lot less "noise" and traceability, so they don't seem terribly "ready to exploit" to me. Could be wrong.2 points
-
While I agree, the fact itâs just started and has a pattern, Iâd say they know something new. If it was bad actors generally looking for exploits we would have seen it before now.2 points
-
A good portion of the IPs are from Emeigh Investments LLC. A quick search finds this: https://securityboulevard.com/2022/05/state-of-api-security-activity/ Basically as I'd mentioned, bad actors are checking the website programming looking for flaws to exploit. With WHMCS containing user info along with monetary info, it's a good target. Add to that the simple way to "Google Dork" the sites running it (powered by tagline, generally), not too hard to find potential victims. They find a way in, it's gold.2 points
-
If they know the email won't arrive, that's puzzling. I will say it's likely they're looking at the transaction in real time to see if anything's revealed there. Brings to mind the 2013 issue with AES encrypt spitting out admin details when a carefully crafted name change was used. Not saying it's that, but concerning it's similar.2 points
-
Here's a hook file that combines all of it, including hiding it in the admin: https://github.com/websavers/WHMCS-Hook-Sitejet-Deactivate2 points
-
I have now removed Sitejet with the following CSS elements: #sitejetPromoPanel{ display: none !important; } button[data-identifier=âsitejetâ], li[data-identifier=âsitejetâ]{ display:none !important; } button[data-identifier=âsitejetâ] + .btn-group > .btn[data-toggle=âdropdownâ]{ border-top-left-radius: 3.2px; border-bottom-left-radius: 3.2px; } button[data-identifier=âsitejetâ] + .btn-group > .btn[data-toggle=âdropdownâ], .btn-group:has(> button[data-identifier=âsitejetâ]) > .btn[data-toggle=âdropdownâ] { display: none !important; } additionally with this hook: <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPage', 1, function($vars) { $primarySidebar = Menu::primarySidebar(); if ($primarySidebar) { $serviceActions = $primarySidebar->getChild('Service Details Actions'); if ($serviceActions) { $serviceActions->removeChild('sitejet'); } } }); And dear WHMCS team, please add an option to deactivate this change for future changes.2 points
-
Hello, The tbllog_register table holds data on the actions taken by the daily cron tasks which are available in the admin area at Utilities > Automation Status. It is where the results of a cron task are stored. The daily cron email report aggregates its content from these rows. These are the actions taken by the daily cron tasks which are available in the admin area at Utilities > Automation Status. At present it is not possible to prune this log from within WHMCS. If you'd like to see this included I'd encourage you to add your vote or comments to https://requests.whmcs.com/idea/cleanup-tool-to-prune-tbllog_register-table Ideas with the most votes and activities are reviewed by our team. As of WHMCS 8.1 and above we have optimized the indexing for cron log data. https://docs.whmcs.com/Changelog:WHMCS_V8.1 CORE-14970 - Optimize indexing for cron log data In the meantime, if this is something that you would like to work with, you can do so with a SQL query. For example, the SQL query below will remove any entries in that table that predate 2023. You can modify this to suit your requirements. DELETE FROM `tbllog_register` WHERE created_at < "2023-01-01"; As always, please ensure you back up your database before performing any such direct actions on the WHMCS database.2 points
-
I am happy to say that the development cycle of vBLink 2.0 is now complete. The release was delayed for a complete ground-up rewrite after WHMCS 4 was announced. It is not ready for download just yet; I have not taken the time to create an installer or documentation because of two major issues that may become a factor in the long term success of vBLink. The first issue is vBulletin 4 support is not included. This is in part because of the fact that I do not agree with decision by vBulletin to change the licensing structure essentially us to purchase new licenses. I own three licenses, two for production sites, one for a development site. The cost to upgrade is going to be huge, especially if I choose the publishing suite. So at this point I have no access to vB4 code. The second issue is that from a business standpoint vBLink has not been a success, or at least the free/paid model that it has been distributed with. In the past year there have been over 400 downloads of vBLink but less than 2% were paid licenses making vB4 support hardly justifiable. So the question now is what to do next, and that is the reason that I am posting this message. Obviously, vBLink without vB4 support is only going to be useful for a short time until v4 goes gold. But without a solid community and financial backing behind it, I have no reason to continue development. But one promise I will make is that if I do walk away from vBLink, I will release all source code into the public domain; I do not believe in holding code hostage. If I do in fact release vBLink 2.0, I'm thinking of a 3-tier release structure... vBLink Basic (Free, Fully Encoded with only account bridging and no extras) vBLink Pro (Mid-range cost, a few admin module source files encoded, fully functional) vBLink Pro Dev (Highest cost, fully functional with full source) All feedback is welcome and will help determine the future of this vBulletin integration.2 points
