[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: php.ini configure package



On Sun, Jun 02, 2002 at 11:53:37PM +0200, Jonas Meurer wrote:
> I think debian isn't that good for webservers at the moments. 

Depends upon who you talk to.  IMHO, Debian makes a great webserver at
the moment. ;-)

> One (IMO very good) example is the php include_path. some packages ask
> the user to add /path/to/project_include/ into the php.ini. 

IMHO, this is a very Bad Thing(TM).  The most elegant solution I've seen
is to add the php_include_path in your Apache configuration via an
Include statement referrencing the software's /etc/<package>/apache.conf
file.  Include the /etc/<package>/ directory for customized *.php or
*.inc files as well as the installed share directory
/usr/share/<package>.  This is the one feature of PHP that has reduced
my configuration headaches to NIL.

> The best solution would IMO be a global includepath, standard in the
> include_path at php.ini, like /usr/lib/php/, and packages are only
> allowed to make subdirs like /usr/lib/php/package_name. Then there
> wouldn't be this problem any longer with adding to php.ini and so on.

The problem with this approach is that you expose the subdirectories to
ALL of the PHP packages, then.  I don't really want my Horde libraries
accessible from phpGroupWare, for example.

> Also I would say that projects are only allowed to make subdirs in
> /usr/lib/cgi-bin, not to place scripts direct there, like
> wdg-html-validator does (/usr/lib/cgi-bin/validate.cgi).

This also has the same exposure problem.  Using Apache's permissions and
URL rewriting mechanisms is a much cleaner solution to exposing CGI and
mod_<language> applications.

-- 
Chad Walstrom <chewie@wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr

Attachment: pgpoBZNyDkbC3.pgp
Description: PGP signature


Reply to: