Tag: PHP

Categories
Technology

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");
    else
        header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    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.

Categories
SVG

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:

<?php
header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    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.

  <head>
    <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(); ?>
    <![endif]-->
  </head>

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=\"http://realtech.burningbird.net/rss.xml\" />\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

Categories
Technology

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.