Category: Burningbird

WordPress is heading into beta test on 1.2, and I’ve installed this with my Practical RDF weblog (though I don’t have the old MT entries ported yet).

This release made some very good changes to the interface, including providing options that allow you to set how long a post entry field is, and what to show on the weblog edit page–the page that lists published weblog posts. You can now turn off full content and just show titles, or titles and excerpts. Much cleaner, and much easier to work with.

Excellent bulk comment management has been integrated into 1.2–the best I’ve seen on a weblogging tool. I will be modifying it to search for comments based on timeframe, to be able to bulk delete the sometimes hundreds of comments left by a spam blitz.

In addition to the change to the bulk comment management form, I have other modifications planned. For instance, both comment preview and post preview in 1.2 are based on in-page innerHTML blocks, I believe, and I don’t care for this. At all. I’ve already made a simple hack to preview a draft post within the same look and feel as my individual published posts, and I absolutely love this. I will be carrying this over with me to 1.2.

I’ll also be providing a full comment preview, rather than the inline preview. What can I say? I don’t like inline previews.

In addition, I am modifying the comment option on each post to include ‘moderated’. With this, I can turn moderation on in a per post basis. I’ve been using this with my posts over 30 days old (this being managed with another plugin), and I really like it. Now I can catch comments from spammers before they go on the page, not to mention the Google Kiddies; however, thoughtful posts are now coming through, as you may have noticed in my “Recent Comments” list. This combined with the good comment management and the throttling to prevent crapfloods is probably all I’ll do to manage comments.

I want to modify NEXTPAGE behavior to use either page numbers or ‘next’ and ‘previous’ page links. I’d also like to be able to add a ‘full page’ link to those posts where I use it. Lots of people didn’t like NEXTPAGE, and if I use it again, I want to be able to provide a workaround for those readers.

To be realistic, though, I think that there is an expectation about weblog posts that precludes them being very large; no matter the subject or the writer. You can only assume you have your readers’ attention for a specific length of time. Either you can disregard this assumption, and their attention; or you adjust your writing accordingly, and perhaps save larger works for different venues. Something to think on.

Once these changes are made, I’ll provide the code to the developers and I hope they’ll add them into the main body of the code. We’ll see.

I’ve also been playing with some of the third-party plugins and hacks. One of the advantages to a PHP-based system is it seems more natural to look at integrating other existing open source PHP-based applications into the product. For instance, a couple of efforts are integrating WordPress in with several PHP-based photographic management packages, including Gallery. Another using existing PHP code to generate PDF files for a post, including the comments. Once this is vetted to 1.2, and seems safe from abuse, I’m tempted to add this to my posts.

I am pleased with WordPress and felt this move was a good one. I was, however, a bit unhappy about some discussion on the WordPress support forum last week. It seems that one WordPress weblog was shutdown because the ISP felt it was causing a problem, but then rather than focus on fixing the situation, it became a spiteful game of ‘he said/he said’. This led to one of my initial concerns I had about WordPress is that is does have a very loyal user base that doesn’t tend to brook disagreement.

(Personally, I’m no longer interested in anything even remotely resembling religious wars about technology. All of this stuff–all of it–is just code, with an occasional segue into specs. Personalizing the tech to such an extent that being critical of the code is equated with being critical of the people behind the tech is utter nonsense, and tiresome. Not to mention deadly dull. )

However, from what I can see of the developers behind WordPress, they’re not encouraging this fan following, and take criticism in the spirit to which it is intended–an effort to help make a better product. As more people start using WordPress, I think we’ll see a more detached viewpoint of the product.

Still, there was two incidents last week when ISPs had to shut down WordPress. It does sound like it may be 1.2, and since that’s still alpha, I’m not overly concerned. The code for WordPress is clean and easy to move around; if a problem occurs, I imagine a fix will be uploaded quickly. That’s the joy of open source.

Speaking of ISPs banning software, you might want to think carefully before installing The MT Plugin Manager, third-party software to make installing plugins for Movable Type more simple. It has been banned on Hosting Matters, my own ISP, and several others I know of. But it does look like the creator is returning to work on the product.

(And did you notice that WordPress automatically translates double dashes into the ‘em’ character? )

Recovered from the Wayback Machine.

I am in the midst of trying to salvage weblog entries that have gone through many variations of URL identification, as I’ve passed from tool to tool, and through many variations of what is subjective goodness in URL naming strategies. At the same time, I am also dealing with years old links to material so far out of date it’s laughable to even think about having ‘this is dead’ notices for it.

The problem with old URLs started becoming extreme enough at my site for me to write an application, PostCon, which I’ve talked about previously. PostCon provides the ability to selectively annotate the information that is returned for old URLs that have been pulled, or to manage URL movement. All well and good – but ultimately in the end, I knew I would reach a point of having to just letting the URL die a natural death.

Tim Berners-Lee has stated that Cool URIs don’t change, but he said this back in 1998, when the Web was only a few years old and we thought that the inherent goodness of the Web was based on accumulated knowledge. Now, over a decade after the Web’s birth, we’re finding that the Internet is an ocean and URLs are rocks around our neck, and with each passing year, the water is getting higher.

