February 24th, 2008

Jeff has been adding SVG annotation, as well as objects to his weblog design. When using SVG, the first issue that arises is serving up XHTML in order for the SVG to be processed correctly. This also means serving up your Atom feeds, accordingly.

In Jeff's case, he's using the object element to incorporate SVG annotating the post type. If he inlined his SVG, and wanted it processed correctly in feed readers (both big 'ifs'–stripping out the SVG is also an acceptable response), two things need to be modified.

First, there's an html_type option value that needs to be adjusted. The only want to do this at this time is to manually update it in the database. I had thought there was a modification made to Wordpress to add this as an Administration option, but I couldn't find it in the checked in code.

I hard coded my feed for this weblog to XHTML, and made the appropriate adjustments, removing the CDATA section and adding a wrapping DIV element (source for feed and comments feed).

To ensure the two feed files don't get overwritten, I have a plug-in that I use to override the location of the atom feed files, pointing the location to files in my theme directory.

This is only a temporary fix, though. The real fix would be to provide an option to set the html_type in the admin page, which then serves the weblog pages up accordingly, as well as being used to set the type in the feeds. The value should also be used to determine the output of the content in the feeds.

All of this could be done in plug-ins. What can't, is handling input from readers when serving up XHTML pages. Input from readers enters Wordpress in several different places in the code, most of which do not have hooks allowing us to override the code to provide our own. The only way Wordpress will be able to effectively do XHTML is through a commitment to make this a change in the underlying base code.

Since the Wordpress developers have not shown any interest in supporting XHTML, and since I haven't seen a lot of interest in XHTML support in Wordpress from my own explorations and published posts, this is just not a challenge I've been eager to take on.

The real question is will Microsoft support the XHTML MIME type in IE8? Not having support for XHTML is one of the major browsers is probably the biggest hold up on more widespread support for XHTML. Otherwise, I would think that the increasing interest in SVG would start generating enough movement towards XHTML to finally trickle it's way into the Wordpress community, regardless of the aversion to XHTML of the development team.

PS I would appreciate help testing my current XHTML validation in my comments. You can't hurt anything with the way the comments are now currently moderated.

July 14th, 2007

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.

Bonus link: PHP MVC Frameworks and their PHP4/PHP5 compatibility.