BBCODE was designed for this purpose. There is no actual standard, but the core syntax seems fairly uniform. It’s good for those used to forums, where it seems to norm.

HTML markup is nice because it is a standard, even if varying subsets are supported. Learning a little HTML isn’t going to hurt anyone, at least for the next 20 years or so. The problem is that HTML was never intended to be hand edited. The syntax is not the most inviting, and different HTML-like markup languages handle whitespace differently than the HTML standard.

Wiki markup syntaxes were designed to be human friendly. The main problem I have with wiki syntax is that there is no standard. It seems like every wiki has a different way to formulate a link, for example. I guess there is some progress with Wiki Creole, but I still have a bad taste in my mouth.

The other problem I have with wiki markup is that I find it to be non-deterministic. When I edit any given wiki and try to use more than basic formatting, I never know what I am going to get. Most of the markup processing engines for these wikis are impenetrable morasses of regular expressions. It can be hard to gauge interactions. Are you really sure they are secure?

Speaking of impenetrable morasses of regular expressions, have you ever looked at WordPress’s input path? I’m sure every one with a WordPress blog who likes to blog about PHP code knows that it is a code eater. I’ve been particularly disappointed with WordPress in this area. Most the “code formatting” plugins still have problems protecting code from WordPress’ heavy hand.

But the WordPress preg_replace gauntlet doesn’t just mangle code. I have a post which has been sitting in draft mode for several weeks because I can’t figure out how to give it the proper markup. WordPress is somehow taking my perfectly balanced input markup and producing “unbalanced” output markup. I haven’t yet tracked down the problem to either submit a fix or to do a good bug report. Frankly, I’m not looking forward to trudging through all those regular expressions.

In Chris’ post, he takes the regular expression approach. Folks in the comments have pointed out a few problems with his approach, including the problem of interleaved tags. If you can’t tell by now, I am not a fan of the regular expression gauntlet approach to markup languages. I prefer a defined syntax and a traditional computer science style parser (which may use regular expressions).

The other must-have is a preview option. With so much variation in markup languages, not having a preview leaves the user to play Russian roulette with their submitted content. I’ve talked about that before in the usability of input filtering. This is another area where WordPress leaves the user high and dry.

The complex input path in WordPress combined with its reliance on global variables seems to leave it unable to do an in-page preview. The admin area preview is an IFRAME so that it launches a separate request. The various live preview plugins are JavaScript based and don’t work when it is disabled. They also don’t pass the input through the same input path that WordPress uses, so they are not a true preview.

I don’t mean for this to be a WordPress rant, on the whole, I like WordPress. Rather, I just wanted to point out how hard it can be to do good input filtering, that is safe, reliable, deterministic, and usable.

Welcome Back Harry.

Also, unless I’m mistaken, it looks like SitePoint is using WordPress for their blogs now. Or has this always been the case and I’m just now noticing it?

Unfortunately, this version of WordPress introduced one bug that really annoys me. Pingbacks and Trackbacks aren’t using the permalinks, but instead using ugly query string links.

A little greping suggests that this is caused by a cache that becomes stale after a post is updated. So, I think the solution is to insert this line:

 
unset($post_cache[$post_ID]);
 

on line 382 of wp-admin/post.php.

Since this post contains a link to another blog post, which should get a pingback, it will be my public test of the theory.

UPDATE: Bug fixed.

When i started blogging, I didn’t know quite what to expect. Over time, two main topics emerged: PHP and Politics. I’ve decided that the two topics should really be two separate blogs. This blog will continue to focus on PHP, software design, web design, agile methods and open source. To reflect the tighter focus, I’ve renamed this blog from Jeff Moore’s Blog to Professional PHP. (Getting rid of the bad-software revealing apostrophe in the name was a major goal.)

All other previous posts have been redirected to my new blog, Lively Debate. That blog will cover politics, economics, education, entertainment and food. Check it out.

The old posts on these topics remain on this blog, but are redirected to Lively Debate. There will be no new “non-professional” content here.

As part of the process of bifurcating blogs, I’ve changed the category structure here as well. Some categories have been moved. The software development category has been deprecated. All the posts except this one have been removed from that category.

Some people subscribed to the software development category in order to avoid the political content. If you have done so, I would encourage you to subscribe to the main site feed now. In a couple weeks, I will delete the software development category and redirect the feed to the main site feed. (Once the political content slides off the bottom of the feed.)

My summer posting hiatus should be over (my blades broke and frost will soon drive me from the garden). I have a backlog of draft posts to clear out. I’ve been waiting to post until after making these changes and am anxious to start again.

I apologize for any technical inconvenience of the switchover (new blog, new name, new theme, new categories and new hosting).

I want to say thanks to those who actually read my ramblings.

Thanks.

The new features in 1.5 are nice. I notice a few little navigation extras in the templates. The admin area seems like an improvement. I like the dashboard.

The comment moderation process has improved from miserable to annoying. I think it may now be easier to dispatch spam within WordPress instead of phpMyAdmin, which I was using with 1.2. The ‘Check Past Comments against moderation list’ is a great idea, except it doesn’t pay attention to comments that have already been manually approved. Now if only there were a ‘Check Past Comments against Blacklist’ option. An ‘Add This Url to Black List’ command would be useful on the comment moderation page. It would also be helpful to have a note on why a particular comment ended up in the moderation list for debugging false positives. Oh well, there are probably plugins for all of these things.

I started to play around with a custom theme. The theme system is very nice. I think the CSS in the default theme for 1.5 is easier to understand that the CSS in 1.2. If you visited the site this afternoon, you might have caught a glimpse of various themes, including my custom theme. Unfortunately, I found that many of the downloadable themes don’t display correctly on Safari, my default browser. This is not uncommon to run across small blogs that don’t layout correctly in Safari. My problem is the opposite. My CSS never works right in IE/Win. I hate that CSS is so finicky and requires so much manual testing.

Still no built in preview capability for comments.

I’ve been waiting for the official 1.5 release for a while and overall, 1.5 is very much worth the wait.

The biggest problem for me by far, though was that WordPress 1.0.2 supported BBCode, which I used for my posts. WordPress 1.2 does not. So after my upgrade, it looked like I had three options: restore my backup, edit my all my posts, or add BBCode support to WordPress.

Of course I added BBCode support to WordPress because that only took 10 times as long as editing all of my posts to use one of the other markup styles provided.

I started with PEAR:: HTML_BBCodeParser. Unfortunately some of its markup processing is brittle and the design could be better. I fixed its case sensitivity and changed some of the markup generated to pass the XSS filter that WordPress uses. I also de-PEAR-ified it, making it easier to distribute as a plug in.

I also had a problem with the WordPress plugin protocol failing to call one of my hooks at the right time, causing my BBCode not to be processed in my feeds. It took me a while to find and fix this problem. Sadly, there was nothing I could do in the plugin. The fix required modifying WordPress. But, hey, plugins are a new feature of 1.2. Unfortunately, my embarrassing broken feed was captured forever at artima.

When I first installed this software, I told myself that I wouldn’t even look at the code, I would just use it like Joe User would. That didn’t last.