vrt

Well that sucks ... I guess the name Auto-Update made me trust in it a bit to much, lesson learned. Of course it was on the only server i didn't set up and they forgot to include the froxlor db in the weekly db backup. I think i try to install php 7 then beside php 5.6. If i remember correct it was php-fpm on an other debian jessie server that let me choose which site runs with which php version. I could run froxlor with PHP 7 then and change the other sites one by one to php 7. Really bad timing, i had plans for summer 2020 to do that.

That's easier, thank you didn't think of that. What do you mean with "run the updater" ? I completly installed over "Auto-Update". It finished with a lot of "OK" Messages and that's it.

Are there known problems If i copy the froxlor folder from an old server. Should work if there are no database changes and i could at least win some time to try it on a local copy.

I have multiple systems running on php 5.6 and today i used the auto-update function on one server. Now i can't edit / manage anything (Null coalescing operator). .. If it's clear the update won't work with php 5.6, there should be a check if froxlor runs on php 5.6 and there should be at least a warning. I'm forced to do an update to php 7 now if i want to use froxlor again but on a productive server with a lot of sites it is an experiment. EOL or not, the php version check is an must have.

Just, if anyone runs into the same problem, i tried another idea today. I replaced /usr/sbin/sendmail with an script: /usr/bin/yoursendmailalternative -optionalparameters $@ That will give the parameters to the sendmailalternative and doesnt't require to change source code in froxlor It works and as far as i see there are no other problems.

I don't know what you mean with editing the php-config, we have our sendmail alternative there as global setting, but that wouldn't make any difference because the vhost setting will still enable sendmail for the customer. I patched the file, but on a froxlor update it will be overwritten i guess.

Hello, thanks for your answer, we use xinetd proxys for pop + smtp. We have 500+ users with their domain names as smtp and pop / imap in their email programs (don't ask me why ...). Thats why we use proxys as "gateway" to the other server. Im not sure if that works with the postfix relay server, but i will check if it fits our needs also. I see what you are trying to do with this setting and it is a good idea but in our case the customers emails aren't up to date in froxlor (we migrate from an older froxlor/syscp version). Only as suggestion, if you don't mind: Instead of adding postfix hardcoded, adding the original sendmail_path setting from the php.ini with the added email parameter should help to fit sendmail alternatives also. Best regards, i love froxlor btw. great work

Hello, maybe i'm blind, but is it really impossible to disable the automatically added "php_admin_value sendmail_path" setting in the vhost. I have no postfix on my server and send mails via msmtp (added as sendmail path in php.ini) and this: $php_options_text .= ' php_admin_value sendmail_path "/usr/sbin/sendmail -t -f '.$cmail.'"' . PHP_EOL; ( In cron_tasks.inc.http.10.apache.php) overwrites my settings for every domain. I don't see any possibility to change this behavior with php enabled. This should be an option, because not everyone that runs a webserver runs the mailserver on the same machine. I can change it in the script, but i think it will be overwritten on next update.