cloudrck

It's just the initial email. The staff reply uses the correct email. It really should use the overridden email. I have my email server setup to only allow SMTP through approved domains. And the domain that Blesta picked wasn't one of them.

When someone emails a ticket desk, the sender's 'ticket received' email uses the FROM email that is set in the email template, rather then the override email address set. Even with this set, it ignores it for the person opening the ticket via email. However, the staff assigned to the desk gets an email with the correct overridden email address set. So the bugs is that for people sending emails to open tickets, they receive confirmation with the incorrect FROM address. Blesta v4.3.1 PHP 7.0

This works in Nginx.

What does your Nginx configuration look like? You also shouldn't be accessing Blesta via sub.domain.com/index.php/ unless your Nginx configuration is incorrect. It should be accessible simply via sub.domain.com/ Test using a developer account rather than hoping for it to work correctly.

I can't recreate the error. There must be another issue amidst. Did you make the appropriate "cgi.fix_pathinfo = 0;" in php.ini

I've had this issue and it turned out to be an issue with the php.ini for php5-cli not having the entry for mailparse. Have your CRON log errors after you remove the lock from the task in blesta For example, my crontab would look like the following. */5 * * * * /usr/bin/php /var/www/blesta/public_html/index.php cron >> /home/me/blesta.txt 2>&1 Disabiling the task does not halt the task. It's still running as Blesta doesn't halt on failure, it continues to "run". You need to add the code to remove the lock (unless it was changed in v4). When you add the code, you have to wait ~60mins, than a link will appear to halt the task so the cron executes that specific task on next scheduled run, as of now your task is locked. Or you can remove the task manually

What emails are you referring to? There exists logs at URI /admin/tools/logs/email/

Okay, I had honestly never heard of Hugo until you guys posted it. I'd imagine Hugo is faster since it's written in GO. As far as auto-reload, I believe there is a rubygem/Jekyll plugin for such functionality.

Curious, why did you choose Hugo over Jekyll?

This question actually doesn't make sense. Cron has nothing to do with HTTP/S. Cron is a job scheduler, it doesn't care what your script does and it has nothing to do with any protocol. So there is no https or http mode for cron. The problem is either with PHP or your webserver. It's difficult to help since I don't understand what your script is supposed to do. $this->base_url = "http" . (isset($_SERVER["HTTPS"]) && $_SERVER["HTTPS"] != "off" ? "s" : "") . "://" . (isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : nul) . "/"; It looks like you're reading headers from a remote request. Where is this request coming from? Is it coming from a load balancer? Load balancers will sometimes move the variable you're looking for into a different header. Depending on your webserver you may have to check if the connection is over port 443. Also, try checking if the $_SERVER["HTTPS"] is not empty rather than isset.

Is there more to the error? You check your php/webserver logs? Have you looked at https://www.blesta.com/forums/index.php?/topic/5156-interworx-module-gives-soap-error2/

Check your webserver logs, if the database is too large you may have to tweak settings to compensate for the time it takes for blesta to execute the command. You should have the domain setup with it's own error log file under Nginx. To be honest it might be better to create a shell script that does the backup, and rsync over SSH. I'm looking to implement this on my setup since I'm having issues with Blesta automated backups.

Everything appears as it should be, but the backups are never executed. The user the cron is run under has permission to mysqldump the database. No error logs,

Okay, I can look into it later today. I posted here mainly to verify I was making the correct configuration changes. I will troubleshoot and report back here.

It's set to backup Every Day.

Okay, that's fine. But how am I supposed to get it to work? The documentation is obviously incorrect since it mentions it's a company task.

Yes, I've followed the instructions. It's already configured for daily, but unless I force offsite backup, nothing backups. The cron logs say nothing about backups. The automation page says nothing about backups. So I'm not sure how Blesta is supposed to call the backup script via cron jobs.

Following the directions here. I am told to enable automation, but there is nothing related to backups in [settings] > [system] > [Automation]. So the backup I have configured never runs. Has this automated configuration been moved somewhere else? Blesta v 3.5.3

Ok, actually, that's fine as is.

Okay, this seems like something that should be disabled by default. For: Configure::set("System.error_view", "errors"); What should that be set to to disable the error page? I don't see any of this documented

How do you disable error displays (not logging). There shouldn't be stack traces on pages in a production environment. For example, when there is no database connection, it displays a full trace even though /config/blesta.php has the default: Configure::errorReporting(0);

Ok, thanks

Once I get everything setup I'll be sure to, I'm still in the planning stages. Just one thing, does it come with the source code, or are there plans for Blesta to take on development and make this a standard module? Reason I ask is I would hate to start using this module, only to have it no longer be developed in the future.

Fantastic, I've been looking for this.

You'll probably right. But unless you're developing, there is no reason to not have a SSL certificate for running Blesta. I would hope Blesta intends on changing setup so TLS is expected.