Description of problem: Fedora uses /etc/php.d for loading PHP extensions and Zend extension through ini files. If someone uses PHPs ini sections (see http://www.php.net/ini.sections) inside an own ini file in /etc/php.d or in /etc/php.ini this will prevent extension from loading. The PHP manual says: "These sections are used only in CGI/FastCGI mode and they can not set extension and zend_extension directives." So extension= and zend_extension= needs to be under [PHP]. Version-Release number of selected component: PHP 5.3.3-1 Steps to Reproduce: 1. Use PHP over Apache/Lighttpd as CGI 2. Add [PATH=] or [HOST=] to /etc/php.ini (or an own file at /etc/php.d) 3. See phpinfo() for loaded extensions 4. extensions loaded at /etc/php.d won't be loaded Actual results: For example the widely used pdo extension (/etc/php.d/pdo.ini): ; Enable pdo extension module extension=pdo.so Expected results: [PHP] ; Enable pdo extension module extension=pdo.so Additional info: http://www.php.net/manual/en/ini.sections.php#99780
Verified # php -m | wc -l 73 # echo "[PATH=/usr]" >/etc/php.d/test.ini # php -m | wc -l 65 Fix seems trivial, but imply to fix all extension .ini files - from php main package - from all php-pecl-package 16 packages - from other php extensions cups-php graphviz-php ice-php nntpgrab-php php-facedetect php-libpuzzle php-magickwand php-mapip php-shout rrdtool-php syck-php uuid-php From repoquery --whatprovides '/etc/php.d/*.ini' : Is it really a change needed when is so simple to simply add [PATH=xx] and [HOST=xx] in the last ini file, (/etc/php.d/z-myhost.ini, p.e.) ? Joe ?
It could be useful to file an upstream bug on php project to ask to "reset" the section on each new ini file...
From reading the code the section *is* reset to default before reading /etc/php.d so it should not be the case that any section in /etc/php.ini affects the php.d files in any way. Only the latter case of adding a section to a php.d ini file. This is trivial to fix in the code (move down the RESET_ACTIVE_INI_HASH() macro) and that is probably appropriate rather than changing our ini files, unless upstream disagree.
That's not true, I tested it: [root@homebox crash]# php -m | wc -l 54 [root@homebox crash]# echo "[PATH=/usr]" >> /etc/php.ini [root@homebox crash]# php -m | wc -l 32 I'll create a bug entry at bugs.php.net to clarify this bug.
Created attachment 443350 [details] Reset ini hash before "each" file in php.d The attached patch fixes the describe issue - reset ini hash before "each" file in php.d - fix RESET_ACTIVE_INI_HASH (to also reset is_special_section)
@Fabian : what you describe in comment #4 is link to the need to also reset "is_special_section".
Remi Collet: thanks for the fast fix. I've reported this to the PHP developers here: http://bugs.php.net/bug.php?id=52786
@Fabian : if you want to try the fix, please use the test build from http://rpms.famillecollet.com/fedora/13/test/x86_64/repoview/ (php-5.3.4-0.1.201009061630.fc13.remi).
Thanks for the patch, Remi; thanks to both of you for pushing this upstream.
I've applied Remi's patch without change on the 5.3 branch and trunk. Thanks for pushing the report up to us!
I close thid bug as upstream. The fix will be available in next release (5.3.4)