php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45489 Additional .ini filre directory should not be a constant
Submitted: 2008-07-11 20:16 UTC Modified: 2008-07-11 20:37 UTC
From: edwin at cheatah dot nl Assigned:
Status: Not a bug Package: *Configuration Issues
PHP Version: 5.2CVS-2008-07-11 (snap) OS: *
Private report: No CVE-ID: None
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
50 - 42 = ?
Subscribe to this entry?

 
 [2008-07-11 20:16 UTC] edwin at cheatah dot nl
Description:
------------
The directory for reading additional ini files is hardcoded (declared as a constant). The base php.ini location is configurable, the additional ini file dir isn't.

Compare:
php_ini_opened_path
PHP_CONFIG_FILE_SCAN_DIR

Why they should BOTH be configurable:
What if I want to have multiple HTTP services with just a single set of binaries?

I may want to have serveral httpd.conf files, and have an Apache process started with different configuration files. In these files I could want to use the PHPINIDir directive. This works fine. The problem is that phpinfo() keeps whining about the "Scan this dir for additional .ini files" It's impossible to override this setting. Quite silly as we can easily have multiple php.ini files for different goals (cli, http, etc).

So first of all this should be configurable (and why not in php.ini?)
Systems must be able to have multiple "instances" of PHP running without actually having to compile separate binaries for different goals.

Reproduce code:
---------------
n/a

Expected result:
----------------
n/a

Actual result:
--------------
n/a

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-11 20:37 UTC] jani@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #45114
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Dec 04 21:01:29 2024 UTC