Re: php.ini configure package
On Mon, Jun 03, 2002 at 09:01:16AM -0500, Chad Walstrom wrote:
> > 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.
That's not the best solution in my opinion. First counterpoint is that this
overwrites global include_path, so that the users are not able to use their
own include files with the package without hacking in .htaccess or httpd.conf.
But I found another idea:
Every package which has php include files could have a /etc/package/conf.php
(for example) and this file gives the path to all the include files.
Then you have to include /etc/package/conf.php if you want to use the
functions of the package. But this would be a bad solution for the performance
because sometimes you only need one or two files of a package, then you don't
need the pathes to the other.
> 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.
Why? Again: you're not compelled to include the files. Just /usr/share/php is
in your include_path and if you want to include a file, use
include("package/file.php") and that's it.
> 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.
Yea, for Apache. But not for roxen or thttpd.
bye
mejo
--
Pinky: "What are we going to do tonight, Brain?"
Brain: "The same thing we do every night, Pinky:
try to install Windows 95!"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: