Paul

Looks like a nice RESTful API, do you know when the beta will end? To be honest, I'm not sure we would consider doing an official module until the API is out of beta.

Yes, you MUST overwrite these files when upgrading. Every single time. Also, to clarify, the hotfix can be applied to PHP 5.4 or PHP 5.5. The standard distribution will work from PHP 5.1-5.4, so it's not necessary to apply the hotfix to PHP 5.4, but you can. Also, there are 3 files, not 2 that are encoded. If you are only seeing 2, you may be looking at a patch where there was no change. Every major or minor release will have all 3 of the files.

We are going to be making use of PHP 5.3 specific features including namespaces, etc.. however to what extent and when I'll defer to Cody. That is the point really, to raising the minimum requirement.

We will be raising the minimum requirement to PHP 5.3 next year, likely in Q1 or Q2.

I'm not a fan of OpenVZ at all, if you ask me it's not really even virtualization. It's the shared hosting of VPS, but hosting providers love it because they can oversell. Each have their benefits I suppose. I prefer KVM or Xen PV personally.

Yeah, security-wise it's not a problem. Inactive users can't login. But, if you are concerned, you could change their password and email address and then de-activate.

We are intending to extend the portal plugin into a more fully featured CMS. Adding additional links to the navigation, even if they link to external content (ie your existing website) would be best suited for this plugin most likely. You could create additional pages and enter the content in a WYSIWYG editor in Blesta, or link those pages to external content.

Staff can do things that are linked to their account. Deleting a staff member entirely could cause database errors, and you would lose potentially vital information about the user, including credit card numbers they may have accessed. It's a good idea to maintain that information, especially for PCI requirements. Perhaps a 3rd status called "delete" which doesn't show them under Manage Staff under Active or Inactive but maintains this relationship would be good. Still, as soon as you deactivate a staff member they lose access.

Oh, that's part of the PHPIDS library. That rule wouldn't be executed unless you navigate to that directory in your browser. We try not to modify 3rd party libraries unless absolutely necessary.

Which rule do you mean?

Yeah it all depends on the application. Most VPS's we spin up here are very minimal on resources, especially since we gravitate to a one role per server rule. Separating each service, HTTP, SMTP, MySQL, etc into different servers means we utilize more but smaller servers. And each role has separate requirements.. a web server may require more RAM than an SMTP server for example. So, depends what your customers are doing. If you can determine that, it should be pretty easy to spec out something that will appeal to many of them.

Ok, we will leave the task open and plan to implement a fix, but it is unlikely to be in the official 3.3 release and will be fixed in a future version.

While this is rare, it is a legitimate concern and I think it should be corrected. The problem is that it's not an easy fix.

Under Packages > Options, click on the Group name and it will expand and display all the configurable options that are assigned to the group. I'm assuming all of your configurable options are assigned to the same group, and do not each have their own group. Is that right? Then, you just drag and drop them within that group. In the attached screenshot, I have a Multicraft group with 2 config options, Server Jar File, and Dedicated IP. I can sort them by drag-n-drop here.

Yes it will set a dedicated IP when provisioned automatically. You just want to make sure you have some IPs for each Daemon ID set up in the module (and available to multicraft). If they do not get a dedicated IP, it will use the shared IP and a unique port (Not the default 25565).

There's already a task for this, CORE-1287 however there's some confusion of whether this is a requirement or not. Anything you can provide that supports this requirement would be helpful, thanks!

If you email me temporary FTP details, I'll send you the beta zip.

You said you were using SMTP. Roundcube probably doesn't use SMTP.

Something must have changed someplace. No firewall issues?

LOL

Config options should display in the order they are set. Go to Packages > Options > Groups. Click to expand your configurable option group to display all the options. Hover over and you'll see an icon on the left of the options, you can drag and drop to sort them here into the order you prefer.

Ok, let's add it back then. CORE-1411

I don't recall why we would have added, and then removed it. It seems like it should be there, do you know what our reasoning might have been?

The bottom line is that there's no 1 software option that's best for everyone. Blesta has a ways to go before it will support all the same gateways and modules as our competitors, and we prioritize development based on demand. WHMCS has had the advantage, a large customer base and plenty of revenue. Yet, they have gone years now without adding any significant new features. Virtually all of their new features and integrations are sold by Modules Garden, a third party developer who was offered an exclusive deal in order to limit competition in the market. The fact is, WHMCS is in damage control and has been for a long time now. As for Blesta: One release at a time. Out of all the products available, Blesta is the best written, the most stable, and has the best track record on security. That's a solid foundation we continue to build on, and we have a lot of great things planned for the future.

I'm picturing colored statuses for each service that's being monitored in the client area or front facing page. <span class="label label-success">OK</span> <span class="label label-warning">Warning</span> <span class="label label-danger">Critical</span> Edit: I would also suggest caching the results for a period of time so that a lot of traffic won't cause a lot of requests. This could otherwise be used to cause a sort of dos attack. On page load, check cache. If cache is expired, query servers. If cache is not expired, serve from cache. Keep the cache for a minute or so.