Re: semi-RFC: new file role needed: docroot
| From: | Stig S. Bakken | Date: | Tue, 29 Jul 2003 14:08:25 +0000 |
| Subject: | Re: semi-RFC: new file role needed: docroot | ||
| References: | 1 | Groups: | php.pear.dev php.pear.general |
| Request: | Send a blank email to pear-dev+get-18901@lists.php.net to get a copy of this message | ||
On Sat, 2003-07-26 at 00:33, Greg Beaver wrote:
> Hi,
>
> I've been investigating the sources for PEAR, and an initial scan says
> it won't be easy to do, but that it will be possible to add a new
> configuration option, web document root. This will allow a new file
> role="web" to install into the document root, and therefore make
> available at a known URL all necessary files needed. This will also
> eliminate the problem of releasing a package with image files having
> role="php"
>
> This affects many packages in PEAR, including PEAR_Frontend_Web,
> HTML_TreeMenu, and phpDocumentor. Basically, any package that has a
> need to access files through html instead of PHP, whether javascript,
> css, or images needs this file role.
>
> If there is no objection, I would like to start working on implementing
> this so that at install-time, pear requests a document root directory
> for web install. I think that default behavior if the document root is
> not found should be to raise a warning, and then install into the data
> directory.
>
> After this is working, then a script can be written that will be
> executed upon pear upgrade PEAR which requests the new configuration
> value. This will also require the addition of a new file role,
> post-install or post-install-script, which specifies that the script
> should be run after installation. The zzoss installer has something
> like this, I believe, perhaps Sandro can comment.
I would suggesting having a template string in the PEAR configuration
for this, for example:
pear config-set htdocs_template /usr/local/apache/%s/htdocs
%s is replaced by the application package name. This way, users may
choose between installing individual application packages as their own
virtual hosts, sub-directories or however Apache may be configured
(being Apache biased for now).
The uglyness of this is that you may not want to use the package name in
the server name or path. Taking things a bit further, PEAR could
instead generate a file for including from httpd.conf, per application
package, that have a comment saying whether or not the installer is
allowed to touch it again:
# PEAR INSTALLER MAY MODIFY
# replace "MAY" with "MAY NOT" (or something else) on the above line to
# keep the file from being changed
<VirtualHost *>
ServerName pear-frontend-web.example.com
DocumentRoot /usr/local/apache/PEAR_Frontend_Web/htdocs
php_value include_path
/usr/local/apache/PEAR_Frontend_Web/lib:/usr/local/lib/php
</VirtualHost>
In httpd.conf it's then just a matter of adding an Include per package
or even have Include /path/to/pear/apacheconfs/*.conf
- Stig