NYCPHP Meetup

[Bradley Baumann]

Gerald,
    I'm afraid there is no "real" definite solution to your issue, you can
look into the code, and try to tweak it so that it would work -- but there
is no magical code that you can feed it to make everything work. The problem
is incompatibility, and where there is compatibility issues, there is always
lack-of-thought. Not your fault.
    Given that it is a common issue, that effects more then what you're
saying here -- I'm sure your comments would be welcomed by the developers of
whatever software you are using. I suggest dropping them a line, and seeing
what they have to say about it.
    Not too much more can be done, since we don't live in a perfect world.
Sucks, eh?
-Brad.

----- Original Message -----
From: "Gerald Timothy Quimpo" <gquimpo at sni-inc.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Monday, December 16, 2002 1:53 AM
Subject: Re: [nycphp-talk] PHP version compatibility standards


> On Monday 16 December 2002 12:54 am, Bradley Baumann wrote:
> >     There is no direct, easy way of making everything compatible with
> > everything else. It's not your fault, obviously -- it's just a lack of
> > thought on the other programmer's side.
> >
> >     Changing the php.ini file around on the fly for specific
applications
> > isn't really a feasible idea, and I realize that. It's an age old
problem,
> > and it just boils down to programmers writing crappy, incompatible code.
>
> i was looking at ini_set, but i don't think ini_set will do anything about
> register_globals. by the time ini_set is called, even if it resets
> register_globals (untested), it won't do it because the globals will
> already have been or not been registered (purely theoretical...
> i am entirely open to correction on this one :).
>
> i'm trying to think of a good way to approach this.  some obvious
> approaches (starting with the most common, register_globals :):
>
> 1.  for any configuration issue/parameter that can be handled by
> Directory specific php.ini's, provide a directory specific php.ini.
> e.g.  register_globals is indicated in the PHP documentation to
> be PHP_INI_PERDIR or PHP_INI_SYSTEM.
>
> ** EXCEPTION ** unfortunately (i have not read any specs, just
> tested on my box), it looks like, if PHP_INI_SYSTEM's setting is *set*,
> then PHP_INI_PERDIR does not matter.  that is, it's ignored.  can
> anyone confirm? so, in order to use a register_globals = On in per
> directory mode, the global register_globals setting needs to be
> undefined?
>
> 2.  for register_globals, perhaps a standard function to call which
> does what register globals does.  or which just registers the
> variables in the current scope (e.g., via extract) if the function
> is called within a function, in which case it should not register
> a global).
>
> 3.  other functions (mainly calling ini_set(...) probably) which programs
> can call from some include file.  e.g., init_compat.inc.php or something.
> the init_compat.inc.php just sets user-settable things which override
> global php.ini settings.
>
> what other approaches might work?  and will software authors (e.g.,
> the author of php-nuke, MOT (Ministry of Truth), otasks, phphelpdesk,
> PHPTroubleTicket, techtables) accept such suggestions?
>
> heh, i'm willing to assume the last.  in any case, i figure, if someone
> sends them patches, and the patches work after testing, then perhaps
> they'll get integrated into the final code.
>
> by the way, what debuggers do you all use?  i use DBG and
> maguma studio lite (running under win4lin, which gives me win98/ME
> running on the same linux notebook as the web server).
>
> 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
>
>
> --- Unsubscribe at http://nyphp.org/list/ ---
>
>