NYCPHP Meetup

[Gerald Timothy Quimpo]

On Monday 16 December 2002 03:00 pm, George Webb wrote:
> 	Since PHP scripts usually are quite configuration-
> dependent, it would make sense to distribute a PHP application
> with its own (per-directory) php.ini file.  Perhaps a
> "configure" -type script could generate this file during
> the install process.

i think i mis-wrote because i misunderstood something. the 
documentation talks about: PHP_INI_PERDIR. so i thought 
that meant that if you put a php.ini in each directory,and if 
you only overrode items which are overrideable, then your 
new setting would override the system setting.  it's not so simple. 

0.  local php.ini files (i.e., files with php directives, 
    named php.ini, in the same directory as the
    php programs) are not used.  php directives in
    that file are ignored.  I haven't done an strace
    (since stracing httpd is a major pain :), but
    changing settings in the local php.ini file
    does not change any behavior.

1.  the documentation discusses using .htaccess with 
    php_flag <setting_name> <setting_value>.

    e.g., for register_globals, we say:

    php_flag register_globals on

    This works on apache for settings which may be set on
    PERDIR basis.  I see no discussion of how to achieve the same 
    effect when using other web servers (google might know, but I'm 
    not online as I compose this).

The documentation clearly states that register_globals cannot be
modified by ini_set (and this is perfectly reasonable and understandable).
However, if there is no universal way (e.g., through local php.ini files
instead of server specific special configuration files) to do PERDIR
settings, then distributing configuration files with applications is not
feasible.

And if, as seems likely, there is no equivalent to .htaccess php 
specific perdir settings for some web servers, then there is no way
to solve at least the register_globals problem for all web servers.
most other settings can be modified by ini_set.  So previous comments
on how mature applications should clean up their environment by 
using ini_set and adapt to their environment via ini_get and 
ini_set are definitely correct.  but not everything can be solved
that way.

it will probably be necessary to rewrite any applications that depend 
on register_globals.  this is obvious and should be done anyway for
reasons of security.  unfortunately, it'll probably be a while before the
major PHP applications will be ported.  and it's likely that some won't be
ported and will, instead, require their users to run apache (so they can
use .htaccess) or run on servers which have register_globals on.

> 	If the distribution did not contain one, perhaps
> you could ask the author for his/her own php.ini file to
> use as a guide for your troubleshooting.

Yeah.  I'm looking at five PHP helpdesk/bugtracking packages
I'm testing and none have php.ini files.  

initially i was just assessing the different packages to see which i might
want to use.  i couldn't even assess them since none would run
without register_globals.  I think i'll just test them on a separate server
(running on the same box, but on a different port) that has register_globals
on, and then, once i've made my choice based on features, i may work
with the author to make it less reliant on register_globals and generally,
able to adapt to its environment (thus making it easier to install).

thanks for all the comments.  this discussion has been enlightening.

tiger

-- 
Gerald Timothy Quimpo  tiger*quimpo*org gquimpo*sni-inc.com tiger*sni*ph
Public Key: "gpg --keyserver pgp.mit.edu --recv-keys 672F4C78"
         Pobrecito mexico tan lejos de Dios y a la vez
		 tan cerca de los Estados Unidos
		                 Gen. Porfirio Diaz