NYCPHP Meetup

[Hans Zaunere]

> Framework question.
> 
> I had an idea that if I were to store many of the web site 
> configuration
> values in the web server environment, such as database connection
> parameters, default email address, company address and major 
> site links in
> each apache server virtual host environment, this information would be
> resident in the server memory, and subsequent requests would 
> require less
> over head than creating a large configuration file that would 
> be loaded and
> parsed at runtime each time a script on our site ran.

Very true.  Something to keep in mind, however, is the visibility of
sensitive data (like passwords).  Not only could someone read the
httpd.conf itself (depending on permissions, of course) but the $_SERVER
array containing the passwords, etc. is globally available in any PHP
script running under that environment.

> For example. In my apache config I set the values in the 
> following manner...
> 
> setEnv    DATABASE_NAME    = "somedatabase"
> setEnv    DATABASE_USER    = "someuser"
> setEnv    DATABASE_PASS    = "somepass"
> setEnv    LINK_HOME_PAGE = "/index.php"
> setEnv    LINK_SITE_MAP = "/site-map.php"
> setEnv    EMAIL_DEFAULT = "info at foo.com"
> setEnv    EMAIL_SALES = "sales at foo.com"
> setEnv    PATH_PHOTOS = "/photos/"
> setEnv    PATH_GIFS = "/gifs/"
> 
> To access these from my scripts, I can use the following...
> 
> $_SERVER['DATABASE_NAME']
> $_SERVER['DATABASE_USER']
> $_SERVER['DATABASE_PASS]
> $_SERVER['LINK_HOME_PAGE']
> $_SERVER['LINK_SITE_MAP]
> 
> Because they are resident in the memory of the server, the 
> server does not
> have to parse the file each time a request is made for the 
> virtual host.
> 
> However, this is proving to be a pain because there are other 
> scripts that
> run from CRON etc, that do not run from the virtual host 
> environment, and
> for those scripts, I have ended up duplicating my efforts by creating
> another configuration file for our site. This means I have to 
> update changes
> to the configuration twice.
> 
> I was thinking that it would may be easier to ditch this 
> effort and go with
> a standard configuration file in PHP that I can include for 
> the site and
> scripts that run outsode the virtual environment. Perhaps 
> something like the
> following...
> 
> <?php
> 
> define(DATABASE_NAME,'somedatabase');
> define(DATABASE_USER,'someuser');
> define(LINK_SITE_MAP,'/site-map.php');
> 
> ?>
> 
> and then access the values in the script using their constant 
> values or
> perhaps store the values in an array such as...
> 
> <?php
> 
> $site = array(
> 'DATABASE_NAME' => 'somedatabase',
> 'DATABASE_USER' => 'someuser',
> 'LINK_SITE_MAP' => '/site_map.php'
> );
> 
> ?>
> 
> I would like to hear all your thoughts on this issue. I have about 100
> configuration directives I would like to be able to store in 
> one place. I
> would be curious how others have dealt with simular issues. Are there
> advantagaes to using an array for config values as mentioned 
> above over lets
> say defining constants?

While define() is more expensive, performance wise, than simply
declaring a variable, using constants elsewhere in the script is faster
than variables (or so Zeev told me once).

> Ideas, suggestions?

Don't forget that Apache can include other files as other conf files.
So, for example, you could have a series of php.app.conf files with your
SetEnv directives which could also be included from cron/cli php scripts
and parsed.  True, maybe a little messy on the cli side, but worth some
thought.

Of course, the "cool" way of implementing this is with shared memory.
More complex, but probably the ultimate in speedy configuration and
flexibility.  For instance, you could have a set of scripts to manage
configuration directives, in shared memory - the config could change,
and applications would see them in real time.  I had some scripts to do
this, but they're not ready for show.  That said, PHP's shared memory
extension has some weaknesses for this type of application, and a custom
C extension would really be the way to do it.

Sorry for the crazy wrapping folks - if anyone knows how to get Outlook
2003 to wrap plain-text messages normally, please contact me offlist :)

H