memo

Remember this: If it ain't broke...

| As 2013 approached, I got it into my head that my new year's project would be to convert this site from thousands of static HTML pages into one with just a few dynamic pages that would suck appropriate content out of a database and build the necessary HTML page on-the-fly.

I've been dabbling with this for a while for specific data-intensive parts of sites. For example, the tour schedule at Hollywood Classic Tours is a single page that will show what's scheduled on every day of any month from now until forever. But my Chronicles — that's everything from a few sentences to lengthy essays that may include dozens of pictures, or none at all.

folder structure

Design was easy. Figuring out the structure of the database table was not very taxing at all. But where I got completely hung up was on how to make links to the articles. If you've been reading my site for a while you're used to seeing a URL like this: http://williamsonpsp.com/chronicles/2013/01/14_ice/ and I wanted a similar URL that would use the date of the article and the title, like this http://williamsonpsp.com/chronicles/2013/01/14/morning-ice/. You see URLs like this at gazillions of sites. To those of us with our minds stuck back in websites 1.0 these URLs imply an elaborate folder structure like the one at right.  But the gotcha! is that with the content in a database, there is no such folder structure!

After fussing with this for ever so long, I decided I would reverse-engineer WordPress, the very popular free blogging software used on millions of sites, see how they did it. That was a splendid and splendidly simple idea that turned out to be utterly impractical. A WordPress installation really only has one page, but you quickly end up deep in the weeds of highly abstract JavaScript without a clue (well, I hadn't one, at any rate). 

This can't be that hard! Eventually I learned enough to realize that the key to the whole affair was an arcane file called .htaccess that looks for certain strings of characters in the URL and, if it finds them, scoops up everything thereafter and redirects the request to a page that will do the database thing. So, to make the Chronicles section work, my .htaccess file contains the following line:

RewriteRule ^chronicles/(.+)$ chronicles/index.php?article=$1

This means, look for "chronicles" at the beginning of the URL (right after the williamsonpsp.com), which may or may not be followed by a slash, capture everything else after that and save it as parameter 1 ($1); then redirect to the page index.php in the chronicles folder and have that page display the article referred to by parameter 1. Aha! After that it's just programming.

But what about the thousands of existing pages? When I thought about the amout of time it would take to convert all of them I naturally went looking for a better way. There was the solution in plain sight: leave them well enough alone! Accordingly, there are two other lines in the .htaccess file:

rewriteCond %{REQUEST_FILENAME} !-f
rewriteCond %{REQUEST_FILENAME} !-d

These two gems mean that the rules that come after them should only be executed if the URL does not refer to an actual file or directory on the server. Which means, in the convoluted logic of programming, that the URL will be processed normally by fetching the actual directory/file.

Back in business!

Last updated on Apr 29, 2016

Chronicles

Archives

Recent Articles