Jump to content

websavers

Member
  • Content Count

    267
  • Joined

  • Last visited

  • Days Won

    2

websavers last won the day on December 14 2021

websavers had the most liked content!

Community Reputation

8 Neutral

About websavers

  • Rank
    Level 2 Member

Recent Profile Visitors

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

  1. In the WHMCS admin, when viewing any particular client's product, there are three possible URI's / request vars used depending on what link you clicked to reach the page: 1. /whmcs/admin/clientsservices.php?userid=UID&id=PID 2. /whmcs/admin/clientsservices.php?userid=UID&productselect=PID 3. /whmcs/admin/clientsservices.php?userid=UID Which is a problem if you're developing modules using hooks that don't supply you with the product ID through a hook function parameter -- particularly the last one where we can't even *try* to derive the product ID from a REQUEST var. And so I submit this as a bug with the (pretty simple) solution being to make that consistent and always have one productid parameter, I don't care of its "id" or "productid" or "serviceid" but make it consistent. I also told them all steps necessary to reach those varying URL structures.
  2. I'm sure anyone who has tried to submit a bug to WHMCS can relate. I feel like it's truly a bug about as often as it's never lupis on House.
  3. More than a few times, I've found myself scrolling through a ticket to find an attachment, or trying to guess at filenames with a on-page text search. To avoid this hassle, I've created the hook at the following repo, free for all to use and contribute to. It provides a list of all ticket attachments in the ticket sidebar with the following capabilities: Click the attachment filename to download it Click the small message bubble to jump directly to the message it was attached to (handy for message context) It's super basic, but could be handy for more than just me! Enjoy 🙂 https://github.com/websavers/WHMCS-Ticket-Attachments-List
  4. Updated in fork to fix the 'view message' pop-up no longer being a new window, and is now a modal: https://github.com/websavers/whmcsEmailImportHook?organization=websavers&organization=websavers
  5. When upgrading to 8.3 from 8.2.x, if you have customized templates and are using the Plesk module, you'll suddenly find the $moduleoutput variable outputs nothing at all. This is because the Plesk module has been updated to not use $moduleoutput to output HTML for the login button. The login action is now entirely part of the dynamically generated module actions menu. Similarly login actions with deep links within Plesk's panel (ex: to file manager, email accounts) are *only* part of the automatic/uneditable (in the template) $tplOverviewTabOutput variable. For whatever reason this wasn't described anywhere (such as in the deprecation and removal notices) as a clear change that template developers should pay attention to. FWIW, I'm not complaining about the changes, just that they weren't detailed as a major change to how module output is shown on the product details template.
  6. I'd also like to add one additional request on this topic: that the WHMCS Client Area front-end *not* be brought down should there be licensing server problems. In other words, I think it's more than reasonable to only do license checks when accessing the WHMCS admin area. This way even if we're experiencing problems with WHMCS, it doesn't affect customers -- only admins.
  7. They did address them in tickets to those users. The gist is that the license cache would normally work great to prevent WHMCS outages when their license servers are down, however the cache is erased any time a WHMCS instance is accessed using a different URL, which could include an alternate domain, or an IP address if your web server is configured to access the WHMCS instance by IP. (Note that it doesn't need to be an actual admin of your WHMCS install accessing it via the alternate domain or IP -- it could just be bots pinging the site using that incorrect URL that cause the license cache to be erased, and so the actual WHMCS admin would never know its happening). And so John's list above is a list of possible solutions to prevent the URL being used to check in with the licensing server from changing, thus ensuring the integrity of the license cache.
  8. Hey John, this seems mostly reasonable to me, however I would say that in terms of the system URL redirect, many web apps do this, like WordPress. You simply add documentation indicating how to change the URL after a relocation. You could even supply a PHP CLI script to help make it happen. If this is reasonable for other web apps, I see no reason it's not reasonable for WHMCS. As for your selected solution: would that alert show to all admins no matter which URL they've logged in with, and only after someone (but not necessarily that admin) has attempted to access WHMCS from a URL other than the system URL? The reason I'm asking is that whomever logs in using the wrong URL (domain/IP) may not be the one who needs to see the alert to correct it. Further the WHMCS instance may be accessed by someone not even logging in at all, which apparently clears that license cache as well.
  9. I seem to be able to connect to all but g.licensing.whmcs.com without any troubles.
  10. Alrighty so obviously it's not great that the licensing servers went down, though service outages are ultimately expected at some point or another; it happens to everyone. There's plenty of options for how to handle paid software and WHMCS has chosen an option that requires that we use their licensing system to ensure the software works. We don't explicitly want to have to license the software purely to keep it alive: but that's what WHMCS requires of us. (As a comparison, think of GPL software, like most of the WordPress ecosystem. We pay for licenses to get updates, not to be able to continue using the software at all). And so, since this is WHMCS's requirement (and not one we specifically *want*), the bare minimum they could do for us is ensure that their licensing system works flawlessly. Clearly this incident brought into question two key issues: That their servers weren't able to handle the problem gracefully despite seemingly having multiple fallback licensing servers (though again, I'm not overly annoyed about this part), and That the software does not handle things in an acceptable manner when the licensing servers are not available In my opinion that second issue is the true problem here. As WHMCS staff have stated both in tickets and I believe here in this thread, WHMCS *is* programmed to keep a license cache and keep the software going in the event of licensing server failures. However the bug that created all of these issues is that the license cache only works if the domain for which you access WHMCS remains 100% consistent. So if you access WHMCS (or bots do) occasionally through an alternate URL, or the server's IP address, that triggers a clearing of the license cache, forcing WHMCS to check in with the licensing servers again. In our case, it was IP address access that was clearing the license cache. In another user's case further back in this thread, it was slight variations on their domain -- seemingly a domain alias that didn't 301 to the primary TLD. This meant a simple fix to prevent the license cache clearing going forward: no longer allow access from the server's IP. However the reality is since this is WHMCS's software and WHMCS's licensing system and servers, it's up to WHMCS to ensure that this bug is fixed in the software and not something end-users have to deal with. I have suggested that they simply add some code that runs prior to any licensing checks that ensures WHMCS redirects to the System URL configured in WHMCS, therefore making all license checks occur against the correct URL. WHMCS staff have indicated the following in response: If you also believe this should be fixed in the WHMCS code and that it's not something we should be required to repair for WHMCS (even though we *can* do so, and have done so), please like this post and let them know in a support ticket that you'd like to have a pre-license-check redirect added to their codebase.
  11. Yep, def do that, and if you still have our suggested workaround above in place, make sure to remove it from /etc/hosts (or comment it out) as that'll continue to get you errors, though I believe you'd be getting a different error from the HOSTS override. Haha, tried that with other support requests in the past... they just ignore it like you never asked!
  12. The issue with their licensing servers is now fixed indeed. Meanwhile their support staff have told me that the reason this was a problem for us in particular is because our system is checking for licensing more frequently than it should be. They then suggested I check my PHP environment to ensure it's working properly... yet *all* of this code that controls the frequency of their licensing checks is within their encoded PHP that I have no access to. Can't say I'm surprised that even during a systemwide licensing server outage they're happy to put at least partial blame on their customers for something that clearly has to be a problem with their own code.
  13. Don't go near the license check button (if it exists?) and with any luck they'll have their servers fixed before you ever see a problem.
  14. Please don't tell me that having working licensing servers should be a feature request? 🤭
  15. Their servers appear to be down. To bring back our WHMCS system, we had to add this to /etc/hosts: 127.0.0.1 f.licensing.whmcs.com a.licensing.whmcs.com b.licensing.whmcs.com c.licensing.whmcs.com d.licensing.whmcs.com e.licensing.whmcs.com g.licensing.whmcs.com h.licensing.whmcs.com But admin is still down of course because now it just says our license is invalid. But at least the front-end is up. Including this here for anyone else experiencing licensing issues. Note that not everyone will because the software doesn't always check in with the licensing server. Don't trigger it manually today, whatever you do!
×
×
  • 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