Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45361
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain MIT.EDU designates 18.7.7.80 as permitted sender)
Content-Type: text/plain; charset=UTF-8
To: internals <internals@lists.php.net>
Date: Mon, 24 Aug 2009 17:46:33 -0400
Message-ID: <1251149348-sup-4709@javelin>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
Subject: Per-directory PHP configuration
From: ezyang@MIT.EDU ("Edward Z. Yang")

Hello all,

I cooked up a patch that gives PHP support for per-directory
php.ini files that properly inherit.  This makes php.ini files
act a little like .htaccess files.  We are cognizant of the associated
performance issues, and thus this is a strictly optional feature.

For a little history, the current, common approach
is to set PHPRC to be the current directory, so that a php.ini
file from that directory is read.  This unfortunately also overloads
the global php.ini file, has an odd ordering with respect to php.d,
and means that you have to place a php.ini file/symlink in every
directory where PHP scripts could be run.

While the patch is no where near where I would be comfortable
formally submitting it for review on internals, I'd like to gauge
how friendly the core PHP developers would be to an enhancement like
this.  In a nutshell, here is how the patch works:

In php_ini.c, php_init_config() is patched to call php_user_init_config()
if user directory php.ini's are accepted.  The function then:

1. Retrieves the current working directory
2. Checks if the cwd is inside the user's home directory
3. Successively walks up from the user's home directory to the
   cwd, checking if a php.ini exists and loading it with
   zend_parse_ini_file if it does.

We also have two special cases of behavior that we found helpful for our
use-case:

 * We serve only a user's ~/web_scripts directory, so perform an optional
   check to make sure the PHP file is in the right place, and to not
   attempt to load ~/php.ini

 * If we had Apache frob $HOME such that it points to a "different" home
   directory, which is the web serve directory, skip the previous check.

To get an idea for its behaviors, take the following example:

/etc/php.ini
    foo = 1
    bar = 1

/mit/user/web_scripts/wiki/php.ini
    foo = 2

Then, we see the following behavior for the following PHP scripts

/mit/user/web_scripts/test.php
    foo = 1
    bar = 1

/mit/user/web_scripts/wiki/test.php
    foo = 2
    bar = 1

/mit/user/web_scripts/wiki/subdir/test.php
    foo = 2
    bar = 1

I am looking forward to your comments, and I can post the very rough
(but functional) patch if you are so interested.

Cheers,
Edward