I had a domain, yasd.com, which I’d had for years and accumulated a vast number of URLs to funky (in the bad sense) material within that domain. The content the URLs reference is badly outdated, much of it to long dead technology. There were page examples for dealing with the beta version of Navigator and IE and how to deal with cross-browser differences and so on. None of the examples have worked for years, and for the few that I managed to pull from version to version, I finally gave up when Mozilla seemed to splinter into many sparkly pieces, and there are now so many different variations of browser/operating system pairs that the only way you can hope to survive is making sure that you work to the most common standards (not necessarily the newest or even the best).

The yasd.com domain was also tainted, long time ago, because there are so many variations of what ‘YASD’ means. For instance, a popular meaning for YASD is “Yet Another Sudden Dead”, a gaming term, and it is through this that I started getting so much of my email spam: kids were using the domain, yasd.com, as a phony sign up email address whenever they wanted a throwaway address.

Rather than continuing to renew yasd.com, and dynamicearth.com, and p2psmoke.org year after year, just to maintain that URL ‘coolness’, this year I’m letting them go.

(The moment I released yasd.com, the email spam coming into my email system fell by 80%.)

Now, before releasing these old domains, I could have setup permanent redirects for the old domain URLs to URLs on my new domain, and I suppose this would be the proper thing to do – but why? There is no value in this old material, and neither is there any additional value with posting a note saying, “This material is out of date and no longer supported.” Though the message might be more meaningful than getting a generic 404 error message, the benefit of providing it is offset by the cost of continually maintaining these old, old, old URLs. Doing so might be ‘cool’–but there is no value either to myself, to the search engines, or, ultimately, to the person arriving at my site from an old, old, old link.

(Unfortunately, the registrar I have, rather than letting the URLs relapse gracefully into a 404 status (and hence letting Google clean out its database), insists on persisting the domain for a time to try and get me to renew it. So if you search on “C# book” and go to what was the Google link to this (third down from the top), you’ll get a foolish registrar generated page instead. )

That takes care of the old and useless, but what about the relatively new and possibly useful?

For the good URLs, ones to pages that still exist, I use rewrite rules in .htaccess wherever possible, and then use PostCon for the rest.

(The .htaccess file is a file consumed by the Web server with directives telling it how to manage specific page requests, including redirects from old page URLs to new. One directive provides a pointer to an error handler file or application that handles all ‘bad’ page accesses, and I use this to point to my PostCon application.)

For the many weblog URL lives: I used .htaccess when I went from individual entry pages ending in .php to ones ending in .htm, and I used PostCon to manage the redirects when I went from numbered pages to ‘cruft-free’ URLs–URLs that are based on a archival data and post title. But now, I’m faced with an interested challenge.

When moving from Movable Type to WordPress, I went from a category-based archive to one based on the date. I could generate .htaccess entries for each file using Movable Type, and since I’m moving the archive location, the only .htaccess file that would be impacted by such a large number of redirects in the one in my old archive location.

However, a second problem arises with the conversion from MT to WordPress and that is both products default to a different separator character when generating ‘dirified’ URLs. Movable Type uses ‘underscores’ (’_’) for all of the replaced characters in a title, such as the spaces; WordPress uses the dash (’-‘).

(Though I appreciate the efforts undertaken, in my opinion the Atom effort would have paid for itself ten times over by now if instead of focusing on the syndication track first in its efforts (which I hasten to point out is now my new default syndication feed, so don’t get pissy with me), it focused on porting behavior instead–including an overall agreed on definition between the tools as to what is a ‘cruft free URL’.)

There are page specific and programming specific ways of working this issue, none of which I’m entirely satisfied with because I don’t want to maintain all of the old files at the old location over time. What I can do is write code to create .htaccess entries (or PostCon entries) that map between the different filenames, including managing the underscore to dash conversion.

In addition, I may be able to create a rewrite rule that handles the conversion for me, including the conversion based on category (by discounting the categories and handling individual title overlaps) to date, not to mention the underscore to dash.

But then I’m faced with the decision: do I want to use underscores, or do I want to use dashes?

Further research shows that supposedly to search engines, the underscore is seen as a part of the search phrase, while the dash is seen as nothing more than white space. On the other hand, others swear by the use of underscore, and feel that it makes for a more ‘attractive’ URL. In addition, they state that smart search engine bots know how to handle both dashes and underscores.

(Oddly enough, much of this discussion is encapsulated in a forum thread having to do with pMachine’s new ExpressionEngine application. )

I can always alter the code for WordPress to work with underscores instead of dashes, but do I want to?

Before I finish this last URL cleanup task, managing the weblog archive URLs, I seek further opinion from others:

In intelligent URLs, is it better to go underscore or dash?

A trackback got through on MT, and ended up causing a rebuild that overwrote the stylesheet, index.php (which is the WP template), and various other files. Luckily, this time I had backups.

Trackbacks should have been turned off, but with all the hacks to overcome spamming, turning TB off in the database isn’t reliable.

If you do move from MT to WP, you’ll have to move the MT installation. Completely. You can’t trust that something won’t sneak through and cause a rebuild.