XHTML and the Forum

An issue I had with supporting XHTML in my WordPress weblogs is that it can be difficult to control others’ input in comments. I solved the issue with Drupal by not supporting comments directly on posts. Instead, I’ve provided a forum, using the Drupal Forum module, here at RealTech. I’ve only provided the one forum for all of my sites to make it simpler for people to register, as well as follow any active discussions.

To ensure that Forum pages don’t create XHTML errors, I modified the PHP to serve pages as XHTML to exclude URLs that have the word “forum” in them. I realize this will impact on any page with ‘forum’ in the title, such as this page. However, it’s unlikely that I’ll be using inline SVG and the word “forum” in the title for the same post.

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

In addition, I turned filtered HTML on for forum entries, as well as installed htmLawed, to ensure that the entries are as clean as possible. Regardless, a problem in the forums won’t take down a post, and that was my main criteria for making this change.

The forums should also provide a much more flexible communication system. You can use your OpenID to register, or just register directly. You can still comment anonymously, though the comments are moderated.

Typically, any person who registered is an authorized user and could create forum topics. Well, I wasn’t quite ready to make that leap of faith. I created a “trusted” user who can create forum topics and will reserve this user classification to people I know. I then adjusted the permissions to enable forum topic creation for trusted users and admins, only.

I’ve created main forum categories. Over time, I imagine I’ll need to adjust the forum categories to be general enough to be useful, without being so general that it’s difficult to find discussions of interest.


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


Movin’ on up to PHP5

Recovered from Wayback Machine.

The PHP group has announced end of support for PHP4 and encouraging everyone to move on up to PHP5.

WordPress Matt isn’t happy with PHP5 and believes such a move should happen when PHP6 goes beta. I think the point really is that the PHP group can’t move forward on PHP6, while still trapped in support for PHP4.

I’m actually not unhappy at PHP5, though I do still tend to develop in PHP4 mindset. In Matt’s comments, Michael Moncur wrote:

I think every language reaches a point in its development where it’s “good enough” – and it becomes popular. Advancing the language after that is often a matter strictly for the hardcore programmers and academics, and the versions they create after that point are rarely widely adopted.

I’m not sure what the solution is, but app developers shooting themselves in the foot is unlikely to be it.

Personally I’ve avoided upgrading to PHP5 mostly because PHP4 is “good enough” and runs the apps I need (and the ones I wrote myself). I guess I’ll eventually be dragged into the upgrade kicking and screaming like I was with Apache 2.0. And MySQL 5. And Perl 5 and 6. And…

If you want to talk about the king of slow upgrades, Apache 2.0 is the winner, by far. I never thought much about Perl because I rarely work with it nowadays. However, the MySQL upgrades have been drastically different. Each new version of MySQL brings with it desperately needed and wanted functionality. I think the only hold back on upgrades with this database is how ubiquitous it is, and how hesitant people are with using ‘new’ database releases.

My hosted environment is running PHP5 and MySQL 5, and my main development machine, the last of the Powerbook G4s, runs Apache 2, PHP5, and MySQL 5 (installed via Darwin/Mac Ports). For the most part, I’ve not had any software that required earlier versions of any of these applications. Whatever I work on for my own amusement and interest works for PHP5 and MySQL 5; I don’t test with earlier versions. Good or bad, that’s a choice I made with host and with my own setup (I could run multiple versions for testing, but I don’t choose to). For my contract work, I’ll work in whatever environment I’m given.

The Go PHP5 effort should help make the point that apps need to move forward. Matt may think the site is corny, and that PHP4 being dropped is a no story, and that PHP5 is awful/nasty, but the news release and the site get the point across–like it or not, PHP4 is going away.

Now, if we can only make earlier versions of IE–such as IE 6.x–vanish, I would be happy.


Clashing colors

Hell grant soon we hear again the swords clash!
And the shrill neighs of destriers in battle rejoicing,
Spiked breast to spiked breast opposing!
Better one hour’s stour than a year’s peace
With fat boards, bawds, wine and frail music!
Bah! there’s no wine like the blood’s crimson!

Ezra Pound’s Sestina: Altaforte

What a serendipitous time to introduce my latest stylesheet creation: Clashing Colors. It’s been said that our words are all that matter; that the colors and pages we wrap around ourselves are but a gilding of a lily, and why is it that we don’t provide full feeds in RSS files?

What matter our page design?

It’s also been asked: why can’t we all just get along? Yes, why can’t we get along. Is it because we’re both unique and imperfect?

I have found there are six degrees of separation between these statements:

Why can’t we all just get along

…why can’t we complement each other

…why isn’t this environment more complementary than contentious

…so much of our writing to each other is contentious

…contentious or not, all that matters is the writing

…all that matters is the writing

What matters our page design?

Clashing Colors uses PHP to dynamically generate colors for different elements of the stylesheet. It also uses a random photo generator, except unlike Random Shot, the photos are all weather related and in black & white. The bit of code and CSS that controls blockquote is as follows:

blockquote {
$hx = substr(‘000000’ . dechex(mt_rand(0, 0xffffff)), -6);
echo “color: #” . $hx . “;”;

Just use the $hx=substr… statement for each color area.

When I was playing with this page, I was surprised at how many times an attractive color combination appeared. Perhaps we worry too much about making sure everything fits together, and should just let chaos reign.

The man who fears war and squats opposing
My words for stour, hath no blood of crimson
But is fit only to rot in womanish peace
Far from where worth’s won and the swords clash
For the death of such sluts I go rejoicing;
Yea, I fill all the air with my music.

Papiols, Papiols, to the music!
There’s no sound like to swords swords opposing,
No cry like the battle’s rejoicing
When our elbows and swords drip the crimson
And our charges ‘gainst “The Leopard’s” rush clash.
May God damn for ever all who cry “Peace!”

And let the music of the swords make them crimson!
Hell grant soon we hear again the swords clash!
Hell blot black for alway the thought “Peace”!

Then again, maybe not.


To save a specific set of colors, do a screenshot of the page and then use a color ‘eyedropper’ application to pick out the individual colors. Adobe Photoshop has this functionality, as does several other graphics tools. Or you can download a shareware application that works quite nicely.

Just don’t update the page until you grab that copy.


Mixing Violence and Tech

Recovered from the Wayback Machine.

This is fun: O’Reilly’s PHP DevCenter picked up my quote from Scripting News  for the PHP Digest:

“I will continue to beat you about the head on this issue until you ultimately bow to my superior knowledge on this subject.”

I must remember to mix threats of physical violence and technology more often.