Paul

Tyson responded while I was typing, so just to add to what he said -- We carefully consider every core feature, if it doesn't make sense to be part of the core then it's implemented as an extension. Take a look at the Order System and the Support Manager. Both very well used, often necessary major features.. but we understand that other developers may create something that people prefer to use instead. Some future features -- KB, Mass Mailer, Affiliate System.. all of these will be plugins. (The KB will actually be part of the Support Manager plugin) Some features just make sense to be part of the core and forcing them to be extensions when they shouldn't be would fragment the system and de-stabilize the most basic function of Blesta. I ask the following questions when considering a new feature - 1. How widely used will the feature be? 2. How likely is it 3rd party developers will want to roll their own? 3. How basic to billing and client management is the feature, regardless of how many people will use it? Not that we go through a checklist, but this should give you an insight into our thought process. It's usually very apparent to us when something should be part of the core or not.

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.