Jump to content

Troy

Members
  • Content count

    507
  • Joined

  • Last visited

  • Days Won

    1

Troy last won the day on February 9 2015

Troy had the most liked content!

Community Reputation

2 Neutral

About Troy

  • Rank
    Member

Recent Profile Visitors

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

  1. Troy

    Password Strength

    The issue is clients wanting to change their passwords. WHMCS says their password is strong but then cPanel disallows it. Maybe the password strength in the WHMCS settings are for system-generated passwords only? Still it doesn’t seem wise to show the user they are using a good secure password only to then inform them of a failure when they submit it.
  2. Troy

    Password Strength

    Something as simple as MuFFin123# passes the WHMCS check set at 100, but fails cPanel set at 80.
  3. Since WHMCS is owned by cPanel can't you guys use the same algorithm for password strength? I have 90 set as a value in General Settings -> Minimum User Password Strength and 80 set for password strength in cPanel, and STILL there are passwords that will get through the WHMCS check but be rejected by cPanel. It's driving users (and me) crazy! I'm going to push the WHMCS setting up to 95 or maybe 100, but with the same ownership of both products you would think matching values on both sides would do the trick.
  4. Worked perfectly! Thanks again for the great suggestion Brian!
  5. Awesome idea, thanks! I hadn’t thought of using a hook. Kinda dumb of me since I did use a hook to change the destination of the whmcs home menu item. I’ll give this a try and report back.
  6. I recently upgraded to WHMCS 7.4.2, from (believe it or not) 5.3.14. Looks like URLs are handled a bit differently, and I'm having trouble with a rewrite I need to do. Basically I want to suppress WHMCS's index.php. I've decided to keep everything in the root, marketing pages that are html and WHMCS php files. There are no collisions and everything is working fine except that I don't ever want people using the WHMCS home page--I want it to redirect to the html homepage. (Client area links outside of WHMCS will all link to clientarea.php and force login if not already logged in.) Problem is, it appears that URLs now route through index.php to an extent. I definitely want to retain full friendly URLs. However, if a request comes in for just the home page index.php, I want it to redirect to index.html. Anything I've tried that actually redirects index.php if it has no query string variables will also redirect the knowledgebase, which I don't want to happen. So far it seems like only the knowledgebase is affected. Has anyone accomplished something similar and could pass along any pointers. I've tried some many rewrite rule variations but can't seem to get it working properly.
  7. I wouldn't see why not. If you are manually migrating data--try to do it in the order in which invoices are coming due in your previous system and if you can stay on top of that you'll perhaps be able to continue migrating while using WHMCS for new orders, and not have to process payments in the old system even though you're not fully migrated yet.
  8. Maxmind doesn't interfere with Stripe transactions--it simply calculates the potential for fraud and then *prevents* the system from completing and charging the order, so if the order was tagged as fraud, there was probably no transaction attempt at that time. If you have since input the correct card information, and are attempting to capture the funds from the invoice view in the WHMCS admin, Maxmind has nothing to do with that process. If you are getting declined--either the card info is bad, the card issuer has decided to not process transactions from you for whatever security reason, or you have one of the Decline options in the Stripe settings enabled and it's failing that. Or the card has insufficient remaining balance for the charge. Those are about the only reasons you should have problems making a charge--and there isn't anything in the database to be flushed or changed that will fix it.
  9. In your Stripe dashboard, if you click your company name in the upper right and choose Account Settings, there are two decline options at the bottom of the window for declining charges that fail CVC or zip code checks. Do you have either enabled?
  10. I just recently happened to notice that the autorelease module (used for services which don't have a provisioning module) now has options to open a support ticket to notify admins of actions needed such as create/suspend/unsuspend/terminate. We handle some services via autorelease so I set them to open a ticket upon suspension, unsuspension and termination. Problem is no tickets ever get opened. I've had services suspended and terminated since making this change with no tickets at all. Has anyone managed to get this working? If so, any tips?
  11. This is outstanding! Really makes mobile use a LOT easier. I'm still on 5.3.10 but installed it anyway. There are a couple spots where the content busts through the right side, (but only on certain devices), but I'll update to 5.3.11 and re-check and then leave info about them in your ticket system, unless you'd prefer it here. This interface is so much more legible on small screens--really makes a huge difference! I love it.
  12. If you're using WHMCS, you can have a *much* more robust domain service than Enom by using ResellerClub and modules from ResellerClub-Mods.com. Who cares if the backend interface is clunky, so is Enom's in areas, and your clients won't ever see it. You'll have a much more robust domain offering combining ResellerClub + modules from ResellerClub-Mods.com versus the WHMCS enom module. If you ever have clients forget to renew a domain name for so long it goes into redemption, they'll probably appreciate paying < $100 to redeem it vs. Enom's $250 too.
  13. What I asked Enom for was a setting that a reseller could use to specify that when domain's in his account expire they don't get redirected to a porn landing page by Enom--not that they wouldn't get redirected at all, but that we could at least trust that our clients domains wouldn't be pointing to porn 24-72 hours after expiration (we don't register porn domains so it shouldn't have happened to begin with). They wouldn't do it, which was perfectly within their rights, so I moved to a new registrar. Pretty simple, huh?. If enom wanted to, for the sake of keeping my business and that of others who feel similarly, they most certainly could implement a preference for resellers to not have expired domain's point to porn. They don't *have* to do it, (and they didn't), but then neither do I *have* to continue doing business with them, (and I'm not.) See how simple that is? Again, why does it matter? Someone in this thread asked me to detail what I considered shady business practices by Enom, and I did. I still fail to understand why everyone needs to argue these points ad nauseum. I stated what I considered to be shady, and what I did about it, plain and simple.
  14. What do you mean by this? Enom definitely redirected the domain upon expiration, as they do with all of them. I had a lengthy ticket discussion with them about it and they acknowledged redirecting the domain to their (Enom's) porn landing page. This is done by keywords in the domain, per Enom themselves. The domain was still in the renewal grace period. And yes, Enom domains most certainly *do* get redirected pretty much as soon as they expire without renewal, with dns propagation time of course. Further, Enom would not provide any sort of way for our domains to not ever get redirected to their porn landing page. So, we moved to another registrar. Why does everyone keep arguing a point that I have never made? I've never said the domain shouldn't have been redirected. It was *where* it was redirected that I, and the client, found objectionable. We lost the client over it in fact. Neither the client nor I had a problem understanding that the domain had failed to be renewed and as such was repointed to a landing page. The destination page itself was the problem--first time any of our expired domains had ever been pointed directly to porn *by the registrar*. Still don't believe that Enom did the pointing to their own porn landing page? I'd be happy to show you the ticket. Here are a couple quotes from Enom directly from the ticket for good measure: In response to my request for a setting that would prevent this from happening again: and At any rate this was just a few bullet points in response to the question of what shady Enom business practices I had problems with. It wasn't meant to hijack the thread and devolve into an infinite loop of argumentation over a point that wasn't even contested.
  15. I'll grant you that wasn't my most professional comment ever. Still I cannot imagine many people would find it cool that Enom purposefully chose to redirect a children's ministry domain name to a porn landing page. Yes the client was dumb to allow the domain to expire, no question there.
×

Important Information

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