Under the Hood #5:
New Website-Ish

Welcome to Camen Design v0.2-ish. I’ve replaced the publishing code in the site, leaving the HTML5 & CSS intact. They will be replaced in the next update. I plan to target Firefox 3.1 (and hopefully Safari 4 may be out by then too), allowing me to make use of CSS animation/transitions and border-image.

In fact, because my site has its PHP / HTML / CSS entirely separated, any one can be replaced without touching a line of the other.

On the subject of future-proof CSS, I noted:

A CSS file is such that you can throw it away easily and start again. I could design my website any way I wanted without ever changing the HTML.

Clean and separated HTML/CSS means that parts can be replaced. That’s what future-proof is about – the ability to adapt to changes.

Being bit-rot proof is an entirely different matter!

Kroc Camen, on Jens Meiert’s blog

That’s a different topic for another day though. This article is about the new back-end:

Clean URLs

In the previous version of the site, a PHP script handled the database, spitting out the data as requested. v0.2 is now all static XHTML5 files, ensuring faster load speed and better caching. The publishing script generates pre-gzipped “.xhtml” files for each of the articles, as well as each of the index pages. The home page is “1.xhtml”, the second page “2.xhtml” and so on. Each content-type is a folder, containing another set of numbered files for the pages. e.g. “blog/1.xhtml” and so on.

Mod_Rewrite is used to mask the “.xhtml” extension, so it isn’t required, giving nice looking URLs with no querystring as before. “/?blog&page=2” now becomes “/blog/2”.

The ‘.htaccess’ file I wrote now handles everything dynamic, applying the ‘application/xhtml+xml’ mime-type to the HTML, but falling back to ‘text/html’ for browsers that can’t deal with that.

I’ve opened up my ‘.htaccess’ file so you can view it fully, but a detailed break-down is covered below.

Serving Compressed XHTML5

A big problem with the old code was that a single PHP page was not being cached very well, relying on me manually setting all the HTTP-Headers for the various pages requested. In this new version each page is a separate file, and so Apache and your browser can handle things fine.

FileETag MTime Size
AddDefaultCharset utf-8

This declaration tells Apache to send ETags in HTTP-Headers. The ETag is a unique hash of the file, so that the browser knows when the file has actually changed. Apache sends ETags automatically anyway, but uses the default “MTime INode Size”, which ties the ETag to the file’s storage cluster on the disk. If you were to upload the same file again, despite its contents not changing, Apache would send a different ETag in that case.

# .xhtml files are gzipped html5 documents ready to serve
AddType application/xhtml+xml .xhtml
AddEncoding gzip .xhtml

This creates a new file-type “.xhtml”, and serves it as ‘application/xhtml+xml’ by default. Though it is possible to serve HTML5 as ‘text/html’ in Firefox 3 & Safari, the <legend> tag will not work correctly when used inside a <figure> element. This is due to the all-round broken-ness of the <legend> tag in all browsers (caused by pandering to IE’s even more broken implementation).

The publishing script uses the gzencode PHP function when saving the files to zip the contents for bandwidth-savings and fast delivery. The “AddEncoding” declaration applies this to Apache, adding the necessary “Content-Encoding: gzip;” HTTP-Header automatically.

# load page 1 by deafult
DirectoryIndex 1.xhtml index.php index.html

The home page is just page 1 of however many pages of the full archive of the site. Therefore “1.xhtml” is set as the default page to go to in a folder so that “/art/” returns “/art/1.xhtml”.

# if the url contains the ".xhtml", show the source code
RewriteCond %{THE_REQUEST} \b([^\.]*[^/])\.xhtml\b
RewriteRule ^ - [T=text/plain,L]

Viewing the HTML source of the pages on this site is an integral part of its design, so I wanted to make it very easy to do so. Just click the “html” link at the top of any page. The code above checks if the URL typed into the browser had the “.xhtml” included and if so, keeps the URL as is, but serves it as “text/plain” instead, preventing the browser from rendering the HTML.

