mburtis

Just wanted to come back and share what seemed to fix this issue for us, just in case it helps anyone else. In our case, we were automatically redirecting users to WHMCS using a dynamically-generated AutoAuth link. Since the redirect was happening at the same time the link was being generated, there was absolutely no way the link should be coming back as expired, but it was. Also, in our case, the link to WHMCS was happening on another server from where WHMCS runs, where we run our main project site. We had checked time/date settings on both servers to make sure they matched (and they did). However, we believe there was a slight (1 second?) difference causing the timestamp on the originating server to be slightly *ahead* of the server WHMCS runs on, and that this resulted in the "link expired" issue. It wasn't that the 15-minute timeframe had passed; rather, WHMCS detected that the timestamp represented a time in the future. We fixed it by subtracting 30 seconds from the timestamp before hashing it and creating the link, and, since doing that, we haven't see the issue again.

Did you ever determine what the cause of this was? We've been having a similar issue with the autoauth feature, and we can't track down the cause. . .

I know this is an older message, but I wonder if you (shalomc) would be willing to share some more info about how you set up the duzzit to do this. I've been experimenting with duzzit and whmcs' api, but I'm having trouble figuring out exactly how to build this within duzzit's system.

Thanks again, Brian. It's pretty clear from what you're saying that the cron isn't running properly on our site. When I search the Activity log for entries with "Cron" in them, I can see ones about invoices being created -- but nothing about client status. So it looks like cron.php is running and doing *some* of the automation, but not everything. I'm not sure how to troubleshoot this, either, given that cron.php is an encrypted file. . .

Thanks, Brian. I've looked at the automation setting documentation, and it seems to me that this cron is designed to change clients who are currently "Active" but who don't have any current products to "Inactive" -- but not vice versa. That said, I'm not sure the cron is even doing what it is designed to do. :-/ I do have the option selected and the cron set up, but I have clients who are "Active" with no products, and the cron doesn't seem to change their status. I'm really not sure what's going on.

We have a system in which, for various reasons, we create client accounts and then the clients login to place their orders. When we create the accounts, we mark them as "Inactive." We had always assumed that when the client logs in, and places an order, her/her status would then change to "Active." However this hasn't happened. As a result we have a lot of clients who how have products/domains but are still listed in the system as "Inactive." Have we misunderstood how the client status is updated? And is there anyway to fix this that doesn't require us to go into ever individual client listing and change it manually?

I've searched on this topic and found some threads, but they all seem to reference files that don't (no longer?) exist in WHMCS. Basically, I want to modify which buttons appear in TinyMCE in the KB article edit interface. (In particular, I want to add the drop-down menu for choosing semantically correct HTML syntax like H1, H2, etc.) Other threads have referenced a file at edit/edit(or).php, but no such seems to exist. I assumed that this was something that would be dictated in the admin templates, but I can find no reference to TinyMCE setup in these files, either. Can anyone point me in the right direction?

Yeah -- I had the same issue with downloading the plugin. The site seems to use WHMCS for the interface which is. . . ironic. ;-)

I wanted to come back and say that we found a way to do this with items currently in the order by using the WHMCS Product Limiter Addon (which is free): http://www.jetserver.net/whmcs-product-limiter. A couple of caveats: * Product Limiter only removes the product that violates the limitation that you've set up. In our case, we had a free domain linked to that hosting product, so I had to add some code to the plugin to remove not only the last product but the last domain, too: In hooks.php, find the line that reads: unset($_SESSION['cart']['products'][$cart_items[count($cart_items) - 1]]); and below it add the following: unset($_SESSION['cart']['domains'][$cart_items[count($cart_items) - 1]]); * If a customer has repeatedly added the same (limited) product, they have to cycle through the checkout a couple of times until the amounts in their cart fall below the limit.

The problem with this approach (for our group -- I'm a colleague of the original poster) is that group discounts don't show up on the checkout screens -- they're only applied at the time of invoicing. We want it to be clear to our users that we will never charge them for this and not have them balk at participating because they think there is some hidden/future cost.