Paul

Can you provide a screenshot or steps to duplicate?

It's certainly possible, but we have not implemented anything yet.

After making a change to padding and padding character, did you create a new invoice?

If you are using suPHP then it would be writable so long as owner is writable. In app/controller/install.php I wonder what would happen if you bypass the key generation. Would you mind giving this a try? Comment out lines 270 and 271 and statically set $system_key to something. // Generate a sufficiently large random value // Loader::load(VENDORDIR . "phpseclib" . DS . "Crypt" . DS . "Random.php"); // $system_key = md5(crypt_random() . uniqid(php_uname('n'), true)) . md5(uniqid(php_uname('n'), true) . crypt_random()); $system_key = "somethingrandomtotestwith"; Then run the installer, does it populate config/blesta.php's database details?

Thanks for confirming. I've updated the manual to display both methods http://docs.blesta.com/display/user/Support+Manager

I believe we talked about this early on in development, and architected the login system to be able to support this later without too much trouble.

You can, just change the path to pipe.php to index.php, make sure to keep all the other parameters. Yes, so long as the server handles mail for the primary domain.

The logicboxes issue was related to missing security certificates on peoples servers to verify SSL hosts with curl. verifyhost and verifypeer in the curl request was subsequently disabled. I believe this was disabled for Namecheap as well. Verify that there is not a firewall blocking egress connections to the Namecheap API, and that all login details are correct.

pipe.php was created in an attempt to resolve this issue. Previously it was piped to public_html/index.php and people had trouble because there was no hashbang in the file. Some people allowed cPanel to add the hashbang itself, and got it working but this seemed less than ideal, which is why we created pipe.php. Email piping and the way various different panels implement it in their UI seems to vary.

These would be good feature requests, and I would just move the thread but it's better if there's 1 request per thread.

Looking really good, thanks for sharing and glad you're happy with what we've done!

We don't mind.

I would do a backup of the database after you do a fresh install. Then, you can just restore the database without having to do a whole new install.

Please provide steps so that we can try to duplicate the issue.

I think this is a result of a missing mbstring extension. If you install mbstring in your php, it should resolve it. I have assigned this to CORE-680 as I don't think we want mbstring to be a system requirement. If we have to use it we may have to check for it before allowing GeoIP to be enabled.

i'm not sure this is a bug, Blesta is attempting to use the language define to display the language, which is the intended purpose except that a language define does not exist.

Try this.. Try the following to enable debugging during import. Then attempt to import again. Open /config/blesta.php and change (line 11): Configure::errorReporting(0); to Configure::errorReporting(-1); Then open /plugins/import_managers/components/migrators/blesta/2.5/blesta2_5.php and change (lines 199-201): //echo $e->getMessage(); //echo $e->getTraceAsString(); //continue; to: echo $e->getMessage(); echo $e->getTraceAsString(); die;

If someone answers, and their answer provides a resolution to the OPs question then mark it as solved. This helps other people who may be searching for a similar issue.

We'll post it as soon as there is something to test. I don't have an ETA yet, we've been fixing any bugs that have surfaced this week and are preparing to release a patch sometime next week.

suPHP is not a requirement, but it does eliminate many permissions issues. Still, I'd like determine the cause for what he is experiencing so we can debug it and implement a fix.

I'm guessing this was not compiled with suPHP? Just to be clear.. 1. Before install, you set the config directory to 777, and blesta-new.php to 666. 2. After you attempt to install it renames blesta-new.php to blesta.php but doesn't do tag replacement on database variables Question: What are the permissions of blesta.php after it is renamed? Is it still 666 or something else? If it's not writable by the web server at that point, my guess is that it may rename the file first and then attempt to do the variable replacements but it can't because it's no longer writable. If this is what's happening, we should be able to look into a fix. Can you confirm?

At this point I'm not too concerned about it, most licenses are unbranded since only orders after the 14th could be branded.

Yeah, that's why. In the past people have purchased a single license and installed dozens in sub-directories for their clients to use.

We may have it automatically remove branding on unbranded licenses in the future.

It looks like they may have written the modules for the other billing apps. I wonder if anyone has asked them for Blesta support? If they built these other integrations, they may be interested in doing so for Blesta as well.