# leave the ".xhtml" off (clean urls)
RewriteRule ^([^\.]*[^/])$ /$1.xhtml [L]

This finds any URL that has zero or one subfolder, and no dot in the filename. It then rewrites the URL to append “.xhtml” as the actual file to return. This is so “/blog/hello”, secretly returns the file “/blog/hello.xhtml”.

# although I don’t support IE, I do have to fall back to text/html,
# otherwise it will try and download the page instead of rendering it
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml
RewriteCond %{REQUEST_FILENAME} .*\.xhtml
RewriteRule ^ - [T=text/html,L]

As described, this will check the browser capabilities to see if it does not accept ‘application/xhtml+xml’ and revert to ‘text/html’. If this is not done, IE will try and download the file instead of showing it. In 2008.

Compressed CSS

# "csz" compressed CSS filetype
AddType text/css .csz
AddEncoding gzip .csz

As with the “.xhtml” definition, this creates a “.csz” filetype of mime-type “text/css”, and default gzip (compressed) encoding. The publishing script takes the normal ‘design.css’ file and spins off a compressed copy ‘design.csz’.

# on my localhost, don’t use a cached CSS file
RewriteCond %{DOCUMENT_ROOT} "^/Users/kroc/Sites/Camen Design/upload"
RewriteRule ^design/$ /design/design.css [L]
RewriteRule ^design/$ /design/design.csz [L]

When I’m editing the website on my computer, I’m refreshing constantly to see new CSS changes. This code checks if the webroot is that of my Mac’s localhost and passes the standard ‘.css’ file and stops processing. The next line passes the compressed CSS file in the case the document root match was not made (live server).

Compressed RSS

The publishing script creates a compressed ‘rss.rsz’ file in each folder and on root.

AddType application/rss+xml .rsz
AddEncoding gzip .rsz

RewriteRule ^([a-z0-9-]+/)?rss$ /$1rss.rsz [L]

This redirects URLs ending in “rss” to the compressed “rsz” file. e.g. “/blog/rss” becomes “/blog/rss.rsz”.

Static Publishing

When I mentioned my plans for v0.2, I noted one particular fallacy:

A simple text field is never going to replicate the editing power I have with TextMate. I’ve got no search and replace, no syntax highlighting, no keyboard shortcuts.

Trying to add these things is just re-implementing the wheel, and thus breaks my very own design principle №3, Let Everybody Else Do Their Job

Kroc Camen: “0.2 Thoughts”

Therefore, I removed the administration interface, in favour of a Laguna 2 (sadly offline now) style system.

The publish script is available to view online, but is not much use out of context. You can download a stub copy of this website with everything necessary to roll your own using the enclosure in your RSS reader, or the attachment at the bottom of this article.

Content on Disk

The source content of this website is just a folder, with a sub folder for each of the “content-types” (blog | tweet | photo &c.). In each folder is a file containing a JSON meta-data header and the raw HTML of the article. This layout directly maps to the new clean URLs too.

Creating a new blog post is nothing more than creating a new file. Because content is now disk files, instead of database entries, I can use my text-editor’s global search and replace and HTML editing capabilities and I can use my O.S. to manage the files instead of having to implement more and more server-side administration pages to do the same thing.

Now I can blog the same way I create the stuff I blog about.

Inside a Content Entry

A content file looks like this inside: (this one is for this article)

{	"date"		:	200807101232,
	"updated"	:	200807101232,
	"title"		:	"Under The Hood #3: ¬Using A Quick & Easy SQLite Database",
	"licence"	:	"cc-by",
	"tags"		:	["code-is-art", "web-dev"],
	"enclosure"	:	"sqlite.php"
}

HTML content goes here...

Pretty self-explanatory. When creating a new article, the “date” and “updated” fields are left out, and the publishing script then adds them in automatically. If I want to mark an article as updated, and thus push it to the top of the RSS regardless of its original publishing date, I just delete the “updated” line and the publishing script puts in a new timestamp.

This zip file is updated every time I publish, so it always contains the most up to date code.