I'm going to try this again. For some reason, it wiped out all of my work because it said that the content contained a banned word - the common name for an attorney. (which I hadn't put in my post anyway. ) Unfortunately, I don't want to spend the next 40 minutes recreating everything, so I'll type this up shortly. Vtiger wants three special variables set in php.ini. Two of them took just fine in the custom php.ini field. error_reporting, however, is apparently ignored somewhere. phpinfo() just shows error_reporting's value is 2. Yay! Very Useful! checked custom php.ini in /var/www/conf/*/php.ini. _two_ error_reporting variables ISPConfig shouldn't do that. It should have _one_ variable definition, not twice. That's bad programming. Checked the cgi php.ini - commented out error_reporting. Ignored. edited all three php.ini files. Ignored. In fact, when I edited all three php.ini files to have the correct values for that one site, then cleared the custom setting out of the custom php.ini field? It generated this: error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT THIS IS NOT SET IN ANY PHP.INI FILE ANYWHERE. This was STRICTLY generated by ISPConfig all on its own.
I also checked phpinfo() for the path it's using. It's using the correct path for 7.0, not the leftover for php5. Does ISPConfig, internally, keep trying to use the php5 ini files?
It is absolutely fine to append values in ini files as values further down override values above and these files are not for manual editing, so it does not matter how often a value is specified. These files consist of the master php.ini file as specified by you under system > server config plus the custom config appended that you have set in the website. That's complete nonsense, ISPConfig does not set or modify this value on its own for websites. ISPConfig sets error reporting for its vhosts on port 8080 and 8081 only. If you want to know which php.ini files PHP is using, use the phpinfo() function, it will show you all used php.ini files.
No, it's not nonsense. If the howtoforge system hadn't purged out my post by claiming it had a forbidden word in it, you'd have that information. I've _used_ phpinfo(). I can post the multipage result if you want. It claims that the site was using the /etc/php/7.0 php.ini files, as well as the custom php.ini. The point is that I removed all of the error_reporting lines from _all_ of the php.ini files, including the custom fields. Then regenerated the custom fields. _ISPConfig_ reinserted an error_reporting line. Which didn't exist anywhere. It decided _on its own_ to populate the error_reporting variable. When I reprogrammed all of the php.ini files to use exactly what I wanted? It generated the _same_ error_reporting variable - error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT In other words, somewhere inside whatever functions ISPConfig uses to build the custom php.ini is something about error_reporting where it forces the above line, even if you've told it to use something else.
Where do you see that line: error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT in the generated custom php.ini file or in phpinfo() output?
Here a small script, you said that this error reporting level is set by ispconfig? then it must exist in the ispconfig sources. You can easily test this with a grep command: grep -r -n 'error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT' /usr/local/ispconfig/ as you will see, this is nowhere in ISPConfig. As another test, you can search for error_reporting in general: grep -r -n error_reporting /usr/local/ispconfig/ You will get a result like this: root@server1:~# grep -r -n error_reporting /usr/local/ispconfig/ /usr/local/ispconfig/server/cron.php:65:ini_set('error_reporting', E_ALL & ~E_NOTICE); /usr/local/ispconfig/server/lib/classes/tpl_error.inc.php:36: if (!($level & error_reporting())&& $level != KILL) return; // binary AND checks for reporting level /usr/local/ispconfig/server/cron_debug.php:36:ini_set('error_reporting', E_ALL & ~E_NOTICE); /usr/local/ispconfig/server/server.php:56:ini_set('error_reporting', E_ALL & ~E_NOTICE); /usr/local/ispconfig/security/check.php:35:ini_set('error_reporting', E_ALL & ~E_NOTICE); /usr/local/ispconfig/interface/lib/classes/tpl_error.inc.php:36: if (!($level & error_reporting())&& $level != KILL) return; // binary AND checks for reporting level /usr/local/ispconfig/interface/lib/classes/simplepie.inc.php:9323: if ((ini_get('error_reporting') & $level) > 0) /usr/local/ispconfig/interface/lib/app.inc.php:39: @ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_DEPRECATED); /usr/local/ispconfig/interface/web/datalogstatus.php:31:error_reporting(E_ALL|E_STRICT); /usr/local/ispconfig/interface/web/sites/aps_meta_packages/modx-revolution-2.3.3-56.app.zip/APP-META.xml:69:- Set default error_handler_types to error_reporting() /usr/local/ispconfig/interface/web/sites/aps_meta_packages/Coppermine-1.5.42-60.app.zip/APP-META.xml:98: <entry>added error_reporting</entry> /usr/local/ispconfig/interface/web/keepalive.php:31:error_reporting(E_ALL|E_STRICT); This shows you that a) no error reporting is set for websites by ispconfig as all these places are for ispconfig itself (port 8080) or the apps vhost and b) that nowhere this exact error reporting level that you claim to be set by ispconfig is used in ISPConfig
That's the original line from the original php.ini files - all three of them in the /etc/php directory. It then showed up in the custom php.ini (as stated above, as a redundancy) Unfortunately, as I said before, phpinfo() just says that error_reporting returns a value of 2. Absolutely worthless. When all three lines were rewritten to be error_reporting = E_WARNING & ~E_DEPRECATED & ~E_STRICT (as well as E_ERROR), the custom php.ini _still_ generated the E_ALL & ~E_DEPRECATED & ~E_STRICT - but not the E_WARNING line that was in the /etc/php files. It ignored that completely. When putting in error_reporting = E_WARNING & ~E_DEPRECATED & ~E_STRICT into the custom php.ini field, the custom php.ini was generated - with an E_ALL line. Then, at the bottom, it had the custom line - and apache ignored the custom line. When I wiped out the error_reporting option in the various php.ini, and deleted it from the custom php.ini, so it should have created a php.ini with _no_ error_reporting option.... It generated the line error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
What I'm saying is that it appears that ISPConfig is drawing the initial construction of the custom php.ini file from somewhere _other_ than the php.ini files. Like it's building a 'default' PHP.ini file, then adding a customization to the end. From where does it draw that initial default configuration? As I did grep through the entirety of ispconfig AND all of the /etc/ folders, and found no uncommented mention of it.
See post #6, this line does not come from ispconfig. It is either in the base php.ini file that is configured under system > server config or you must have set this in the custom php.ini field of that website.
That's not the case. ISPConfig simply uses the php.ini file that you specified in server settings as the basis for the custom file. See System > Server config > web and system > server config > fastcgi and if you still don't know where that php.ini is, use: grep -r -n 'error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT' /etc/ to scan all files in /etc for it.
Oh for crying out loud. You obviously didn't really read what I wrote. I already did all of those searches, and one of my questions was if ISPConfig pulled from other locations other than the system defaults. You _finally_ answered that. Yes, apparently when php was upgraded, ISPConfig continues to draw from the originally _automatically_ set settings, which are not re-checked during upgrades. FastCGI has its own stored location - which I've now corrected. I'd suggest a quick check for versions of php in the upgrade script. Especially with the huge jump from 5 to 7. Ubuntu/Debian has apparently moved from /etc/php5 to /etc/php/7.0 (and so forth) Oddly enough, I tried the other various php options, and none of them were willing to obey the custom php.ini at all. (well, maybe suphp, but I wasn't up to compiling that after three hours of screaming at a server) Thank you for the answer. Hopefully this will help other folks that have upgraded their servers from php5 to php7.
You should have really read my first answer as it already contained the whole solution of your issue. I said that your claim that ispconfig creates config settings out of the blue is nonsense and it is in fact nonsense, as you found out now. Believe me, I know the ISPConfig code a bit. I told you in my first answer that you should check the settings under system > server config as the php.ini is pulled from there and apparently you did not do that. These settings are set once during installation, they are not and shall not be altered by the updater as many users choose custom settings there and if the updater would override them, their systems will fail. Also installing an additional PHP version does not mean that the system php for ispconfig changes. When you choose to update PHP on your server and use a different path than the one used at install time for this new PHP, then you as the administrator have to take care that the environment settings of the new environment that you have built are reflected in the settings. Custom php settings are supported by php-fcgi, php-fpm, php-cgi and suphp, but not all of them use the custom php.ini file, e.g. php-fpm has custom settings in it's pool file. So all options except mod_php support custom php.ini settings and the reason that mod_php does not support them is mod_php itself and not ispconfig. Thats described in the manual btw.
I appreciate the need to support and not break custom configurations, but when running through dist-upgrades on ISPConfig systems and changing php5 -> php7, I also thought the installer could probably do a bit more to detect when the system php version was changed and offer to update the settings to the new defaults. When first installing ISPConfig you don't do anything to set those, they just get default values appropriate for the OS - when upgrading php versions along with dist-upgrade I was a bit surprised the first time I ran into needing to track those settings down and update the configuration, as it's not something I had set in the first place. I think I actually installed a debian9 perfect server from scratch explicitly to look up those values and php open_basedir to make sure I had them correct, which sure felt like a lot of work to update what I had thought was a "use system defaults" type value. I'd be happy to log a feature request for that. It seems like tracking a "use system defaults" vs. "use custom settings" for php settings would be easy enough (an explicit checkbox would work fine), then the installer could keep those updated, making occasional upgrades just a little easier.
Well, I made https://git.ispconfig.org/ispconfig/ispconfig3/issues/5310 but accidentally left the "confidential" setting enabled, and I don't see a way I can disable it. I can either create a new issue and delete 5310 or maybe you can fix it, @till - thanks!
