FRH Dave

Hope it's not too late, but I'd love to see the ability to pass configuration data to the SolusVM master. Things like template (with the ability to present a clean name to the customer ("CentOS 6 64-bit") instead of the filename ("xenpv_centos65x86_64.img")), # of IPs, which node to create the VPS on, which node group to use, etc.

Now that I've got a better understanding of the options, I'm still puzzled as to why some of my checkboxes toggle themselves on at checkout. I'm still trying to come up with some better logic here, but it's definitely a toggle and not "on when this specific action happens". Right now my order form has a checkbox, slider, checkbox, and dropdown, in that order. A user selects this package and gets the options screen, with checkbox #2 selected and #1 unselected. The user clicks checkbox #2 to de-select it. The user changes the price to any other pricing term, and checkbox #1 toggles itself. Changing the price again to any tier will toggle checkbox #1, and this can be repeated indefinitely. Checkbox #2 never toggles itself again. EDIT: While testing this, I noticed that the options are appearing in random order within their group.

Nope, I left the value blank. I figured since the module (SolusVM) isn't passing that to the master server anyway, no point entering it. But I'll try that and see if it works! EDIT: It did! Thanks!

Okay - that took care of the checkbox option. Now I've run into a different problem. When I create a dropdown containing four options, it only shows the very last dropdown entry. The price is correct and correctly matches the term, but it doesn't show any of the other options. Is this intended behavior? I assumed that if I created: 10 Mb/s - $2.99 20 Mb/s - $9.99 50 Mb/s - $29.99 It would let the user choose from any of the above. Instead, it only shows "50 Mb/s - $29.99".

About to run out of the office now, but this looks like it's going to work. Thanks!

Thanks. I can see the multi-company integration being a little tricky, as I'll have to stay on top of all the settings. Fast forward five years and I've purchased six companies; if I want to change a package or an email template, I have to change it seven times. If a long-term goal for the migrator could include some additional intelligence to parse the user list and insert the newly-imported customers into the first available block of open user IDs, that would be helpful. There's no real harm if customer #123 in WHMCS becomes customer #4567 in Blesta.

It's been a while since I've played around with the options, but I'm getting a little confused on how the add-ons work. I've created three basic packages and configured the corresponding cPanel module. Each package has pricing for 1-, 3-, and 6-month terms and a 1-year term. The cPanel module correctly pulls the package names from the server and the package itself appears to behave as expected. I want to be able to create an additional service called "SSH Access". For the sake of example I'll be manually provisioning this feature on each order, so I'm not concerned with passing this additional data to cPanel. If I add an option for "SSH Access" (a checkbox), two unexpected results happen: 1) No matter what combination I select the options with, the order form returns the error "One of the configurable options selected is not valid for the service". I've confirmed that the options are all in my "Accelerated Web Hosting" group, and the package is set to use the option. 2) The checkbox toggles itself. Let's say in step 1 of the ordering process I select a 3-month term. When I proceed to step 2, the SSH checkbox is checked. But if I change the term, it un-checks itself. If I change the term again, it re-checks itself. This process can be repeated indefinitely and I can always manually check or un-check the option. Thinking that the options don't work the way I assumed they did, I tried creating SSH Access as an add-on. This works, but not as expected: 1) Step1: I select my plan with a 3-month term 2) Step2: I add my domain name and select 3 months of SSH access 3) Step2: The next page shows only the SSH access add-on, and lets me change the term What I was expecting is that Step 2 would show the options and allow me to proceed to the order review step. Failing that, I was expecting Step 2 to show the add-on plans, with the next step being the order review. Instead, I'm getting a sort of Step 2.5 that has me re-select the SSH payment term. I'm not sure where I'm going wrong, so let me ask this: What is the proper way to add an option to a cPanel hosting package in Blesta, preferably so that the term for the option matches the term for the package?

Is it still recommended that the WHMCS migrator only be used to import into fresh installations? What are the implications of not doing so? I'm asking because my migration process at this point is to install Blesta, log which configuration steps need done (modules, payment gateways, email templates, etc), re-install Blesta (or revert to a "freshly installed" backup), put WHMCS in maintenance mode, pull over WHMCS data to Blesta, re-enact all the Blesta configuration steps, and go live. It seems like the import process shouldn't be touching any settings outside of packages, so it would seem logical to assume I can configure Blesta as I want it and then pull over the WHMCS data. But I'm also wondering about down the road. If we decide to buy another hosting company that uses WHMCS, I'll need to be able to import their data into our live Blesta installation.

I remember this being discussed long ago, and I don't remember what the outcome was. This is definitely a good idea. I would prefer to see it structured so that you enter ledger-style adjustments to move the price in either direction. Instead of simply entering a new value as you do in some other billing platforms, you get something like: $ 100.00 : VPS Package -$ 25.00 : Recurring Ad Credit Barter $ 75.00 : Monthly Total That way, you have a description of what happened so when you look back on the account a year later, you see why the customer is only paying $75.

Just wanted to check in and see if any progress has been made here. Is Quantum Vault still just around the corner, or should I be looking at switching to Stripe?

Oh - an affiliate program plugin would be nice. It should have the option for both one-time and recurring payouts determined on a per-product basis. It should also have the ability to set payouts as either a percentage of the service value or a fixed dollar amount.

Anything to make the import easier for the customers. If they don't have to re-enter their card information, then so much the better.

I used to be in favor of a wiki. But after re-writing my content and going through it all, I think a KB is the way to go.

