Public service message: firefox 3 does not play well with self closed script tags.
I discovered this when I was repointing my jQuery libraries toward the googleapis hosted versions, to take advantage of their speed. I tested the switch in Opera, where it looked fine. Later, doing some debugging with firebug, I noticed those pages were no longer executing any javascript. Chrome had no problem loading them, and initially I thought the jQuery lib was the issue, but curling a new copy proved it was identical to my locally hosted version. Finally I noticed the difference in how I had self closed the script tags, which is perfectly legal… firefox 3 just doesn’t like it.
So I like the ajax.googleapi.com hosted libraries, although I don’t buy that using the google.load() method is better than pointing to the hosted library directly. Profiling the difference between two pages that do nothing more than load jquery shows that using google.load() adds about 0.2 seconds to the load time. Try it yourself:
Pointing directly vs Using google.load(). Which only makes sense, since loading the google api takes time… so where is the extra “power” they boast you receive by using this method? The only potential advantage I see is the ability to load the library conditionally, avoiding the load unless you need the library. I say potentially because I’ve yet to make use of that kind of just-in-time loading. If you have, or I’ve overlooked some strength to this method, I’d love to hear it.
One last googleapi related note: using a script tage to call your library, you can use https to load the file. The google.load() method appears to load files using http, which is quicker but poses a security risk by injecting insecure code into a supposedly secure environment. This is the same reason secure method pages should use the secure-only flag on cookies: you are only secure as your weakest link.
I’ve been running more PHP apps for virtualhosts lately, and one thing I dislike about such bundles is having a config file in the app root. For one, it’s sitting in the web root, and if improperly configured the server could serve it as content, posing a security risk (as they tend to hold database login information, passwords, etc.) The other reason is that I like to maintain a single copy of the app (via the FreeBSD ports tree, or from a single repository checkout.) I don’t want to make copies, because then I need to maintain each copy too, and I can’t just set the primary installation directory as the server document root, or alias a subpath to it, because each deployment would receive the same default config file. Any modifications to the application code, to make it look elsewhere for the config, would likely be lost in the next upgrade. So how can you share a single installation for multiple deployments?
The key is that the config file itself is usually left as-is during upgrades, as it is supposed to be altered by the user. We use this file to include another config file from elsewhere based on webserver variables.
For example, here is my config.inc.php for phpMyAdmin:
<?php
/*
Delegate to another file.
Set web server variable PHPMYADMIN_CONFIG_FILE to the file that would normally be located here (config.inc.php).
Under Apache, it would look like this:
SetEnv PHPMYADMIN_CONFIG_FILE /usr/home/rj/.phpmyadmin
Include the absolute path, or make sure the file is in the PHP include path.
Ensure that the file is readable by the account the web server runs under.
*/
include($_SERVER['PHPMYADMIN_CONFIG_FILE']);
?>
You now just need two lines in a virtualhost config to set up a new installation:
SetEnv PHPMYADMIN_CONFIG_FILE /usr/home/$USER/.phpmyadmin
Alias /phpmyadmin/ "/usr/local/www/phpMyAdmin/"
Of course, you still need to set up each .phpmyadmin file, but that’s easy enough. Of course, if you’re deploying lots of similar database setups, you could also use the virtualhost config to set up the configuration and re-use a common config.inc.php tweaked to use server variables (PHPMYADMIN_HOST)… but I’ll leave that as an exercise for the reader. Avoid passing passwords this way, however, as server configuration variables are another potential data leak.