mrrsm

That should be more than enough space. Currently I am using around 4 GB of space for everything on the machine that blesta is running on (OS, db, files, etc). I am hosting downloads from elsewhere though otherwise those could add up as custom packages for people may be a couple hundred mb's a piece. If you are doing design stuff just take into account the size and number of files you may be putting into blesta for your users to download. If you are hosting them elsewhere then it shouldn't be a problem.

The premadekb articles are a pretty good starting place. For $50 is saved me a ton of time as all I had to do was read each one to make sure it sounded right and looked correct to me. It will give you most of the cpanel kb articles you need as well as instructions for updating name servers at many of the popular registrars. They have Softaculous articles as well which is helpful. They didn't cover any of the items that cloud linux uses if you use that but it was quite easy to add a couple more articles for those items.

You are right it should not matter. Are you sure your main httpd.conf is set to load everything in your conf.d folder (it should by default).

I'm guessing this is a linux server. If you check the folders owner:group that does work and use that same owner:group combo on the new folder does it work. After you do that, check the permissions as well.

What Tyson said seems like it would be what you wanted. You may want to change the application_id in the `application_view` and `application_ratings` to be an id (added column) from the `application_versions` if you want to have statistics for each individual version

Same here, I'll need at least a couple months to test and verify that there are no real issues with any of my stuff before upgrading. It is looking like it will be amazing though.

You are correct, it was a bad analogy. My overall opinion stands though

Do you ever change your password? To me this could be the same principal. Another reason I see is if someone gained access to my system but my database was safe I would need to change my encryption key for security reasons. Having a tool, not normally uploaded to your live system, available would be nice to have. Not a high priority for the blesta team, I don't think, as anyone (developer) should be able to create a tool to do this as blesta doesn't hide how it does encryption.

They need your old encryption key, if they have that and your database you are screwed anyways.

+1 I think that having a way to migrate to a new encryption key would be useful

Looks like you already voiced your opiniion on the feature request http://www.blesta.com/forums/index.php?/topic/1453-braintree-gateway/ I personally don't know how payments get migrated if there isn't a matching gateway. An option you have is to hire someone to create that payment gateway for you, there are many capable developers in the community who would probably be able to do it.

What fields do you think shouldn't be encrypted that currently are? Looking through my database only sensitive data has been encrypted such as credit card info. From my going through the code for blesta it doesn't seem like they are storing php code and executing it out of the database so I don't see a worry there. The only thing may be XSS or javascript injection which I haven't tried but I am going to guess the Blesta team tests for so I don't need to worry too much about that.

I personally don't even think it needs to be a setting. Having an uploadable image field should always be there. You can either use it or not use it depending on your needs. If you do use it have the image display (thumbnailed?) in the ui and full page if you click on it both in the admin and client side. Maybe a checkbox to display it to the customer?

If you are using S3 you can set a lifecycle on your bucket which can archive to glacier, delete, or both. Moving to glacier save $0.02/GB (I think that was the figure last time I checked) which I need to keep some backups for an extended period of time so this is nice. However if you don't need them you can set it up to auto remove them after x time which may work for you.

At the same time who knows if PDO will be the way to go in the future (I hope it is though). I don't think it is worth converting mysqli to PDO unless you are doing a redesign that warrants it. To me PDO makes more sense as it seems to be significantly more structured in the object oriented design. mysqli seems to be the hybrid approach, it is OO but feel like it had to make some compromises to support much of the procedural stuff. That is my current opinion at least just finishing up moving a huge core database library for a project from the old mysql extension to mysqli and finally to PDO.

I like your idea Paul, being able to force send the password reset from the admin client page would be preferable.

It doesn't look like mysqli is removed in php7 so you shouldn't have any issues. I personally prefer PDO just because I can almost seamlessly support multiple database types without changing any code.

+1 This is almost always a good thing to have on an invoice (or at least the option to have it)

+1 sounds like a great plan

I think he was talking about quickfile (http://www.quickfile.co.uk/) being free.

A lot of really good ideas. I personally like the license check as I have seen this used with a few other scripts that I have used. A token would probably be a good compromise between nothing and license id. Would there be a step on the initial installation to set this (advanced option or something) or would this have to be manually done? I am guessing it would have to be manually added to existing configs, or handled in an upgrade step somehow to prompt you for the value to add to the config (or tell you to add it if you want).

+1 filling these out manually does kind of suck

I am not sure why you wouldn't be able to authenticate the user in this case still? You are most likely never changing the username/email and password fields in the database for users which means running a query against that shouldn't be much of an issue. On top of that you control the upgrade script, that means you know that schema version (not sure if you track this or not as I haven't checked) which means you should be able to craft a query for any version of the users/groups/permissions tables if they did change. I am most likely missing something though and probably should just look at the code at this point (which is my favorite thing about Blesta).

Human error is possible, you may have backed up the files but not the database. You read the note that said make sure you have a backup so you go to backup the database and it gets ran in that time. Again there isn't much that can really go wrong but why not make it safe? Are you telling me that isn't a security hole though regardless if it is a staff account or not. If one of my support peoples accounts was compromised they normally wouldn't have been able to do much damage unless they took advantage of the bug. Overall Blesta is proactive is protecting people who use their software, they can't be expected to do everything for you but making minor changes that could help people that aren't a lot of work don't seem like a bad move to me. Either way I trust the developers decision will be what is in Blesta's best interest.

I will +1 this. They tell you to take a backup before you upgrade just in case anything goes wrong. If someone comes by and upgrades, it botches itself, I now have no recovery option past my last backup (assuming you are doing them). cli update. If you have access to the server you may as well let them upgrade it There is no such thing as perfect software, as much as anyone would like there to be. Security holes will pop up here and there no matter how hard to try to prevent them. Blesta is great at addressing issues quickly. An example would be CORE-1045. That was a security hole, but they patched it very quickly. Mainly what I am getting at is saying "Blesta doesn't doesn't [sic] do holes" is not putting forth a proactive feeling toward security. Showing that they do have issues but treat them seriously and fix them in a reasonable amount of time shows they do care about security and do their best to keep things secure which is what the majority of people expect. .