Smokes your problems, coughs fresh air.
When a site is available under multiple domains, it is usually bad idea to not have them all redirect to one domain. In apache, do this:
RewriteEngine On RewriteCond %{HTTP_HOST} !=www.domain.com RewriteRule ^(.*)$ http://www.domain.com$1 [L,R=permanent]
For the record, when deploying mod wsgi apps, remember to enable optimizations in mod_wsgi.conf. Otherwise debug will be true.
openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr openssl x509 -req -days 3650 server.csr -signkey server.key -out server.crt
May, last year, I created an empty draft for this post, because, around that time, I had gone through quite some effort before I got thumbnails for foreign file repos working just right. Now, I’m taking a dive into my MediaWiki working dirs in preparation of the creation of a separate development environment, so it’s a good moment to rehash the past experience (almost as good as when I’d have done it right away).
This is how I configured the foreign file repo to be able to use images uploaded to the English wiki from the Dutch wiki:
$wgHashedUploadDirectory = false; $wgForeignFileRepos[] = array( 'class' => 'ForeignDBRepo', 'name' => 'en', 'url' => "http://wiki.hardwood-investments.net/media", 'hashLevels' => 0, //'thumbScriptUrl' => "http://wiki.hardwood-investments.net/thumb.php", 'transformVia404' => true,//!$wgGenerateThumbnailOnParse, 'dbType' => $wgDBtype, 'dbServer' => $wgDBserver, 'dbUser' => $wgDBuser, 'dbPassword' => $wgDBpassword, 'dbName' => 'hardwood', 'tablePrefix' => 'mw_', 'hasSharedCache' => false, 'descBaseUrl' => 'http://wiki.hardwood-investments.net/Image:', 'fetchDescription' => false );
To make thumbnails be generated by thumb.php on request I added the following to my .htaccess at the other end (and visa versa, because the Dutch wiki actually contains most of the images):
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^media/thumb/([^/]+)/([0-9]+)px-.*$ /thumb.php?f=$1&width=$2 [L,QSA]
I often get the “NameVirtualHost *:80 has no VirtualHosts” on my webservers. It seems that every version of every distro has different requirements. My existing Debian config was fine, until I upgraded to Lenny. With fiddling, I determined the solution:
In /etc/apache2/ports.conf, put (among other things):
NameVirtualHost * Listen 80 <IfModule mod_ssl.c> # SSL name based virtual hosts are not yet supported, therefore no # NameVirtualHost statement here Listen 443 </IfModule>
Then you can define virtual hosts:
<VirtualHost *>
ServerName bla
ServerAlias hoho
</VirtualHost>
The key is to not define *:80 for the namevirtualhost and virtual hosts. Instead, use the listen directive to define the port.
Stichting EcoSafe is a Dutch foundation for the safe-keeping of the funds that are necessary for the maintenance of hardwood plantations. In July of 2006, together with Johan Ockels, I created a website for the Foundation. Johan was responsible for the organization of the whole process. This went very smooth and the website ended up being an emblem of simplicity and clarity. That’s why I wanted to blog a bit about it now, even though there are a few things that I’d probably end up doing different if I were to start from scratch. [There’s actually a disturbing number of things for which this is true, I’m coming to notice.]
 The Welcome page of the EcoSafe website |
 EcoSafe page for plantations |
 EcoSafe cost structure |
Like with most websites, I started with creating an SVN repo so that I wouldn’t have to be afraid of ever losing anything.
The file structure was pretty standard:
If I were to redesign this file structure, I’d collapse css, img and js into one directory called layout, because these are typically things that require the same robots.txt and caching policy. Also, it is meaningless to organize things by file extension. If you want to sort something by file extension, use ls -X
(or ls --sort=extension
if you’re on GNU).
The site would be so simple that I felt that any type of CMS or content transformation would be completely unnecessary. Instead, I decided to rely on Apache’s mod_include and just use a few partials for repeating page elements such as the left sidebar containing the logo and the menu.
Also, because I didn’t need to transform the HTML files, I decided I could use good ol’ HTML 4 instead of XHTML 1 (which I’d have to send to the browser with the wrong mime-type anyway).
This is the HTML for contact.nl.shtml:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"> <head> <title>Contact EcoSafe</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link rel="stylesheet" type="text/css" href="/css/style.css"></link> </head> <body> <!--#include virtual="/inc/left-side.en.html"--> <!--#include virtual="/inc/alt-lang.phtml"--> <div id="content"> <h1>Contact</h1> <p>Your email to EcoSafe kan be sent to the following address: <a href="mailto:service@stichting-ecosafe.org">service@stichting-ecosafe.org</a>. Or, alternatively, you can fax us at +31 50 - 309 66 58.</p> <h2>About this website</h2> <p>For comments and/or suggestions concerning this website, you can direct an email message at: <a href="mailto:webmaster@stichting-ecosafe.org">webmaster@stichting-ecosafe.org</a>.</p> </div> </body> </html>
Alternative language selection
I use <!--#include virtual--> to include the repeating parts. <!--#include virtual--> has several advantages over <!--#include file--> in that it allows for content-negotiation, execution of dynamic content etc., but here the only place were it holds an advantage is in the inclusion of /inc/alt-lang.phtml. alt-lang.phtml is a messy PHP script that figures out which language variants of a page are available and displays a selection of alternative language versions (variants with a language different from the current).
Without the XBitHack directive set to full, all content handled by mod_include is sent without a Last-Modified header. However, I don’t want to use XBitHack at all, because I don’t want just any executable file to be handled by mod_include; that just too much of a … hack.
If I were to do something similar now, I’d use some kind of (sed) substitution to pre-process the includes locally so that more of what I end up uploading is simple static content. The dynamic part of the included PHP script, I would simply replace with JavaScript.
As you can see in the HTML example, there’s hardly anything layout oriented in the HTML source. This is good, and means that I have to touch only the CSS for most minor and major lay-out modifications. (It is a pipe-dream to think that you only need to change the CSS to make the same HTML page look however you want as long as that HTML is rich enough in meaning, but for a site with pages of such simple structure, it’s a dream that comes pretty close to reality.)
I’m not much of a designer, but I think design is overrated anyway. Actually, I think that most website suffer from too much design.
The EcoSafe logo
To start the design, I got a logo made by Huite Zijlstra. Because the logo was pretty big and didn’t look good scaled down, I decided to put it at the left of the content area instead of at the top. This would still leave enough room for the menu (which actually takes less space horizontally than the logo).
For the color scheme, I just picked a few colors from the logo. As always, the base of the scheme would be black text on a white background for maximum readability. The print version hardly uses any colors.
@media screen { body {:; } * {:; } a:link {: #585; } h1 {: #880; } h2 {: #888; } strong {: #a62; } #menu li a {: #660; } }
I wanted an underline below the level 1 and 2 headings. Because I didn’t like the effect of text-decoration:underline (too thick for <h2>s, too dark for <h1>s and different from browser to browser) and because border-bottom was set too far from the text, I made two simple PNG images that I could repeat-x along the bottom edge.
@media screen { h1 {:('/img/h1-border-bottom.png'); } h2 {:('/img/hx-border-bottom.png'); } }
The menu is very simple. The markup is part of inc/left-side.en.html for the English version and inc/left-side.nl.html for the Dutch version:
cat inc/left-side.en.html
<div id="left" lang="en"> <a class="logo" href="/index.en"><img class="logo" alt="[Logo]" src="/img/logo.jpg"></img></a> <ul id="menu" class="menu"> <li><a href="/index.en" rel="start">Start page</a></li> <li><a href="/plantations.en">For plantations</a></li> <li><a href="/investors.en">For investors</a></li> <li><a href="/history.en">History</a></li> <!--<li><a href="/goals">Goals</a></li>--> <li><a href="/methods.en">How it works</a></li> <li><a href="/cost-structure.en">Cost structure</a></li> <li><a href="/cost-calculator.en">Cost calculator</a></li> <!--<li><a href="/clients.en">Clients</a></li>--> <li><a href="/contact.en">Contact</a></li> </ul> </div> <script type="text/javascript" src="/js/menu.js"></script>
The EcoSafe menu (in English)
As is customary, I started by removing all the default list styles and made the anchors behave as block-level elements. I used the big O from the logo for bullets in the list (using background-image instead of list-style-image because the latter gives unpredictable cross-browser results and doesn’t make the bullet clickable).
#menu { : 2em; : 2em; :; : 0; } #menu li { : 0; } #menu li a { :; :('/img/o-21x16.png'); :; :; : 30px; :; :; :; : #660; } #menu li a:hover, #menu li.active a { :('/img/oSafe-21x16.png'); } #menu a:hover { : #787800; }
To add the active class to the currently active list item (<li>), I used a client-side solution using JavaScript. After all, it’s proper use of JavaScript to enhance your user interface with it (as long as, as many would say, it isn’t required for the UI to function (as it is in the Cost Calculator)).
// menu.js var menu = document.getElementById('menu'); var anchors = menu.getElementsByTagName('a'); var locationHref = window.location.pathname.toString(); for (i = anchors.length - 1; i >= 0; i--) { a = anchors[i]; aHref = a.href; // Does this menu item link to the current page? // We find out by looking if the window location contains the URL in the anchor // or the other way arround. The reason to look at both is content-negotiation. // It's also true if the location is just '/' and we're looking at the anchor of // the 'start' page. if ( (locationHref === '/' && a.rel === 'start') || (locationHref !== '/' && ( locationHref.indexOf(aHref) !== -1 || aHref.indexOf(locationHref) !== -1 ) ) ) { a.parentNode.className = 'active'; break; } }
I actually just fixed a long-standing bug that was caused by me not being able to fully rely on HTTP language negotiation for the selection of the appropriate language variant, which made me change all links from being language-neutral to including the language in the link target (e.g.: http:///history became http:///history.en and http:///history.nl), the problem with this being that, instead of being able to link to link to http:/// (http://www.stichting-ecosafe.org/), I had to link to http:///index.en or http:///index.nl, making it more difficult to detect the active anchor if we’re requesting the home page through http:/// instead of on of its language-specific URLs.
The JavaScript rested on the assumption that by reverse iterating through all the anchors in the menu and thus processing the link to http:/// as last, I’d know that I had struck the home page and wouldn’t need to worry that any of the links contain a slash. (I don’t know if I intended it to work this way, but it sure seems to me now that the only way this could ever have worked was as an apparent side-effect of the looping order; the SVN logs seem to agree.)
I could have solved this by redirecting all requests for http:/// to the appropriate variant. Maybe I should have (to avoid duplicate content). Instead I chose to add a rel="start" attribute to the links to the home page, as can be deduced from the JavaScript above. (To resolve the duplicate content issue, I could also add a canonical link to the header of the two language variants.)
Anyway, all this brings me to the messy subject of content negotiation.
The EcoSafe website would be bi-lingual (English and Dutch) from the onset. Initially, I wanted to use language negotiation to the extend of having completely language-neutral URLs. For example: http:///cost-calculator
instead of http:///cost-calculator.en
and http:///cost-calculator.nl
. In the end, you can make this work properly in the browser with the help of a cookie, but it’s still a pipe-dream because nothing else will work if you do not also offer another navigational path to the different variants. Maybe, we’ll revisit this topic for a later experiment.
Content-type negotiation is almost effortless with Apache thanks to mod_negotiation. If, like me, you despise to have .html, .htm, .xhtml, .phtml, .pxhtml. .sxhtml, .php, .xml in your URL (I actually used all of these at some time or other), you only have to make sure that MultiViews is in your options.
I’ve configured SSI by means of the following instead of a “magic mime-type”:
AddType text/html .shtml AddHandler server-parsed .shtml AddCharset UTF-8 .shtml AddOutputFilter Includes .shtml
For PHP I couldn’t do the same because my web host was still at Apache 1.3. Otherwise, the following should have worked equally well for PHP:
# This doesn't work with Apache 1.3 AddType text/html .phtml AddHandler php-script .phtml AddCharset UTF-8 .phtml
Configuring language priority is easy with Apache:
The integration of PHP with all the weirdness that I had configured and created around SSI took some figuring out. Luckily, PHP offers a virtual() function that works roughly the same as mod_include's <!--#include virtual-->. Here’s an example:
<body> <?php virtual('/inc/left-side.en.html'); ?> <?php $uri = '/cost-calculator.en.phtml'; include('inc/alt-lang.phtml'); ?>
In retrospect, it’s pretty much bullshit to use it. I could have just as well require()d the partials (which I actually did for the alternate language selection), but I probably started out using virtual on a more generic URL without language and content-type selection in it.
Because I deployed on Apache 1.3 and the ForceLanguagePriority directive was only introduced with Apache 2.0.30, I had to write an ugly hack to avoid visitors getting 406 errors. To that end, I added a 406 handler to my .htaccess file:
LanguagePriority en nl ForceLanguagePriority Prefer Fallback # This doesn't work with 1.3 ErrorDocument 406 /error-406.php # Luckily, this does
error-406.php is a PHP file that figures out the available variants based on $_SERVER['REQUEST_URI']. Then, it simply picks the first one (which works because, accidentally, that’s the one I’ve given priority using the LanguagePriority directive as well), outputs a 200 OK header instead of the 406, and virtual()s the file of the variant. The code looks somewhat like this:
<?php chdir($_SERVER['DOCUMENT_ROOT']); $filenames = glob(basename($_SERVER['REQUEST_URI']) . ".*"); $filename = $filenames[0]; apache_setenv('DOCUMENT_URI', "/$filename"); header('HTTP/1.1 200 OK'); virtual("$filename");
EcoSafe Cost Calculator
EcoSafe Cost Calculator results
The EcoSafe Cost Calculator is some of the least neatly contained and most procedurally oriented PHP code I’ve ever produced while knowing full well what I was doing. It does almost everything it does in global scope. Yet, it does it well.
The thing is designed as a dynamic web page rather than a web application. What I mean by this is that it’s simply two pages (one for English and one for Dutch) using PHP among a number of pages using SSI. In an application, it’s usual to have just one ‘view’ that is the same for all languages, but here I chose to put the different language versions in different language pages and then include everything reusable (and language-neutral) from within these files.
Most of the actual processing and calculating is done in inc/costs-functions.php. (The part about gotos is a joke. (Labeled blocks would have been quite sufficient. 😉 ))
<?php # costs-functions.php - Stuff that's includes by cost-calculator.{nl,en}.phtml /** * Just remember that this code was never meant to be general purpose or anything. * So, relaxeeee and keep your OO-axe burried where it belongs. * Oh, if only PHP would support GOTO's ... Sigh ... */
The rest of the file is just a whole lot of processing of form data and turning it into something that can be easily traversed for display to the user. There are even the function calls without arguments doing all their work on globals. These are actually only added to make it clearer em a piece of code is doing. And—I must say—after a few years it’s still remarkably clear to me what each part of the code is doing. There’s no deep, confusing nesting structures or anything. There’s just a whole lot of very simple code.
Users of the calculator can add any number of plantings and locations. When the user decides to add a planting or a location, the onClick event triggers the execution of addExtraPlanting() or addExtraLocation(). Here’s how addExtraPlanting() looks:
function addExtraPlanting() { lang = document.documentElement.lang; new Ajax.Updater( 'plantings', '/inc/planting.' + lang, { method: 'get', insertion: Insertion.Bottom } ); }
Ajax.Updater comes from the Prototype JavaScript framework.
Here’s what inc/planting.en.phtml looks like. The same file is also included in a loop to rebuild the form’s state after submitting.
<li> <input name="num_hectares[]" type="text" size="5" value="<?php echo $num_hectares ?>" /> hectares have been planted in <select name="plant_years[]"><?php require('planting_options.php') ?></select> (<a title="Remove this planting" href="#" onclick="removePlanting(this); return false;">x</a>) </li>
I think that I’ve gone into small enough detail by now to get to the conclusion. Also showing the contents of planting_options.php would be pushing it. Ah, well…
<?php if ( !isset($this_year) ) $this_year = intval(date('Y')); if ( !isset($plant_year) ) $plant_year = $this_year; for ($i = $this_year; $i >= $this_year - 20; $i--) echo "<option" . ($i == $plant_year ? " selected='1'" : "") . ">$i</option>\n";
(Yesterday, I couldn’t resist the temptation of turning this into a simple file to require() instead of the function definition it was. I think it’s funny to refactor something to remove encapsulation.)
As is usual when looking at old code, I see many things that I’d do (even just a little) different today, but I saw a surprising number of solutions that I actually still like now that I see them back after three years. Removing some of the remaining warts probably won’t do much good besides the masturbatory satisfaction it could give me. (It’s likely that the website won’t live much longer, making such extra attention very undeserved.) But, nevertheless, I’ve enjoyed blogging about it now to recoup the whole experience and to at least look at what I’d do different now and what I learned in the meantime.
I hate modules, especially core modules. I prefer code to be tightly integrated. I want it to work together. Is that too much to ask? In Drupal, most functionality has been stuffed in modules. There’s a Locale module, a Content Translation module and a Path module. What’s missing is a Working Together module.
For me, clean, meaningful URLs are a number one, two and three requirement for any website that I do. Drupal considers /node/54673 to be a cool URL. I don’t. So, as a kind of afterthought, Drupal comes with the Path module. This module allows you to set URL aliases per node.
The problem is that there’s no concept of a canonical URL. The URL alias works, but so does the node/3242 URL. Neither redirects to the other. In many cases this is not much of a problem (because regular visitors will not notice this) but for our current project it is.
We have a lot of blocks with URL dependent visibility settings. For example, for a section about investing we have a menu that is displayed on all URLs starting with /investing
, such as /investing/projects
and so on.
After editing a page, Drupal helpfully redirects the user to node/[nodenumber]. For us, this means that the menu is no longer displayed and even the theme will be wrong. (We use the Sections module to select a subtheme based on which section you’re in.)
The Global Redirect module promises to solve this by allowing you to redirect node/[nodenumber] URLs to their alias if available. It kinda does, in some circumstances.
Our Drupal website sports two languages: English (EN) and Dutch (NL). English is the default language (not the fallback language; we don’t use a fallback) and doesn’t use a prefix. Dutch uses the nl prefix. Two example URLs:
| URL alias | Generic URL |
|---|---|
| http://www.example.com/investing/projects | http://www.example.com/node/288 |
| http://www.example.com/nl/beleggen/projecten | http://www.example.com/nl/node/110 |
When /node/288 is requested, the client is correctly redirected to /investing/projects, but when /node/110 is requested, no redirect takes place. It will take place when prefixing /nl, but this is completely useless since Drupal’s built-in actions such as edit don’t redirect using this prefix, and these actions were what we needed this module for in the first place.
We ended up tearing our hair out trying to fix Global Redirect until we decided that we could just delete the module and replace it with a RewriteRule and a simple PHP script.
# Put this after RewriteBase and before Drupal's default rewrite rules RewriteRule ^(../)?node/([0-9]+)$ fixurl.php?nid=$2 [L]
<?php require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE); $result = db_query("SELECT * FROM {url_alias} WHERE src = 'node/%d' LIMIT 1", $_GET['nid']); if ( db_error() ) die("O agony!"); $url_alias_object = db_fetch_object($result); $destination = $url_alias_object->dst; $result = db_query("SELECT prefix FROM {languages} WHERE language = '%s'", $url_alias_object->language); if ( db_error() ) die("O agony!"); $prefix = db_result($result); if ( !empty($prefix) ) $prefix .= '/'; header("Location: /$prefix$destination",TRUE,301); ?>
The code assumes that every content page has an URL alias. For us, this is okay, because we need these pretty URLs to even have menus show up or to have the right page be displayed with the right theme.
Also, this code is specifically tailored to language code in the URL prefix. For subdomain based language selection, for example, you’d need to modify it.
Since version 2.6, WordPress can be installed in its own directory, separate from your customizations and everthing. Needless to say, this makes upgrading a whole lot easier.
If, in the pre-2.6 days, you wanted to fetch your WordPress updates through SVN, the docs would advice you to do an svn checkout from the official WP SVN repo in your working dir and then do an svn update whenever you want to update WordPress. This works because svn update leaves local modifcations alone. However, this means that you’ll be unable to commit your local changes (configuration, themes, plugins, etc.) if you choose this route.
I used my own subversion repository for my blogs and thus had to upgrade the old fashioned way with each release (although I prefer diff/patch over rm/cp). (I could have used vendor branches, but, clearly, I hadn’t thought about that at the time.) This was pretty much a royal pain in the ass, so I was glad when I could move WordPress into a separate directory with its 2.6 release.
This process consisted of removing everything except wp-content/, wp-config.php, .htaccess. (I also kept robots.txt, favicon.ico and some other personal files.) Then, I added the current WordPress release as an svn:external.
svn propset svn:externals 'wp-factory http://svn.automattic.com/wordpress/tags/2.6.1' .
In the WordPress codex, it is then suggested to copy index.php to the root dir and to change it to require wp-factory/wp-blog-header.php instead of ./wp-blog-header.php. I preferred adding some mod_rewrite voodoo of my own to .htaccess, so I did:
<IfModule mod_rewrite.c> # This way I don't need directory indices RewriteRule ^$ /wp-factory/index.php [L] # This way WordPress can manage its own block without doing any harm RewriteRule ^index.php /wp-factory/index.php [L] # Allow easier access to /wp-factory/wp-admin/ RewriteRule ^wp-admin http://%{HTTP_HOST}/wp-factory/wp-admin/ [L,R=301] </IfModule>
The middle rule performs most of the magic. It redirects all the requests to /index.php to the factory default index.php. This means that I can let WordPress pretend that index.php does live in the root, so I don’t have to modify the rewrite rules that are managed by WordPress itself:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress
In Giving WordPress Its Own Directory in the WordPress Codex, it is suggested to change the “siteurl” and “home” options through the administration panel. In my case they would have to be changed to “http://blog.bigsmoke.us/wp-factory/” and http://blog.bigsmoke.us“. I couldn’t do this because I override these with WP_SITEURL and WP_HOME in my wp-config.php. This is because I configured WordPress to support a development environment separate from the live production environment.
Ignoring the customizations for my development environment, these are the relevant settings in wp-config.php:
define('WP_HOME', 'http://blog.bigsmoke.us'); define('WP_SITEURL', WP_HOME . '/wp-factory'); define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content'); define('WP_CONTENT_URL', WP_HOME . '/wp-content');
BTW: I really like it how WordPress disables the form controls for siteurl and home when you override these settings in wp-config.php. Kudos for that, devs!
In the end, this is all quite a bit of pain to compensate for what is essentially a version management problem. That’s why, on my newer projects, I’m now using git which makes forking and tracking an upstream repo absolutely trivial. 🙂
When you’re out Googling on how to maintain a separate development environment for a WordPress installation, you will only stumble across information about how to install all kinds of WAMPP packages. Well, I don’t care about WAMP (or WAMPP). I want to be able to edit my theme, change my plugins, mess with my database locally and then deploy my changes when they’re ready and well-tested (as if I ever…)
Rails was the obvious inspiration for how to do this properly. In Rails, the whole development and deployment process is very intuitive and powerful. In WordPress documentation I never even see the awareness of the need for this separation. They usually tell you to download stuff, upload it and muck about with it on the life production server. But, I’m not the mucking-about-in-live-configurations type. I’m the I-fucked-this-up-so-often-I-want-a-staging-area type. This post is about how I managed to fulfill this wish with WordPress.
The first thing I had to do was to find some way to decide which environment to go into. For some reason I decided to use Apache’s mod_rewrite to set an environment variable based on the HTTP Host header. This is in fact very illogical, but we’ll get to that later.
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} =bsblog [OR] RewriteCond %{HTTP_HOST} =bsblog.molensteen RewriteRule . - [env=WP_ENV:development] RewriteCond %{HTTP_HOST} =blog.bigsmoke.us RewriteRule . - [env=WP_ENV:production] </IfModule> # Keep out of WP's own block of rewrite rules below # BEGIN WordPress
. -
looks like a needle because it’s voodoo. The dot says I match anything and the dash says I change nothing of what I match. I do set an environment variable to whether I want to be in development or in production.
So I now have an Apache environment variable available for querying from within PHP (as if PHP doesn’t have a $_SERVER['HTTP_HOST'] variable:-? ) and I can make use of that in my wp-config.php.
I love configuration files that share the program’s language; wp-config.php being simple PHP code is what make this whole thing so easy:
<?php if ( getenv('WP_ENV') == 'production' ) { // ** MySQL settings ** // define('DB_NAME', 'blog'); // The name of the database define('DB_USER', 'wordpress'); // Your MySQL username define('DB_PASSWORD', '[my password]'); // ...and password define('DB_HOST', 'bigsmoke.db'); // 99% chance you won't need to change this value define('WP_SITEURL', 'http://blog.bigsmoke.us'); } elseif ( getenv('WP_ENV') == 'development' ) { // ** MySQL settings ** // define('DB_NAME', 'bsblog'); // The name of the database define('DB_USER', 'root'); // Your MySQL username define('DB_PASSWORD', '[my password]'); // ...and password define('DB_HOST', '127.0.0.1'); // 99% chance you won't need to change this value define('WP_SITEURL', 'http://bsblog'); //define('WP_DEBUG', true); } define('WP_HOME', WP_SITEURL); // You can have multiple installations in one database if you give each a unique prefix $table_prefix = 'wp_'; // Only numbers, letters, and underscores please! // The rest of the stuff in this config file just isn't interesting ?>
There’s a few things to note here. You have to use getenv() or $_SERVER instead of $_ENV because variables set by Apache end up in the former two. Another thing to note is that I should have just checked $_SERVER['HTTP_HOST'] instead of resorting to mod_rewrite voodoo. For the rest it’s all very straight-forward: I make some database settings depend on which environment I’m in and I set the URL accordingly.
I had some trouble putting the pieces back together when newer WordPress versions started doing automatic redirects for URL that didn’t match siteurl in the wp_options. This change meant that when going to http://bsblog/ (the development URL for this weblog) for example, I’d inevitably end up at http://blog.bigsmoke.us/.
Links had always been constructed according to this setting, so I had already been planning a plug-in to transform production URLs to development URLs. But, I learned (a little late) that this is completely unnecessary since wp-config.php supports the configuration of a base URL. I had wrongly assumed that settings that weren’t in the sample config file, simply didn’t exist.
Thus, after adding WP_SITEURL and WP_SITEHOME to wp-config.php, everything was working.
Yesterday, after uploading a refreshed www.sicirec.org, some character encoding issues popped up because I had converted the website’s content from ISO-8859-1 (Latin 1) to UTF-8. (I wanted to be able to type and paste special characters from PuTTY into VIM without worrying about the particular encoding of each file.)
The Apache HTTPD at InitFour, our webhosting provider, is configured to send ISO-8859-1 by default, while the one on our test server is configured for UTF-8. This caused a little bit of a surprise when I uploaded the refreshed website and saw all characters outside the ASCII range mangled on the life website!
I quickly dug into my .htaccess file to add the AddCharset utf-8 .xhtml directive. To my surprise, this didn’t do squat. A lot of fiddling, reloading and researching later, I realized that the following section in my .htaccess file rendered the AddCharset directive irrelevant:
<Files *.xhtml> ForceType text/html </Files>
I had to change the ForceType directive to include the charset as a MIME parameter:
<Files *.xhtml>
ForceType 'text/html; charset=UTF-8'
</Files>
Now, it all seemed to work. (Except that it didn’t really because I do some ridiculously complex content negotiation stuff involving a 406 handler in PHP that virtuals the most appropriate variant when no match is found. This script didn’t send a useful Content-Type header. After first adding it to the script, I noticed that the AddDefaultCharset is actually allowed in .htaccess context—a discovery which luckily rendered the other hacks useless.)
© 2024 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments