PHP behave weirdly with local configuration
https://askubuntu.com/questions/1556065/php-behave-weirdly-with-local-configuration
Had php-fpm on Ubuntu 20.04, switched to Xubuntu 24.04.
First, PHP seems to ignore .user.ini. Every thing thing has been checked: all configuration files in /etc and access rights on all the path going to the .user.ini file. It was working normally with Ubuntu 20.04. php_info() confirms the values set in .user.ini are ignored. More strange to come.
Tried with a local php.ini instead: not better.
Tried to set the configuration flags and value in .htaccess although it seems to be obsoleted now (unless I’m wrong): php_info shows the good local values, however entirely ignores it. Ex. it says display_errors is On, but it does not apply, similarly with log_errors and error_log, nothing is written to the specified error log, although php_info() says it knows the values. This is not an issue with group/owner/permissions, it was checked and it is the same as was with Ubuntu 20.04, and was applying fine. PHP and Apache had been restarted many times.
Again weirder: if I remove the lines from .htaccess it writes to another error log which is specified globally. If it is set locally, it says it knows it, but write to no error log file, either the local or the global one, it makes it ignore error logging entirely.
Searched the web many days for that, tired of it, though it was working with .htaccess (although would prefer .user.ini to be better organized), but it just shows the value and ignores it.
It must be either something obvious I am missing or a weird corner case no body or very few knows; searching and reading multiple pages line by line did not help.
It seems it works only if set globally under /etc/php/8.3/.
What would be nice, would be a way to debug step by step what PHP is doing and where it fails, but I don’t how to do it or even if it can be done.
Versions:
- PHP 8.3.6 (cli) (built: Jul 14 2025 18:30:55) (NTS)
- Server version: Apache/2.4.58 (Ubuntu)
- Server built: 2025-08-11T11:10:09
- Ubuntu 24.04.3 LTS (although it really is Xubuntu)
Checking Apache version, I noticed I had to invoke apache2ctl to get it right, because apache2 returned an error about a missing APACHE_RUN_DIR environement variable being not defined. But I really have to sudo service apache2 restart because apache2ctl is not the name of a service. I feel to guess this issue is not related, while still mentioned in case it may be meaningful.
Update 2025-09-14:
The only way I could get PHP use a per site INI file, is adding a directive for it in the virtual host:
<VirtualHost 127.0.0.2:80>
ServerName ....
...
PHPINIDir /home/xxxx/.../public_html/.php.ini
</VirtualHost>
(idea after this french web-site: mettre un php.ini spécifique pour un VirtualHost)
Each time .php.ini is modified, a sudo service apache2 restart is required.
It still reads the INI files in /etc so it does not break the configuration. php_info() now sees all configurable properties as “local value” and “master value” at the same time. Ex. the value for error_log is the same for both. I made this an opportunity to rename .user.ini into .php.ini, which is more meaningful. Unlike php.ini (without a leading dot), it will apply on all directories of the virtual host, with no need to copy it in each directory.
When I said it was writing to another error log, it was the one defined for Apache in the same virtual host, so it was not really a PHP error log file, rather an Apache error log file. This means when PHP was not writing to it anymore, it was not logging error via Apache anymore, I guess.
The practical case is solved, good enough to be said better than a mere workaround, but the initial issue is not, which is to explain why PHP behave so strangely.
Be careful with comments, which may break the configuration file. It's better to have few or none.