Tim Greer

Just an update; I spent a little time and I figured out a work-around and it's working exactly how I want. It was a little bit of a hassle, but it is completely seamless and works perfect. I still need to do the conditional in the "order complete" template, but I can now set a method in the new "step" I've put in-between to allow for a way to check that. Cool.

I had done that, but figured I'd see if anyone had an idea here as well, so I don't have to bug them about it (I'm sure they're busy enough). The person that answered today didn't know what a Smarty session was and suggested I use a session variable, so I'm not sure where to go, but I'll try some other ideas today and see what I can accomplish. Yeah, but with hosting, I don't have a pool of credits that can run out and I can simply terminate the account, but I do implement all of the appropriate checks and I didn't think it would be likely, it was just one of a few ideas that turned me off on the API. Ultimately, this is what I might have to do, but I was trying to avoid them going off site, even to the WWD storefront). Out of all of the years I've been doing web hosting, I have seen that the chances of a client going off site for any reason pre-order, will increase the chances of them being confused and not finding your site again. So, they get a domain and then have to look for a web host again. WWD's storefront is okay, but the fact I offer SSL certificates forces a link at the top of the storefront that says "Web Hosting" (not mine). I could certainly remove the SSL certificate option to remedy that problem, but I don't believe it makes it easy to go back to the hosting site or order form (everything is static for links, and after the order is completed for a domain, the line on the site is pretty far down the page and small that says "Go back to $company_name"). Obviously none of this is a massive issue, but it can potentially be significant enough to lose a certain percentage of orders if clients get confused or have to do too much and are taken off the site. This is why I'm okay with how they access the storefront, after the order is complete or they've been invoiced. That way they've signed up, get an email and know how to access the site, remember who they're hosting with, etc. I've seen it happen too many times to count, with some major web hosts I've worked with over the years, so I'm just trying to anticipate that scenario and avoid order losses and client confusion. I appreciate the suggestions, and I've already considered doing something such as this before opening tickets and posting here, but thought I'd try for a more seamless method. It's just that enom's lowest price is too high for what you get, but I might just have to do it anyway and avoid all of these issues. I did check out and even signed up for the Directi API account, but didn't really like what I saw and didn't use it. I'm just not a fan of the credits the API's all want you to have (I understand why it works that way) However, if it can solve the issue, even if the domains are a little more per year, I might just end up doing that. I'll have to check into it more if my mods to the order today don't give me the results I want. Again, thanks for the suggestion, and I'll likely go with the Directi API if this doesn't work and I want that intergration. I guess we can consider this thread dead/closed now, since there's really nothing anyone on the forum can do, like you said. Thanks everyone.

Unfortunately that won't work. However, I'm going to test out some ideas today. Thanks for the suggestions.

