Paul

Is that what you really see? LOL, looks kinda familiar. No, site looks normal, very blue

What module is this? If you're using a domain registrar module, you should do the following: Create a Package Group specifically for domains. Call it "Domains", if you want. Create your Domain Registration packages, one for each TLD (is possible, though each price point is ok), add them to the above group. Use the "Domains and Other" order form type Packages > Order Forms. Select your Domains group from the drop down. Select all other hosting groups you want to offer in the multiselect but NOT your domains group During checkout, there will be a whois with TLD selection.

localhost, that is bizzare. Maybe the links weren't corrected before uploading from a local environment? Relative paths man, relative paths!

It's likely we'll be adding a text area you can paste that into in the future, but follow Mike's instructions above and you'll be set.

We upgraded phpseclib in v4, and I believe the license manager module ships with an older version of phpseclib. Do you think it's possible this is the source of the issue?

To be sure it's not an issue with v4 beta 3, would you be willing to test it on 3.6.2?

It probably won't make a difference. If there's an invalid signature, that would explain the null response. Might be something wrong with your implementation.

Have you tried license_manager-2016-08-02.zip? I don't see any reason it wouldn't work with 4.0

You have a bad tag or conditional in the Welcome Email section. Make sure any tags you use are accepted. You may test by removing all tags, and slowly adding them back if you aren't sure.

Can you check your email logs for the piped email? There may be a more descriptive error in there. Also, triple check that PHP has mailparse, both for Apache and the CLI version. If you SSH in you can run this to check: php -i | grep mailparse You should see something like: mailparse support => enabled Not only should "uploads" be writable, but so should the sub-directories in there, including 1 and 1/support_manager_files. The path stored under Settings > System > General should begin and end with a forward slash, and point only to the uploads directory. ie "/home/user/uploads/"

Blesta 4 support?

The Rotation Policy is how long certain logs are held before they are rotated out. The default of 30 days is best for most people. Some logs like the mail log are never rotated out. Don't manually truncate log tables from the database or you could run into trouble.

Attachments (at least for the included Support Manager) are stored in your uploads directory, which must be set correctly under Settings > System > General. /path/to/uploads/ Inside uploads should exist a directory named "1", representing your first company. Inside "1" you should have support_manager_files /path/to/uploads/1/support_manager_files/ Inside that is where Blesta tries to write ticket attachments. Ensure that the directory exists, is set under Settings > System > General (Just to ~/uploads/), and that it's writable.

You can just update your license key with your new paid key, no need to update files or re-install.

That would be nice, yes. Not sure if a feature request exists for that, but the topic has come up before.

I don't have any direct experience with Cachet, but have been contemplating doing an install and playing around with it. What I've seen I like. https://cachethq.io/

Please take a look at https://www.blesta.com/development/ You can receive one or more quotes from various 3rd party developers.

Remove everything after pipe.php, and make sure the path to PHP is correct. cPanel will likely do several things: 1. Add the correct hashbang to the top of pipe.php 2. Make the file executable (chmod 755) 3. Strip off the path to PHP at the beginning of the forwarder Next, time for testing. Don't worry about missing folders, they are parameters and do not correlate to the file system.

Did you look here? https://docs.blesta.com/display/user/Support+Manager#SupportManager-email-pipingEmailPiping Actually setting up piping on your server can vary from server to server. We give an example of doing this manually on a server with no control panel. If you have a control panel, you'll likely set up piping through it instead.

ACL Permissions are access permissions. They are group-based. Go to Settings > System > Staff > Staff Groups, edit the group. You'll see a list of all ACL permissions, make sure that you have permission to what you need. When you install a new plugin, usually your group is granted permissions to the plugin. However, if you have multiple groups, you may need to grant permissions to others who need access. By default, for security purposes, access is not automatically granted to all staff groups.

We aren't going to convert file based templates to database based templates.

If you modify a file in Blesta, then upgrade Blesta by uploading the files over your existing install, then yes, it would be overwritten. This is why I suggest creating a NEW CSS overrides file. This way, all you have to do is add back your include in structure.pdt which would take all of 1 minute.

So an option when editing an Addon Package Group, to only allow it to be added to an existing service? Meaning, you could not buy it during order form checkout, but only after the parent service has been provisioned?

It's likely there will be an option to add custom CSS or JS via the UI, near "Settings > Company > Look and Feel" in the future, but it's not a high priority right now.

In an ideal world, it would be great if everything was open and audited with our seal of approval. Because Blesta is extensible, 3rd-party developers can create their own extensions. Those extensions are therefor their own intellectual property. So, they can choose to license it how they wish, encode it or not, have it audited or not, etc etc. If we were to put strict rules on 3rd-party extensions, it would result in fewer such extensions being available and still be no guarantee that the ones available, and audited, with our seal of approval could never be exploited. There is some risk with any software, so it's up to people to assess that risk and make decisions on what to use. I like the idea of an optional, paid "Certified by Blesta" process for extensions, because it's voluntary and ensures people that the code was reviewed by Blesta developers and meets our standards for security or code styling. This can add value to 3rd-party extensions by creating a level of trust with users, but there would be a cost associated and it wouldn't make sense for obscure or open source extensions. "Certified by Blesta" is not something we would require though, because it would have a negative impact on the availability of extensions. We want to make it as easy as possible for 3rd parties to create more extensions, not less.