Just Shelley

The long way home

Before weblogging and RSS—long before Facebook, Twitter, or the next poor bastard service, doomed to be worshiped and then sacrificed on some given Friday—I used to write long essays I’d publish online by hand editing the HTML and posting the static files. Having to manually create the HTML template and design, incorporate navigation, and craft the links and images, took a considerable amount of time.

To justify the time, I wanted to make sure that what I published was worth the effort. I would research a story and edit and re-edit it, and look for additional resources, and then re-edit the story again. My one essay on the giant squid actually took two months to research, and days, not minutes, to edit. Even after publication, I would tweak the pages as old links died, or to refine a section of the writing.

Now, we have wonderful tools to make it easy to put writing or other content online. We can think of a topic, create a writing about it, and publish it—all in five or less minutes. We’ve also come to expect that whatever is published is read as quickly. We’ve moved from multi-page writings, to a single page, to a few paragraphs, to 140 characters or less. Though there is something to be said for brevity, and it takes a true master to create a mental image that can stand alone in 140 characters or less, there still is a place for longer writings. We don’t have to be in a continuous state of noise; a race to create and to consume.

Other than a few posts, such as this, all writings at Just Shelley will be spread across pages, not paragraphs, or characters. Such length will, naturally, require a commitment of your time in addition to your interest. However, I can’t guarantee that your time will be well spent, or even that your interest will be held (though the former will, naturally, be dependent on the latter). All I can guarantee is that I probably took longer to create the writing than you will in reading it.

I am using a tool to publish, true, and even providing an Atom feed. There are no categories, tags, or taxonomies, though, because everything here fits under one bucket: it is something that interests me. Taxonomies would just clutter the site’s zen-like structure, as well as set expectations I’m almost certainly not going to fulfill.

To further add to my state of web regression, I’ve not enabled comments, though I’d love to hear from you through some other means. As anachronistic as it may seem nowadays, this is not a site that’s community built. It’s not that I don’t care about you or community, or that I’m asking you to be a passive observer. My hope is that if I don’t inspire you—to talk, to write, to howl at the moon— I make you think; if I don’t make you think, I provide comfort; if I don’t comfort, I entertain; if I don’t entertain, at a minimum, I hope I’ve kept you in the house long enough not to be hit on one of those rare occasions when a meteorite falls from space and lands in front of your home just as you were leaving.

Just Shelley is my place to be still, and my invitation for you to be still with me.

My tree


XHTML and template.php

Since I use inline SVG in all of my sites, I need to serve my pages up as XHTML. I couldn’t find a Drupal module or option that triggers Drupal to serve the pages up as XHTML, so I added the following code at the very top of the page.tpl.php page:

header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    header("Content-Type: application/xhtml+xml; charset=utf-8");
    header("Content-Type: text/html; charset=utf-8");

All this code does is check whether the user agent can support XHTML. If it can, the page is served up as XHTML; otherwise HTML. Using embedded PHP in page.tpl.php for the theme works as desired. However, the content type of the page no longer agrees with the content-type meta element, which is included within the $head variable.

    <title><?php print $head_title ?></title>
    <?php print $head ?>
    <?php print $styles ?>
    <?php print $scripts ?>
    <!--[if lt IE 7]>
      <?php print phptemplate_get_ie_styles(); ?>

One solution would be to not print out the $head variable and just hard code all of the head entries. However, when you add a new module, such as the RDF module, which adds entries to the $head variable, you either have to hard code these in, also, or you lose functionality.

Instead, I used the template.php file, which is used to override default Drupal behavior. Specifically, I created a variant of _preprocess_page for my subtheme, used this to access $head, and alter it.

function flame_preprocess_page(&$vars) {
  $head = $vars['head'];
  $head = str_replace("<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />",
              "<meta http-equiv=\"Content-Type\" content=\"application/xhtml+xml; charset=UTF-8\" />", $head);

  $head = str_replace("<link rel=\"alternate\" type=\"application/rss+xml\" title=\"Burningbird's RealTech RSS\" href=\"\" />\n","",$head);

  $vars['head'] = $head;

I am still getting my head around customization in Drupal, and will have a follow-up posting later, after I’ve had more time to work through issues. In the meantime, from my understanding, the _preprocess_page passes in an array of system variables, each of which can be accessed and altered, as I’ve done in the code example. The subtheme naming is essential, otherwise I would overwrite the use of the function within the Garland theme.

There is another theme specific function for overriding variables called _phptemplate_variables, but I gather that was Drupal 5 and the approach I used is Drupal 6.x and forward.

Now, the head entries are as I want them, and modules such as RDF can add their entries without me impacting on their work. More importantly, with the addition of the XHTML support, I can add inline SVG and the SVG will display correctly for those browsers that support inline SVG.

(Note this image is now included using the IMG element. I’m now using WordPress, and WordPress does not allow inline SVG.)

hello world in svg