alturic

Except ValidateLogin is useless as they either changed the functionality of the call (without documentation) or it's flat-out broke. We use ValidateLogin (since it creates the session properly) but sometime around 7.2-7.3 the functionality has stopped creating sessions and the passwordHash it returns is completely useless to WHMCS itself. CORE issued, but this kind of stuff is probably the biggest issue we dislike about WHMCS. Changes that either intentionally (without documentation) happen or just completely break between versions. The craziest part is that dologin.php works fine when it comes to creating sessions (obviously) so it would take all of 10 minutes to find the corresponding code that needs to be adjusted in ValidateLogin but alas the source is closed and these kind of bugs are apparently not a high priority to issue a hotfix.

Nope, we were in the process of upgrading from 7.1 to 7.4.2 and noticed the game-breaking change. There's a CORE issue for it, but of course there's no real communication on when another build will be. What's insane to me is how they won't even push out a hot-fix or give a workaround. dologin.php correctly set's sessions, hence they know what ValidateLogin needs to return for the passwordHash. Oh how I wish they still offered unencoded source purchase.

Except for the fact there was a game-breaking change with ValidateLogin sometime around 7.2-7.3 where ValidateLogin no longer creates sessions, AND the passwordHash that's return is apparently completely wrong and can't be used for setting $_SESSION['upw'].

Don't feel bad, sometime around 7.2-7.3 ValidateLogin was broke and no longer creates sessions. The best part, the passwordHash that's returned doesn't mean anything and can't be used to set the $_SESSION['upw'] either.

Honestly, I think it's something with PHP and sessions. It's writing sessions to the tmp directory for sessions and they work, but remember me isn't working. So at this point, forget any API stuff, going to my install directory and logging in, works. Going to my install directory and logging in with remember me checked, does NOT work when you close the browser and come back. EDIT: Upon further testing, I don't believe it's anything on the server as admin and master client logins all work, and are saved and restored upon browser exit and reopen. It's only the subaccounts that do not "remember me"...

It seems like everything "works", until you close the browser. Anyway to have a remember me option passed to the internal API to it sets the cookie as well when it starts the session?

Hey guys, I'm using validatelogin (internal api) and while the docs say that it returns userid and hash so you can then set the two session values, it appears as though validatelogin is already setting the session or something? As an example, I have test.php, which strictly does validatesession. It returns successfully, and then if I goto our clientarea.php we're already logged into that client? If I log-out, and refresh clientarea.php we are still logged out, and then if I goto our test page, it validates the user/password combo and then if I go back to clientarea.php the new client is logged in. I was under the impression validatelogin simply returns data and doesn't actually initiate any sessions or anything?

There's gotta be more than a handful of members out there who attempt to charge an unpaid invoice everyday instead of once per week for X weeks?

Anyone know the answer?

Oh and also, since WHMCS is meant as a hosting billing system what would be the easiest approach to start stripping away the various instances of the words "Domains' and such in the client-side of things? Is ALL of that stuff in the tpl files or is there language files I need to edit as well?

So, knowing that code above shows on existing clients "Order New Services" checkout, the value they enter for customfield[13] should get sent to (and saved obviously) to customfield[13] in the clients profile fields, when the <form method="post" action="/cart.php?a=checkout&submit=true" id="mainfrm"> gets submitted, right? If so, it's not for existing clients checking out for some reason. :-/ I know traditionally people probably do foreach $customclientfield and stuff but this was the only way I was able to get it to work how we needed since we're using if statements for literally every customclientfield, I didn't know how to do it inside the foreach syntax. Yea, I'm a bad boy and use {php} code all the time and then save the var into Smarty so I can do: {if $forumaddoncount['PremiumForum'] == 1} <tr style="display: block;"><td style="width: auto;">Forum Username</td><td><input required="" style="max-width: 110px;" maxlength="20" type="text" name="customfield[13]" id="customfield13" value=""></td></tr> <tr style="display: block;"><td style="width: auto;">Forum Password</td><td><input required="" style="max-width: 110px;" maxlength="20" type="text" name="customfield[14]" id="customfield14" value=""></td></tr> {/if} Last quick question, is there anyway to find a list of vars that are available (without {debug}ing every hook) at each action hook? So if I wanted to find out what variables were available at "InvoicePaid" I could pull $clientdetails.customfield13 or whatever it might be?

Ok, so we basically have a new client checkout process/order form exactly how we need it, and I'll explain further below. We have a custom client field for "forumname" and "forumpassword". Those 2 fields are using IF statements in viewcart.tpl and only show if someone select the product addon "Forum Access", so that part is fine. My question is this though and perhaps I'm just not truly understanding what people can use all the various hooks for (such as InvoicePaid) but theoretically we'd want to run the forum account creation AFTER that particular invoice is paid, but it'll run on every invoice being paid erroring out because there's already a forum account with that name... so forum creation type integration is the AddClient hook really the only real way people handle those? Secondly, I put this: <tr style="display: block;"><td style="width: auto;">Forum Username</td><td><input required="" style="max-width: 110px;" maxlength="20" type="text" name="customfield[13]" id="customfield13" value=""></td></tr> into viewcart.tpl for someone doing "Order New Services" but yet when they click Checkout it doesn't post the value they entered, any clues as to why? Can you not input custom fields on existing client checkouts, which I'm assuming I'm wrong about.

Let me explain what I'm looking to do and you guys give me input on which hook you'd use. So I have a script that will add a user to our forum. Great, if it was for all users we can use anything, BUT what all vars can you pull? Example, I only want it to fire if the order has been paid and only if one of the $products has a Yes for a configoptions optionname, so I was thinking of doing the hook for accept order because we'd only accept an order if the invoice is paid. Also, if I did hook it to accept order, would I have to do foreach's for when/if we bulk approve orders? Or do these hooks fire once for each order if bulk "accept order"ing? - - - Updated - - - Oh, and i dont have to include hooks in the hooks dir, right? Whmcs will always include all files in there?

<?php function create_store($OrderID, $OrderNumber, $InvoiceID, $Products, $Addons, $Domains) { echo"<pre>"; print_r($OrderID); print_r($OrderNumber); print_r($InvoiceID); print_r($Products); print_r($Addons); print_r($Domains); echo"</pre>"; } add_hook("AfterShoppingCartCheckout",1,"create_store",""); ?> Unless I'm misunderstanding what should happen here (I don't think I am simply do to "where else will these echo", the user should get this echo'ed to them upon checkout, right? I have a file in includes/hooks called blah.php and nothing happens at checkout, anywhere.

I guess I'll give up on this. I've tried adding you on Skype as well with no luck.