NYCPHP Meetup

[Brian]

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