There's definitely going to have to be manual customer involvement to switch to Stripe. What I'm trying to do is minimize customer inconvenience. If I can, I'd like to install the Stripe module for WHMCS, gently encourage everyone to move to Stripe over a month or two, and then migrate to Blesta, hopefully bringing the Stripe tokens along. If that's not possible -- if that would cause the customers to have to enter their card details once in WHMCS and again after migrating to Blesta -- then I'd just have to do it cold turkey and drop CDG when I move to Blesta. Definitely not preferable.

IP management: We've grown past the point where a spreadsheet is a reasonable solution. QuantumVault plugin: I think this is already assigned to a CORE. Knowledgebase: I reverse my earlier statement about a wiki being a better choice. I'd be thrilled with a KB. I remember you started one a while back -- any progress? As for development costs, I'd be willing to consider paying one-time for modules. Free is great, but free doesn't write code. What would you consider a fair price for some of the above?

Thanks, both of you. We currently use offsite storage for CDG via QuantumVault. No card information is stored or collected locally. I think I got confused -- Blesta doesn't yet support QuantumVault, does it? Because if it did, my life would get a LOT easier. I could gently and slowly encourage my customers to slide over to Stripe.

Since Blesta doesn't support CDG Commerce, I'm going to have to do some payment shuffling before migrating from WHMCS. Naturally I want to inconvenience my customers as little as possible. If I set up the Stripe module in WHMCS using offsite storage (all card data is stored only with Stripe, leaving only tokenized data in WHMCS), will Blesta import the tokens during the migration? Or will customers have to re-enter their card information after moving to Blesta?

I'd be VERY interested ... if they included Xen support. SolusVM seems to find a new way to annoy me every week.

Keep in mind that if you're going to charge more for V/MC customers, you're only permitted to tack on the exact amount of card processing. So if you're getting paid for a $100 transaction, and your processing fee for that transaction is 1.5% + $.30, you can only bill the customer either $100.00 or $101.80. If you bill the customer $102.00, you're out of compliance and may find yourself unable to accept V/MC, regardless of gateway or processor. I haven't read through AmEx's master agreement for years, but they've always basically pointed at the V/MC agreement and said "yeah, what he said". This makes charging more per gateway a little sensitive. Someone who has a beef with your company might report you to Visa because your price is 100% on this gateway and 80% on that gateway. Not that they'd be right, you'd still have to deal with it. And who knows if you're just going to get an apathetic rep who simply deems your account out of compliance. It's one of those things that's a grey area, and you could probably get away with it, but is it worth the risk -- however slim -- of you waking up one day to find out PayPal has frozen your funds?

You understand that this is a bug and/or exploit that hasn't been publicly disclosed, right? Because I'm not sure why you're so against getting the word out. Are you active on WHT?

I see your point, but I disagree with it. There might not be any business incentive to passing it on, just as there was no business incentive to responsible disclosure. Disclosing it to a trusted third party (like Rack911) is not only an ethical choice, it also may help prevent another outbreak like those that plagued WHMCS last month. WHMCS seems to have a history of not responding to security threats until they're made public, so putting it in the hands of a neutral-and-trusted third party is doing a tremendous service to the community. I don't buy into the "that's their (people who use WHMCS) own dumb fault, let 'em burn" mentality. Never have, never will.

I'd say at this point hand it off to someone like Rack911 or one of the other trustworthy security firms. Let them do their thing and, if appropriate, post on WHT. If you make a public disclosure, it would immediately be shouted down as a conflict of interest.

Most of you know probably already know that we use a reseller account for our shared hosting. We have our own colo'd servers for VPSes, but there just hasn't been enough per-unit profitability to justify doing the same for shared hosting. Now you know. We're getting ready to move from our InnoHosting-based WHMCS installation to our Blesta installation hosted on another provider's VPS. We'll also be moving the main site over as well. Many of our existing shared hosting customers will be remaining at InnoHosting for now, and we will soon be launching our own shared nodes in our home DC. So we'll end up with our website on an off-net VPS, some shared at InnoHosting (cPanel), and some shared on our colo gear (InterWorx). I'd like to continue using InnoHosting for ns3 & ns4 (we're keeping that reseller account open, so why not?), while moving ns1 & ns2 to the Blesta VPS. In the future I'll add some more geographic diversity. How do I ensure that the new ns1 & ns2 on the Blesta VPS contain all the information for all my shared hosting customers on the InnoHosting server? Is this the "synchronize DNS records" function in WHM?

Getting ready to make my final switch. The instructions recommend starting with a blank database. Does this apply to configurations as well? I'm going to leave the plans alone until after the switch, but what about setting the company name, setting email templates, etc?

Yup. They want to know what range you have, what ISP issued them, and your current utilization. They'll also ask if you're renumbering out of your current block. So a submission table might look like: xxx.xxx.xxx.xxx - /29 - BurstNET - 100% xxx.xxx.xxx.xxx - /27 - BurstNET - 93% xxx.xxx.xxx.xxx - /27 - BurstNET - 100% xxx.xxx.xxx.xxx - /28 - Limestone - 100% xxx.xxx.xxx.xxx - /27 - Limestone - 80% etc. It's a minor nuisance and as Paul said ARIN is really cranking down on the "dime a dozen" IPv4 mentality of just a few years ago. I'm sure in another year I'll look back at this post and reminisce about "how hassle-free it used to be to get IPv4 space". Limestone's service far outweighs this minor annoyance, and I really can't blame 'em for doing it this way. I just have an unrealistic expectation of being able to click a Magic IPv4 Dispenser button and get more space.