Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 11/05/20 in Posts

  1. 3 points
    I dont think this a bug the themes designer peoples need to edit the themes.yaml Example: # Themes Name Configuration File name: "Company Theme" description: "The Official Theme for Company" author: "Joe" properties: serverSidePagination: false # Defines client side will handle pagination
  2. 2 points
    I know plenty of enterprise systems, far better in security than WHMCS. All of them (admin back end) lets you force a user password change. What purposes does a back end have if you cannot manipulate data...???? From a security standpoint removing this has NO, ZERO effect on the account's security. Forcing a user's password is still hashed, it's not saved in clear text. No risk involved. If WHMCS assumption is here "We don't want, you to know YOUR customers password" this is idiotic. It's my customer, not theirs. As you said, you can just use a dummy email account and still know the password, they now just add another layer of complication to the equation. Also, we already have full access to the database, I can manually change whatever password I want and still know my customers passwords because it's my data. And without mentioning that, well WE DON'T need the customers password in the first place as we can just impersonate the account. We don't care about the user's password. And finally, you can make a hook that does the same. What is the purpose of WHMCS removing this besides making it more complex and killing an especially useful feature in the back end? The only thing that comes to my mind is they don't want your staff to randomly change users' passwords. If this is the WHY they did this, it's a dumb approach. They should just add a permission and problem solved. That way we as admins can set specific staff users not to have the option to change a password or impersonate a user. Therefore permissions exist and you can give or remove specific permissions to your staff. Now completely removing the function is just going nuclear and making the whole admin side less useful. It makes no sense. Forcing a user's password change is one of the most, if not the most common tasks someone will look on a user's account. It seems WHMCS thinks that everyone using WHMCS just has random users online from a website. Don't they understand that some of us know our customers in person? And they are in front of us and we need to tell them now "Sorry, our fancy billing system does not let us change your password manually" This is seriously a joke. An admin software that does not let you change user's password. Then again, I'm not surprised because in v8 it seems you cannot remove users either. People are complaining about this because they either did not upgraded yet or are not even aware something this BASIC was removed from the customer profile. The devil in me tells me something different. I suspect why they are removing things like that. WHMCS is trying to slowly kill the self-hosted edition of WHMCS and move it to a cloud service. Then it makes no sense to offer things like this because you don't have access to the database. Their whole final idea is lock in. The self-hosted edition will be killed, and you will have to pay them monthly to use WHMCS and store your database with them. And your data and customers is now theirs. And eventually they will even email your customers directly and try to sell them things directly and claim it was a mistake. I saw this so many times. This is speculation but this is the only reason I can think why they don't added features like removing sub accounts in v8 or why they remove the password change feature. If someone takes a deep look at what they are adding in terms of features and removing, it all points to a version that will be cloud only and self-hosted killed. This is why they are slowly locking things down more and more and removing things that only makes sense on a self-hosted server edition. WHMCS will claim otherwise but just see each release and what brings and what it removes, and all things start to make sense. I suspect our future with WHMCS is already compromised. I refuse to believe they are doing this things by mistake because nobody would think removing something like this makes any sense at all or not adding a way to remove sub contacts in v8. The reason is they don't need customers to remove things. In their cloud service they will bill per users and customers and they will remove them from their back end. They don't want you to manipulate the database because it will be billed from their side. They already are moving towards that, owned license cannot be purchased anymore. Only leased. Then they introduced it billing by number of customers (your WHMCS now transfers that data) and they already confirmed here in the community that they plan a cloud hosted edition. Eventually they will move towards that and bill for everything, based on the number of customers, products, etc. Maybe even a % of your income in the future. This is why the marketplace makes so much sense for them. Of course they will lose most customers that cannot host billing & users data with them for compliance and regulatory reasons. But I suspect they don't care. Lucky for us, there are alternatives. I'm very disappointed with how the future looks with WHMCS because there is none for us that host it with our own servers. Granted, this is all speculation but the changes they are doing since version 6 are pointing towards that. Its all about vendor lock in.
  3. 2 points
    Hi all, We opened case CORE-15572 as a result of these reports, and are planning to make sure the Client Group colour is displayed to correspond for the ticket owner. This is scheduled to be included in v8.1. Thank you for the reports!
  4. 2 points
    really ?? you must have a different definition of the word "mistake" than most... i'd have said the opposite, but maybe i'm more suspicious / less naive of their motives than you... hey ho.
  5. 2 points
    I think it's safe to say that, barring any emergency issues (and they wouldn't see this as one by the looks of it), there won't be a v8.0.5 release... therefore, their focus will turn to v8.1 - from past experience, I wouldn't expect to see a beta for that this year... unless they go down the silly road again of releasing a beta one week before Christmas and then later complain that no one is testing it. ๐Ÿ™„ if v8.1 doesn't go to beta until the New Year, then I doubt it would go GA before Easter 2021 - especially as there are scheduled to be a Bootstrap 4 upgrade, a new client area theme (let's call it "Eight" lol) and cart template updates due to be included - so it might not even be considered "stable" (by their definition) until months after that. therefore, it would be good to know definitively, long before then, whether WHMCS see this as an issue they're going to address themselves in v8.1 - ideally both user management and their password management - because if they're not, others can start making alternate solutions... but others likely wouldn't want to waste time going down that road if WHMCS are going to address this themselves (which would be the preferable solution and should really have been in place before v8 when GA). I think a simplistic hook that just deleted the equivalent user when a client is deleted is potentially very dangerous - primarily because in v8, client/account does not necessarily equal user... e.g a user might be linked to more that one client/account, and so auto deleting the user when you delete one of those clients, could cause issues for those remaining clients... so that potentially means warning the admin that a user might be associated with other accounts before they confirm for the deletion to continue. as Dennis so rightly says, "you just got to account for a lot of things" - the deeper you delve looking at this, the more checks you find that you would need to perform before deleting anything from the database... and one would hope that WHMCS internal developers would understand that relationship better than the rest of us. as i've outlined, a permanent solution from WHMCS would likely be months away at best - so as long as you know in your case that there is an account = user relationship, then just removing the appropriate row from the tblusers database table will remove that user.... I suppose for completion/tidiness, the relationship should be removed between client/user in tblusers_clients table too - though that's probably not essential... and remember to backup the table(s) before you make changes to them.
  6. 2 points
    I'll have to stop you right there, John. The same thing goes for regular clients. In theory, you could just change their details. It's just a hell lot easier to delete everything than to have hundreds of inactive users (all with unique email addresses). ... And so can a client. But - if the client wants their account deleted, we should (and must) delete it. If a user (not a client) actually decides to contact us and asks us to have their account removed, why shouldn't we be able to delete it? Sorry, but I just can't wrap my head around why a 'Delete User' button and/or API function has been made. Reasoning? We're forced to delete data about a client if the client requests it. Not doing so is punishable with huge fines. In 2018, WHMCS made a lot of steps to make it look like they cared about GDPR - and then they basically ruined it with a single update and can't understand why we feel something is wrong. Please, please, please, please (!!!!!) let us know why it has now taken 3 releases (I reported it before GA) and there's still no solution to this. It's really just a matter of deleting the user the same way that a client is deleted. Sorry about my tone in this reply, my it really frustrates me. You can't make a release that is so GDPR focused back in 2018 and then ruin it two years later saying: "You know, you can just manually edit out the personal information for each user" - WE COULD VERY WELL DO THAT WITH CLIENTS AS WELL BEFORE 2018, It's just a lot easier NOT having to do that.
  7. 1 point
    Hey Guys, sorry for my late reply. No idea why - no notification reached me. Spam folder maybe? Anyways, thanks Remitur for that IMPORTANT feedback. That's why I can just again and again point out: Report Issues and Feature Request to us (support ticket the best). We are gathering YOUR ideas and we will work on them. Noted down. The Drop-Catching module will need a revamp anyways in 2021 I guess. UTC timezone as basic configuration requirement is probably the biggest blocker for customers. We'll find a solution for this. Thanks Kai
  8. 1 point
    As long as they maintain an up to date version of PHP and MySQL, there shouldn't be any issue. They don't have to "support" WHMCS. That's what the company (WHMCS ltd) is for. If they don't maintain up to date versions of PHP and MySQL, then run away... quickly
  9. 1 point
    I agree this functionality was so convenient! Why remove it!!
  10. 1 point
    well going forward, you might want to stop selling Weebly as a service, and only as an product addon - that would prevent this from occurring again for new purchases. for an existing user in this situation, you might want to open a ticket with Support - they might have an internal script to move a service to an addon.
  11. 1 point
    Would you believe me if i told you even if you mentioned my username i still wouldn't remember it. Not Hans though for sure, he runs https://infinityfree.net/ changed name from grendelhosting. You two are probably the only successfull free hosting providers that have came so far! Congratz mate.
  12. 1 point
    if this is going to be on a custom page, then you're probably looking at creating 3 parts to the solution. a custom .php page that will include your SQL query and return it to the template as a Smarty array - https://developers.whmcs.com/advanced/creating-pages/ a custom .tpl template based on clientareainvoices or clientareaproducts - frankly, I don't think it will matter which dt template you choose as a starting point, they're all very similar... you should just need to change the tablename references; specifiy if certain columns can't be sorted or filtered; adjust the table headings & variable names to your return SQL query array (or vice versa if you're feeling lazy!). a custom sidebar hook to generate the filter - i'm not aware of any such hook code ever being published here or elsewhere - it's an absolute pain to do, so worry about 1 & 2 first and then cross the filter bridge when you have your output and know what you want to filter on... in any event, it's likely going to need to use a similar query as (1) to generate the statuses or whatever it's going to be filtering on. search and pagination features will be automatically available unless disabled, so I wouldn't worry about that either. I wouldn't worry about tablelist, it's highly unlikely that you would ever need to edit it - it's just a sub-template used by clientareainvoices etc to output an array in a sortable, filterable table. really, all you should need to do is get the array generated by the query into an order that the custom template can output - e.g fields of the array are referenced correctly by the template code. if it helps to start off with, put a {debug} in clientareainvoices and then examine how the $invoices array is being outputted by the template. technically, these are DataTables that WHMCS is using and their documentation can be found at https://datatables.net/examples/index - however, WHMCS seems to call it in a slightly kinky way and therefore a word of advice - don't go to their docs, think that you can use x, y or z exciting feature and then try to incorporate them into WHMCS - you'll likely end up with errors! certainly to start off with, you shouldn't even need to view the docs as you're not reinventing the wheel, just duplicating what WHMCS already does but with new content.
  13. 1 point
    I've worked with WHMCS for so many years that I always try to see if I can integrate it with my side projects. Last time I integrated it with a mining farm for altcoins. It was fun but now we're still selling a bunch of 1080ti ๐Ÿ˜… This time my weird idea is about selling physical product on marketplaces. There's a platform that is capable of selling any product on a wide variety of marketplaces like Amazon (UK, IT, FR, NL, MX...), eBay and many more. It imports catalogs from any warehouse / store and adjusts selling price based on the price of other sellers. For each products it "knows" quantity, size, weight, EAN/ASIN, it loads images, prepare SKUs, descriptions. It ships goods everywhere in the world using plenty of logistic networks (DHL, FedEx...), sends tracking codes and handles returns. The owner of the platform has its own wharehouses, logistic network, couriers and staff meaning that anyone can use it as a fulfillment center. I'm trying to see if there's a market in integrating it with WHMCS. Here's the idea. I bet there are tens of thousands of e-commerce websites hosted by WHMCS-based providers. Right now the only profit for a provider is selling them hosting, VPS, SSL certificates, dedicated IPs/SMTP, sitebuilders. What if providers can offer them the possibility to sell their products on Amazon, eBay etc. in a question of minutes? Providers get a percentage on each sale ๐Ÿ˜ฑ
  14. 1 point
    it is - i'm working on an addon module that converts the WHMCS staff into a PES team.... unfortunately, they have a habit of scoring own goals; passing it along the back four to play for time; ignoring comments from the paying crowd; group hugs for successfully completing a two-yard pass... and the manager has lost his voice. โšฝ it was a typo - I meant EPS (EmailPreSend). btw - I think it would be useful if the comments of your hooks at least list which releases it was tested on / written for... obviously, some are v8 only, but that might not necessarily be obvious to everyone downloading.
  15. 1 point
    That's not what I mean. WHMCS has the standard_cart, six, and twenty_one on GitHub. What about the other order forms that come stock? What about the "Blend" admin theme? Don't just add a select few. Add them all. It really helps theme developers out.
  16. 1 point
    Esoteric side point perhaps, but can we have the theme's JS and CSS split into their source versions on Github? Maybe even the SCSS/LESS source if that is how it's developed? At the moment we only get the combined production ready theme.css or invoice.css and the massive all.css and scripts.js files with combined third party css/js. https://requests.whmcs.com/topic/provide-source-css-and-js-for-client-side-templates-on-github
  17. 1 point
    If you check every other major release in the past 2 years the story was the same. They are quick to release new versions that hardly passed Beta. That should explain some of your questions. The trick is not to upgrade WHMCS when they release a new major version but wait for the smaller releases that keep fixing stuff.
  18. 1 point
    I understand what you are trying to achieve and you probably are like me a number freak. It does bother me for example when I closed fraud accounts that now I have a useless ID I wil never use again. But this is not only true for WHMCS. For example, lets say a bug tracker like Mantis, also creates a unique ID per each bug, even if they are on different projects. Since one bug is just one more record in a table and the ID is created by the database system not the software. The thing is that most developers use this setting (auto increment) because it creates a unique ID on the database automatically and you need this for data consistency as everything can and will change (like username, or name), in the end the number that never changes (and should) it what identifies a unique item. And while you might use this customer identification purposes or product (I do) you need to stop worrying about the number and consider like a trow away setting. Don't completely rely on them and instead try to query the number for each customer in case it has changed (from other systems...) If you really need to match this to the old system, the only solution I can give you is to create dummy accounts in between the users that don't match an ID. Then if you someday register an account manually use one of those positions that hold temp data. Or the other solution is not to use the ID's from WHMCS and like someone else suggested create your own custom field, you can then have a hook that calls this automatically on each new customer registered but now you are replicating what WHMCS does and you need to babysit a parallel number systems that does the same. It all depends on how many customers you have. The logic thing I would do in your case, is just to import the customers in order and then change the ID on my other system to match this. You need to think which one is the most important one and the master. If your new ID's will be assigned from now on forward's by WHMCS (like registering new customers) then the logic here tells you that it's your other system that should take the ID from WHMCS and not the other way around. It would be easier just to change the ID's in the other system and then start with the new numbering system on WHMCS. This is the cheap easy way instead of creating a hook or a new number format. It all of course depends on how many customers you have, but if you need to start hacking around WHMCS then why not just create a script that does the same in the other system? Just create a script or some other task that gets the new ID for each old customers in WHMCS and then updates it automatically in your other platform/software. It's a one time job, and once finished just start using the new ID's created by WHMCS. Do not change or try to tamper with the ID's in WHMCS because they are used in several queries and tables to get data, you will end up with many troubles and your installation will always have troubles afterwards. The unique ID is the primary key in the database and as such has to match with other tables for data consistency.
  19. 1 point
    Welcome Matthew. Hope to see you around !
  20. 1 point
    If you have WHMCS on a server that you have WHM access to, it's in tweak settings. Look under mail for "Track email origin via X-Source email headers" and shut it off. That should resolve it. Of course, it sounds like you have your billing system on a server where you have clients, which is typically a lot less secure...
  21. 1 point
    I don't think there is such a rate limiter built-in. A ticketopen hook might work to then add the email address to the block list. This would need to have a tracking mechanism to determine how fast they are opening tickets and cron hook to then unblock after x amount of time. Is the tickets being opened via email or the client area ? If via email, on your side make sure your SPF record is correct and set to reject non-listed sources via the "-all" instead of "~all" which is a soft fail. On the other side, they would of course need to be checking SPF but most spam systems do that. If via the client area, a clientarea hook could do tracking via $_SESSION and block via like a redirect or a header 403 maybe.
  22. 1 point
    original code from the thread below... <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPrimarySidebar', 1, function (MenuItem $primarySidebar) { GLOBAL $smarty; $templatefile = $smarty->getVariable('templatefile'); $client = Menu::context('client'); if (!is_null($client) && in_array($templatefile, array('clientareahome'))) { $SupportPIN = generatePinCode($_SESSION['uid'], 8); $primarySidebar->addChild('Support-Pin', array( 'label' => "Pin de Soporte", 'uri' => '#', 'order' => '10', 'icon' => 'fa-ticket' )); $primarySidebar->getChild('Support-Pin')->setBodyHtml($SupportPIN); } }); the second hook in the file would remain the same as that refers to the admin area.
  23. 1 point
    It is security but also programming standards as logic should be limited to controllers (and models) in the MVC programming style. So php should be left out of templates as templates are in the View context. It also helps to limit customizing template files. So with that said, it would be best to use a hook such as the ClientAreaFooterOutput , get the wordpress stuff as you describe within that hook's function, and then use javascript to move the output to where you want. For example: <?php add_hook('ClientAreaFooterOutput', 1, function($vars) { // Include the wp-load'er include('/public_html/wordpress/wp-load.php'); // Get the last 10 posts // Returns posts as arrays instead of get_posts' objects $recent_posts = wp_get_recent_posts(array( 'numberposts' => 10 )); // Do something with them $Text = "<ul id='wp-recent-posts>"; foreach($recent_posts as $post) { $Text .= '<li><a href="'. get_permalink($post['ID']). '">'. $post['post_title']. '</a></li>'; } $Text .= '</ul>'; $Text .= '$(document).ready(function() {$("#wp-recent-posts").prependTo("#wp-container") })'; return $Text; }); then just place in file called "hook_wp_recents.php" in whmcs install/includes/hooks . It will then display them on every page within the client area. You can limit which page, or at least template, it injects in to by checking $vars['filename']. Or checking the url ,etc. Updates to WHMCS should not break this and you don't have to redo the templates each time.
  24. 1 point
    If I understood correctly, you need two checkboxes. One for TOS and one for Privacy Policy. That's pretty common in EU. In Italy it is mandatory (I suppose you're italian). The thing is that WHMCS doesn't support multiple checkboxes but you can solve the problem with javascript. Edit the following files: templates/{YOUR_TEMPLATE}/clientregister.tpl templates/orderforms/{YOUR_CART}/checkout Add two dummy checkboxes (for TOS & Privacy) and make them required. Let's call them A and B. Then hide the checkbox of WHMCS. Let's call it C. Lastly, create a javascript that: Ticks C when A and C have been selected Unticks C when the above condition is false
  25. 1 point
    technically, you don't *need* to edit the template - you can use a hook to change the URL in that link. you should just need to change 'a.logo' to 'a.btn-warning'; the URL you are linking to (and optionally whether it opens in a new window or not) and limit the hook to only work on the domain registration page. <?php # Change Hosting URL Hook # Written by brian! function change_hosting_url_hook($vars) { if ($vars['templatefile'] == 'domainregister') { return "<script> $(function(){ $('a.btn-warning').attr({href:'https://www.google.com',target:'_blank'}); }); </script>"; } } add_hook("ClientAreaFooterOutput", 1, "change_hosting_url_hook"); there is only one button of that class on the page, so that simplifies the coding - if there were more, then more specific identification of the particular link would be needed... or WHMCS could just start adding unique IDs to all their links! ๐Ÿ™„
  26. 1 point
    didn't it take them years (decade?) to add an image upload option to kb articles... and now you want to browse them! ๐Ÿ™‚ if all the images were in the same folder, I suppose you could use SmartFTP to view the thumbnails and then drag/drop them to WHMCS where appropriate.... but I wouldn't hold your breath waiting for WHMCS to add the option.
  27. 1 point
    by changing one line in the configureproductdomain.tpl template... <option value="{$listtld}"{if $listtld eq $tld} selected="selected"{/if}>{$listtld}</option> to... <option value="{$listtld}"{if $listtld eq $tld} selected="selected"{/if}>{$listtld|ltrim:'.'}</option> it shouldn't have any impact on the order process as you're just changing the label rather than the value being passed through the forms.
  28. 1 point
  29. 1 point
    Hi I have updated the hook here is the code if(!defined("WHMCS")) die("This file cannot be accessed directly"); use WHMCS\User\Client; use WHMCS\User\User; add_hook('ClientDelete', 855412, function($vars) { $clientid = $vars['userid']; $userid = Client::find($clientid)->owner()->id; if($userid) { if(User::where('id', $userid)->delete()) { logActivity('User Deleted - ID: '.$userid, 0); } } }); deleteClientUser.zip
  30. 1 point
    Frankly, there are equally compelling issues on both sides here. As an admin user, YES, of course everyone for various reasons would like to see the password-related emails in the client email log/listing. Helps for customer service to see/know when/how/if that email was sent, etc As any responsible IT manager, YES, it is completely unacceptable to expose a user password in plain text in logs etc. Against best practice as noted by WHMCS, and just a bad idea. Could we possibly all aim for a compromise? How about: Simply mask the password immediately after it is sent and prior to logging. Admins would only see "*****" in the email log. Workable?
  31. 1 point
    @Wouter0100 you taught me something new! Can you encode values in the addons table as well and have it automatically unencrypt? I really like that and it would be neat if it could! I'm glad I learned something new. Thank you!
  32. 1 point
    Hello @Gitex, Let's address this in two parts: Do you mean decrypt? I'd suppose if you want to ENCRYPT you could use md5, but then you'd need to decrypt in PHP. WHMCS uses encryption already, so to decrypt what they have, you'd need something like this: function gateway_capture($params) { require_once ROOTDIR . '/includes/gatewayfunctions.php'; $GatewayConfig = getGatewayVariables('gatewayName'); $testM = $GatewayConfig["testMode"]; } What this does is grabs the parameters that are encoded. As such, I've given you a start. From here, you'd need tokens, client info, etc, which are used as parameters. I'd look up the documentation if you need more guidance. You would replace gateway and gatewayName to the actual name of your gateway. What type of addons are you trying to use? As I mentioned above, if it's the gateway portion, you'll need to use the excerpt above. I use the Licensing addon for my payment gateway, and it works flawlessly with Version 8. We are solving something internal with conversion, but using the Params portion will make your gateway work with version 8. At first, we were using straight laravel, but even the SDK says use $params.
  33. 1 point
    I seem to recall them switching to a sort of subscription model, where paying x monthly/annually allows access to a certain number of modules.
  34. 1 point
    Ah! That's true. Updated. Now it should work also for flagged tickets.
  35. 1 point
    even if the first beta was released tomorrow, it definitely won't go GA in 2020.
  36. 1 point
    This script here should work.
  37. 1 point
    I think you have Monthly Pricing Breakdown enabled... https://docs.whmcs.com/Ordering_Tab#Monthly_Pricing_Breakdown and it shows the same price because monthly is $3, quarterly is $12 ($3 per month) etc - your other cycle pricing is just multiples of the monthly pricing, and so when MPB is enabled, they all appear to be the monthly price.
  38. 1 point
    Hello - I have a logo and would like to hire someone with WHMCS web design experience to create a theme for my WHMCS portal. If you have experience with this, please feel free to reply here or reach out to me at webdesign@amdvps.com.
  39. 1 point
    I couldn't think of an existing solution - commercial or otherwise.... possibly one of Kian's hooks could have been expanded to cover this, but it doesn't work in v8 anyway even before you could think about expanding it. ๐Ÿ™„ all you should need is a domain validation hook that checks the domain entered when used with specific products... <?php # Prevent Domain Re-Use with Trial Products Hook # Written by brian! use WHMCS\Database\Capsule; add_hook('ShoppingCartValidateDomain', 1, function($vars) { $pid = $_SESSION["cart"]["domainoptionspid"]; $trialproducts = array(44); $domain = $vars['sld'].$vars['tld']; $domaincheck = Capsule::table('tblhosting')->where('packageid',$pid)->where('domain',$domain)->count(); if(in_array($pid,$trialproducts) && $domaincheck > 0) { return 'You cannot use this trial service with '.$domain; } }); so in the above hook, $trialproducts should contain a list of your trial product IDs and then the hook checks if there is a record in the hosting database for that product AND domain... if yes, then it throws an error message and prevents the ordering continuing. as written, it's only going to check for the current PID in the database, .e.g let's say you had 2 trial products (44 & 45) and someone had previously used domain.com with PID#44... the hook would prevent them using the domain again with #44, but wouldn't stop them using it with #45.... now you may or may not want that to happen if you don't, e.g you want to prevent a domain being re-used after it's been used on ANY listed trial service, then that's just a tweak to the query changing the first where condition to a wherein. $domaincheck = Capsule::table('tblhosting')->whereIn('packageid',$trialproducts)->where('domain',$domain)->count(); the error message thrown could use a language string if you prefer to ensure that it's shown in the user's language.
  40. 1 point
    Have version update for whmcs 8 1.30 Compatible with WHMCS v8.0 Link download https://downloads.tawk.to/plugins/whmcs/whmcs_tawk_to_1_3.zip https://marketplace.whmcs.com/product/3134-tawkto-live-chat
  41. 1 point
    The worst thing is that if this information becomes public (WHMCS is not anymore natively GDPR compliant), How many hosts are now in danger because of this update? how many hosts are working with WHMCS? 70% I think. Among them, how many have installed version 8? If the organization in charge of enforcing the GDPR wants to have fun and especially to collect some money for christmas, they have something to work with... WHMCS has only two solutions: Either they publish a patch as soon as possible. Or there is something preventing them from doing so, in which case they must offer to disable this new feature (user management), or perhaps even a pure rollback. But I have the feeling that they don't care at all...
  42. 1 point
    Hello. Here I'm, answering to this quite-old message, just to answer a question (and give you a suggest) about your domain backorder module. I tried it time ago (how much time? More than one year, I guess...) I tried it, was quite satisfied but, despite this, I gave up and canceled it. Why? Because created in mysql a HUGE table (between 1 and 2 GB, as I remember...). And it did in the very same main db of WHMCS, and this bring to a number of issues (the main and first important: backup, done every 6 hours, required much more time to complete, and also the daily backup, done using WHMCS function for db backup, stopped working because the db was too big). So, if in the meanwhile you have not yet fixed this issue (and, if it's so: sorry, I beg your pardon and go on testing the new version of your module...), I suggest you a fix: allow to configure the module in order to use another db, different from the main WHMCS db. So, using a different db, the main WHMCS db stays "clean" and there're no issues about backup. Even more: the user can set up a different kind backup for your module, with different policy and different timing ... Just my two cents: thank you for your time and attention.
  43. 1 point
    Fixed, I just removed the files from: /cpanelExtended/
  44. 1 point
    Hello everyone, Exactly I came here for a solution to remove users but no luck, What kind of logic is behind it to not deleting users????!! I can delete them from DB but why WHMCS does not put delete button in managment area?????? Oh man this is so bad so bad ๐Ÿ˜ž
  45. 1 point
    Agree also! Definitely one of the most looked at parts of my WHMCS. Unless you are on the Dashboard (which we are usually not) there is now no way to see if there has been a ticket reply or if an order needs to be processed ๐Ÿ˜• I'd like to see a notification of some sort for both in the header and the sidebar in the next release asap.
  46. 1 point
    This is correct. @WHMCS John Would request to add this section in some form, perhaps as notification icons or dropdowns if space is an issue ?
  47. 1 point
    out of the box, there will at least a couple commercial third-party solutions... WordPress Manager For WHMCS IBG App Installer - All-in-One (AiO) both would be $100 per year, so check out reviews (where available) and use a trial version on a development install before committing to purchasing (if possible). for free solutions, you could take a look at the Softaculous WHMCS Auto Install Module - though that would likely require more manual configuration on your side than using the commercial options.
  48. 1 point
  49. 1 point
    I've expanded this hook a bit to also cover failed transfers and log everything it does to the activity log. <?php use WHMCS\Database\Capsule; add_hook('DomainTransferCompleted', 1, function($vars) { //This hook will complete to-do items for transfers when the transfer is completed. $toDoID = Capsule::table('tbltodolist') ->where('status', 'In Progress') ->where('title', 'Domain Pending Transfer') ->where('description', 'LIKE', '% ' . $vars['domain'] . '%') ->get(); //Loop through the ID's and set them as completed. foreach ($toDoID as $entry) { $command = 'UpdateToDoItem'; $postData = array( 'itemid' => $entry->id, 'adminid' => '1', //Update this ID to an admin ID 'status' => 'Completed', ); localAPI($command, $postData); logActivity('Clean-up To-do List: ID ' . $entry->id . ' has been set as complete as the transfer completed successfully - Domain ID: ' . $vars['domainid'] . ' - Domain: ' . $vars['domain']); } }); add_hook('DomainTransferFailed', 1, function($vars) { //This hook will update to-do items for ttransfer that fails. $toDoID = Capsule::table('tbltodolist') ->where('status', 'In Progress') ->where('title', 'Domain Pending Transfer') ->where('description', 'LIKE', '% ' . $vars['domain'] . '%') ->get(); foreach ($toDoID as $entry) { $description = Capsule::table('tbltodolist') ->where('id', $entry->id) ->value('description'); $command = 'UpdateToDoItem'; $postData = array( 'itemid' => $entry->id, 'adminid' => '1', //Update this ID to an admin ID 'status' => 'Incomplete', 'description' => '*FAILED* '.$description, ); localAPI($command, $postData); logActivity('Clean-up To-do List: ID ' . $entry->id . ' has been set as incomplete as the transfer has failed - Domain ID: ' . $vars['domainid'] . ' - Domain: ' . $vars['domain']); } });
  50. 1 point
    pick it up from the front desk before you leave...
×
×
  • 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