Since I'm unwilling to pay huge fees for a registrar API, and have credits I might never have used (or worse, have too many illegitimate orders taking up all the credits and not enough time to fund the credits before a legit order comes in (and before a credit back after canceling)), I'm using the WWD storefront for reselling domains and SSL certs. This allows me to offer the cheapest price without all the concerns (and let's the clients order them on their own, separate from the hosting service offered). That all said, here's the problem: I have a rewrite conditional for step 2, so it actually uses a different script for domain registration, transfer or "use my own domain" requests. This allows for better control and security, and I have my script actually check the WWD site itself and see if the domain is available and automatically capture the current price (and savings from the normal suggested price I'd be offering). That all works great. I can keep the group and product id's set and pass them around and then post this (the domain now set) to step 3. There is the problem though, the compiled order.php script dictates that someone *has* to go through the actual step 2 order process (and not the bypassed script I've created to work seamlessly), or the order will not be valid and no product, domain or pricing will show. I can post values directly (via GET or POST) to the (real) step 2 order process and it will read in the group (gid) and product (pid), and that's where it starts creating the needed Smarty session for the order to be valid. What I need to do for this to work, is have an option where I can make it so step 3 can have variables passed to it (via POST or GET or otherwise), so I can simply pass the same variables as I did to step 2, to step 3 (being just the additional "domainoption", "sld[2]" and "stld[2]" variables/values to be read into step 3). I have it all set for "owndomain" even though it works for new registrations and transfers (later, after the order complete display). This keeps new clients from getting confused if I force them to first register their domain off the order form. I'd prefer to have a variable I can also pass throughout the steps, such as "domreg" (for example), so I can keep track of the initial "this is a new domain they need to register" conditional. I can't enable the TLD prices since I don't use an API. I want clients to order and control their domains without feeling forced to move to or register with us anyway, so this would work out nicely. With this option, if the domain name variable itself can be passed, I can run a template conditional against it such as {if $domreg}form to Register your domain now! URL?domain={$domain}{/if} (just for an example). I also can't set prices for the TLD's, because I can't charge them unless I register it, and without an API, I'd have to use my own financial information to pay for it (God forbid they do a charge-back (not that I'd expect this, but some people are unreasonable and scammers)), and I'd have to either provide access and explain to them about a new WWD account (that has my payee information on file), or have them register a GoDaddy/WWD account and go through the hassle of explaining to them and transferring it to them. Obviously, a domain registrar API is looking more reasonable all of the time, but Enom wants $1,499 of credits (Chuck-E-Cheese tokens I may never use, as far as I'm concerned) for their lowest API plan and my domain base price is $3 higher each than I get from WWD without any pre-purchase credits. To get the pricing I get at WWD, it would cost $6,999 of credits! Also, I'm still concerned about potential abuse (it can happen, albeit unlikely). So, the changes I'm looking for are very simple and quick, but obviously it deviates from the WHMCS default and design. I've already taken an hour or so earlier today and created all the initial frontend logic for the domain checks and so on, but I can't post to step 3 due to Smarty sessions being unique to the compiled order.php's code, so it can only create a new, unique session, which won't work with the later order step(s). I've even played around a little by using some iframes, JS onloads, Ajax and other various calls to have the script itself make the request to the "real" step 2 process order URL with the appropriate variables/arguments passed in the query string/URI and POST, both for the script itself and the client, but again, it has to be the client directly accessing it, and the session will be uniquely different anyway. Besides, I'd still like that final "order complete" simple logic available. Is there some way to pull this off that I'm unaware of, or perhaps some way I can pay to have such a quick/easy mod performed? It's really that easy (accepting posted vars to step 3 and not requiring step 2 to start the Smarty session), not having to enable any other options, simply pass a variable between the scripts with a $smarty.post or $smarty.session variable, and just have two variables available for the order complete Smarty template driven script so I can work with those variables. In all, if the code wasn't compiled, it would be a 5 minute task, but since it's limiting what I can do with the code as is, I'm curious if I'm missing something (if there's a way), or if this can be something someone with the power to, can add/mod (for a price)? I really like a lot of things about WHMCS, but this is definitely a frustrating and limiting aspect that I'd be very happy to see as a viable option. For now, I hate that I have to do this, but it looks like I'll have to set a pre-order domain check, ask them to make a note and fill that in upon ordering, and then again by linking to the storefront and hope it doesn't piss them off. Anyway, I realize this is long, but I wanted to provide all of the details about it, even if it's a pretty simple request. Any idea if this can be accomplished now, or in the near future, or is that just it then and I'm forced to use an API from a registrar that WHMCS supports because I can't pass variables to step 3 like I can to step 2? Thanks for any insight, suggestions or whatever you can.

I think I pretty clearly said "why" above. I do sell domains, I just don't use an API and WHMCS doesn't support the API for WildWestDomains at this time anyway (not that this matters). I'm not sure where the confusion is about wanting to offer newly signing up clients an opportunity to obtain a domain from my reseller storefront with WWD at a good price (and prevent them from being confused at the same time -- and it happens, I've been doing web hosting for 17 years, so I know it's a common thing new clients can get confused about), which is why I want to present a link or form button for them to "continue" and "register the domain name" after the order has been completed or invoiced. For the record, I am aware it doesn't have to be automated if I set the TLD prices, but it will still add the price to their invoice, and I can't use my own payment information to register a domain for them, and I don't want to force them to allow me to have control over them, nor do I want to have to force them to initiate a transfer to their own WWD/GoDaddy account just to get control of their domain. Finally, it's not a big deal, I was just confused about how it was set up to work and fail to see why it only allows for set prices just to search for domain availability (not just ordering it through me or my storefront). But, it doesn't really matter what I think, I've created my own frontend for the WHMCS orders and have it all working that way -- I just need to find some way to have the Smarty driven templates allow for an action hook, which doesn't seem to work no matter what (no posted variables will pass regardless of how it's set up). However, it's obvious this TLD issue is a feature, and not a bug, so there's no reason to discuss my functionality desires in this thread anymore. Thanks for the insight.

This above worked, but then it stopped working without any changes. The issues I have at this time, are the domain type (existing domain, transfer, register) variable hooks. I added a simple [if} conditional in the "Order complete" and "View invoice" .tpl files for the domaintype being "register", and it was working, but as soon as it was Smarty-ified and compiled into the c_templates viewinvoice.tpl it no longer worked, so I'm unsure what to do about that. I want to present a link to the reseller domain registrar storefront site's URL I have (along with the domain variable I can POST to that site to get them started with that domain they initially selected on the order), but _only_ after the order is complete or they've been presented with the invoice, and _only_ if it's a new domain registration (not for people using their existing domain on my hosting service -- and I don't plan to offer them a "transfer" option, as it would be too confusing for them since I don't use a registrar API, and I don't want newbies thinking they have to pay to transfer a domain to me just to get hosting). Is there any specific hook or switch or variable or conditional I can use for that purpose?

It appears that I simply failed to realize that you had to add the TLD's with prices (since I'm not using a registrar API), or they won't allow the TLD dropdown to show anything at all. I don't see a means at this time to allow people to search for available domains unless I set a price and use a domain registrar API (or, rather, it will force me to sell the domains and charge them). It was just that I didn't realize that and didn't find it searching the FAQ's/Documentation (or I missed it). Anyway, I suppose it's not a bug, just a matter of confusion then. That won't work for me anyway, because I don't buy the domain for them (and I therefore can't charge them in the invoice, nor can I make it look like it's free), and I want to keep it separate and for them to be the only one's with control of it (I just want to give them a good price and keep them on the site and not confuse them on new orders where they need a domain registered). That said, I've already created a new interface for the hosting orders and for domain registration. I did also find that I was able to use the domaintype variable hook to allow them to order a domain via a reseller storefront I have after the order was complete (or the invoice for mail-in/bank transfer), but I now see it's failing to show anything after it's been compiled/Smarty-ified, even though the variable hook is there, so I'll have to work on that after I complete the final stages of this registration interface. Anyway, thanks for the help.

Nevermind, I found it by looking at the template source. I can just add: {if $domaintype eq "register"}Stuff here to register your domain{/if} Thanks.

I plan to use a domain registrar storefront (wild west domains), rather than a domain registrar API, so I'd like to present people with a link to it for their registering their new domain (fields I can populate with their information, when pointing/linking to the storefront), but only if they've selected "order a domain" through us. I won't confuse them with the "transfer domain to us" option, and plan to implement our own module to check that the domain is free before their hosting plan order, but want this to appear only after they've ordered (otherwise we risk the client being off site and getting confused with all of the WWD options and pages to complete their order). Does anyone know if there is a switch/conditional I can add to the order complete.tpl and/or viewinvoice.tpl files that will allow for this logic (i.e., it's not someone updating their name servers and actually needing to register a new domain)? Something like {if $domainoption.register} My form fields here w/ link to storefront {/if} I plan to write my own modules or frontend to solve some of these issues, but will need this special conditional on the invoice/order complete pages. If anyone knows, please advise. If I find the field and it works with a conditional, I'll update this thread. Thanks.

There is nothing unique to the install, which was a fresh version of 3.6.2, so I can't imagine what would be unique. Anyway, I shall open a support ticket.

WHMCS v3.6.2 Firstly, I see no TLD's listed for "Transfer my domain to you" or "register domains with you". The TLD drop down is blank. Also, I notice that when a client fills in their own domain name (not checking to register it and selects "Use my own domain and update my name servers"), it will allow them to fill in pretty much anything without error. You can input something like 34637574574ysdgsdgr.trweyey and it'll accept it as appearing valid. I'm using WildWestDomains for their pricing and no APIs with any registrar's I resell for, because it seems too pricey for what you get and I don't like the idea that some of them will take too long to fund the credits you might need, especially in fraud order situations with too many domains ordered through them (the hosting part is easily enough dealt with, at least) and ensuring there's enough credits and quick enough funding (and I don't like the whole Chuck-E-Cheese's credits (tokens) you have to buy that you might never use anyway), so I'll likely be creating some module addons today and tomorrow to interface with the WWD storefront (not API) and have my scripts act as a gateway for orders like a browser (at least to a point). So I can fix these issues and bypass the TLD on orders, fix the wording , etc. and remedy these issues, but I figured I'd report these issues anyway.

Okay, I see that it won't open a ticket from the admin email (saying it can't find the Ticket ID -- that was a confusing message), so as long as I know that's part of the testing issue and it's normal, I have no qualms with that. The other sender emails that didn't come in once they were piped, aren't showing as a failure or success to open a new ticket, so I'll keep looking to see if I can find anything.

More strangeness, if I set the script to a from address at the WHMCS admin email address, it doesn't come through (which is what I was testing with locally), but it will come through if I change it to another address at that domain. So perhaps to prevent some looping mistake, you can't open a ticket as the admin address (I have all tickets opened alert me at that address, so okay). However, why do none of the test emails sent from other off server/network email addresses ever work and open a ticket, when I see they are being piped without errors in the mail logs? This is frustrating and annoying for it to just "not work" without any errors displayed or logs showing a problem, since it's clearly not working.

FYI, sending via sendmail from a script also works for both on and off site addresses that I declare in the CGI or PHP script. Extremely strange that sending email through the same local service from a valid mail account address fails to open a ticket (I can CC and BCC it to myself or send to other accounts fine and see it piping to the pile.php in the logs with no errors). This doesn't make sense. I really wish this pipe script wasn't encoded so I could just fix it!

And, for what it's worth, the mail command on other servers with valid addresses doesn't work either. It, too, shows in the Exim logs that the email reached the server, piped to the pip.php script and then did nothing. It would be nice if this did proper error checking so I could see what is wrong. If it matters, there is no high load or other email usage, and everything is set up fine. I find it strange that it will accept mail sent via the mail command (it's not as if I'm manually piping email to the script), and no others come in at all (other than the dozen or so out of maybe 20 on tests). If I don't get an answer pretty quick, I'll just dump the helpdesk, since it's too buggy and use a 3rd party solution. Then, we might not have much of an incentive to select WHMCS over some other solutions either. We simply can't have problems like this, especially when the scripts aren't coded to catch errors and report a problem. The silent drops are troubling. I'm hoping we're missing something and it'll work fine, because the billing, helpdesk and knowledgebase at least looks like a nice package.

I've retested a few more times over the last few days and just again, and only if I do a mail command from shell will it open a new ticket. Any emails sent from valid addresses on the same system (local delivery) via SMTP never open a new ticket. (Believe me, the SMTP works fine, too, I can send email to and from addresses that have a POP mail box, including adding a POP account and keeping the forward for the support address), and only the POP works. Exim's logs show the email incoming and piped from other mail addresses, but it never opens a ticket. In other words, I know they are being immediately delivered and piped to the pipe.php script, but nothing happens. Why is this? Why does it work fine if I mail from the mail command in shell?

Linux CentOS 4.5, Cpanel/WHM and Exim, email pipes fail without errors. We are testing the demo for the newest, stable WHMCS version (3.6.0). PHP 5.2.5 (tried as CLI and CGI, with php -q, /usr/bin/php -q and /usr/local/bin/php -q). All versions (CGI, CLI) have ionCube PHP Loader v3.1.32 and Zend Optimizer v3.3.0. The system runs Apache 2.x w/ suphp, though that shouldn't matter for pipes. The following fails: support@domain.com: "| php -q /home/user/public_html/whmcs/pipe/pipe.php" support@domain.com: "| /usr/bin/php -q /home/user/public_html/whmcs/pipe/pipe.php" support@domain.com: "| /usr/local/bin/php -q /home/user/public_html/whmcs/pipe/pipe.php" Nothing happens. I sent about two dozen test emails from local email accounts as well as off server/off network email addresses and no new tickets are opened. I've tried this from registered user addresses and it doesn't make a difference. If I send an email on the local system itself to support@domain.com via "mail -s test -vvv support@domain.com", it will open a new ticket, but not from other addresses. Everything else is working fine. The permissions on the /home/user/public_html/whmcs/pipe/pipe.php file and directory are correct and executable. I did finally see about 10 of 15 test emails open new tickets after hours, which would suggest that it was a delay in sending/receiving, but that was not the actual case. All other test have no results, no emails at all. The Exim mail logs show no errors, and there are no bounces. It's strange. How reliable is this helpdesk in the WHMCS system? I've been testing a demo of WHMCS and thought it would be nice to have the helpdesk included, but if it's an issue at all (whatsoever, even in the slightest), then please let me know. Also, please let me know if it's possible to change the template for the WHMCS system so we can point the helpdesk/tickets links to a different 3rd party script. We don't care, but want to ensure there's not some small thing missed (I doubt it), and we just need to make sure that the helpdesk works 100%. We will otherwise consider using just WHMCS for billing and another solutions for a helpdesk.