NYCPHP Meetup

[Bradley Baumann]

I don't think that is the question he was asking... although changing the
php.ini file will possibly provide a way of working around the errors he was
having...

The question isn't focusing entirely on the specific problems with those
pieces of software, but more of a standard that he believes should be formed
to keep things current with each other and to ensure that problems like this
won't happen due to previous versions of software, which is an age-old
concern that gets to everyone at some point.

-Brad.


----- Original Message -----
From: "Brian" <brian at preston-campbell.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Sunday, December 15, 2002 9:28 PM
Subject: Re: [nycphp-talk] PHP version compatibility standards


>
> On Sunday 15 December 2002 07:49 pm, Gerald Timothy Quimpo wrote:
> > hello all,
> >
> > I've been evaluation quite a few PHP programs (mainly bug tracking and
> > helpdesk software, but other things too) and I find that there are many
> > problems with version and server configuration incompatibilities.
> >
> > 1.  Version incompatibilities example:
> >      the software was developed on PHP 3.x or 4.0.x.  It depends on
> >      get and post variables being globals (PHP 3.x) or in the
> >      $HTTP_GET_VARS or $HTTP_POST_VARS arrays (deprecated
> >      in PHP 4.2.x).
> >
> > 2.  Server configuration incompatibilities example:
> >      Software was developed for the same version of PHP that it is
> >      to be deployed on, but the deployment server uses safe_mode,
> >      or register_globals_off, while the code assumes that
register_globals
> >      is on.
> >
> > Those are just the most common incompatibilities.  There are many more
> > incompatibilities possible, and combinations of incompatibilities too,
> > since some configuration settings and version differences will interact
> > with many other settings and differences.
> >
> > It is possible (but unpleasant and undesirable) to hack the code to make
> > it work with the deployment configuration.  This is undesirable though,
> > because when the next version comes out, the same code hacking would
> > have to be done.
> >
> > The patches could be sent to the author of the software, but it might
not
> > be applied.  Even if applied, the code gets complicated because there
will
> > be version checks everywhere.  there will also be checks as to whether a
> > setting is set correctly, and if not, then calls made to ini_set(...) or
> > import_request_variables(...) or need to set up per-directory php.ini
> > files, etc).
> >
> > My question is, is there a standard (or even just an emerging standard)
on
> > how to deal with these issues in PHP code?  is there a recommended
library
> > of functions that does all these checks (e.g., Do_PHP30_Compat() or
> > something similar) so that PHP 3.0 standard global variable behavior
> > works.
> >
> > A discussion of best practices would be interesting.  My particular
> > interest, though, is in what the emerging standard (tending to actually
> > be used by PHP developers of important projects) is.
> >
> > I've tried to install maybe 8 different bug tracking systems.  Some of
them
> > are perl (most were rejected because they lacked the features i wanted),
> > many were PHP (most were rejected because i'm using PHP 4.2 and most of
> > them won't work with 4.2 with default security but not in safe_mode.  i
> > could get them to work, but that would require massive modification of
the
> > code).
> >
> > I've got bugzilla working.  It's rather too much for what I need, but it
> > *is* working, and I can deal with it.  I'd like to stay with PHP
products
> > though since i know php and i can't stand perl.
> >
> > But of course this isn't really about bugtracking or helpdesk software.
> > It's a general question involving the evolution of best practices in
> > the development of PHP software.
> >
> > tiger
>
> Your issues can be easily addressed by editing the php.ini file.
>
> ; You should do your best to write your scripts so that they do not
require
> ; register_globals to be on;  Using form variables as globals can easily
lead
> ; to possible security problems, if the code is not very well thought of.
> ; ##### JMD: This is set to On in Mandrake because a lot of existing
scripts
> ; needs it to be on, and we don't want to break configuration. Turning
> ; it on is a Bad Thing (tm), but for the sake of compatibility and less
> ; technical support, we'll close our eyes ;-)
> register_globals = On
>
> AND
>
> ; Safe Mode
> ;
> safe_mode = Off
>
> Someone else could probably tell you what the exact revision number was in
> which they changed the default register_globals setting -- the reason for
the
> change, as outlined above, was for additional security.
>
> Just curious, what don't you like about Perl?  I started in Perl and find
the
> two so similar that it was an easy transition.  Perl is a little more
> stringent in its requirements but that is not a bad thing IMHO.
>
> Brian
>
>
>
>
>
>
> --- Unsubscribe at http://nyphp.org/list/ ---
>
>