Archive for January, 2006

Google Censorship Viewer: US vs. China
Tuesday, January 31st, 2006

Search Censorship Viewer, US vs. China (Google)

On Wednesday, 25 January 2006, Google began providing filtered search results on Google.CN, contributing to the Chinese government’s ongoing
censorship
of the internet. This side-by-side viewer is intended to illustrate the implications of this censorship by providing side-by-side comparisons for search terms.

A few interesting queries:

It seems that, even for terms like “democracy” and “freedom“, Google.CN still returns a reasonably good spread of links. Whether or not these pages can be accessed from within China itself is a far different issue, of course.

Please leave a comment if you find any search terms with frighteningly different results between the two versions; I’d be interested what other people can find.

WordPress OpenSearch, v1.1
Saturday, January 28th, 2006

WordPress OpenSearch, v1.0

The OpenSearch API provides a flexible common standard for XML-powered searches. WordPress OpenSearch 1.0 worked on WordPress 1.5, but a few changes in the way WordPress deals with DB configuration and HTTP GET parameters caused it to fail in WordPress 2.0. Thanks to tips from James E. Robinson, III, version 1.1 of this plugin now wraps WordPress 2.0‘s search functionality. This code should be generic enough to allow anyone to quickly add OpenSearch RSS feed functionality to a WordPress 2.0 site.

The source of version 1.1 is freely available for download here.

Read the rest of this entry »

Williamsburger Maps, V3.0
Saturday, January 28th, 2006

Although this isn’t a huge upgrade, there were enough files created or renamed in the background that I felt this warranted a new major version number. There shouldn’t be any visible functionality changes here.

Bug Fixes

  • Upgraded map code to work within WordPress 2.0. See notes here.

Features

  • Extracted some of the core effects code into reusable JavaScript files (here and here).
WordPress 2.0 Upgrade
Saturday, January 28th, 2006

Today, Williamsburger upgraded to WordPress 2.0.

I ran through the DB backups easily, as well as the very quick official upgrade script. I’ve reactivated most of my plugins, although Akismet doesn’t seem to be working anymore. I’ve fixed problems with Williamsburger Maps, as well as an issue I already knew I would need to deal with to patch the WordPress OpenSearch Plugin.

The changes I needed to make to support WP 2.0 are as follows:

  1. The .htaccess file needs to have all non-WordPress regexp’s before the WordPress section, or else the new default rules will simply override any additional rules you’ve added. This appears to be a change since WordPress 1.5, where your custom regexp’s needed to be after the WordPress section.
  2. If you want to directly access a HTTP GET parameter, you can’t simply reference the variable by name, as is often the case with PHP, but instead need to use the internal $_GET function, as such:
      $id = $_GET['id'];
    

    Thanks to James E. Robinson, III‘s post explaining how to patch my OpenSearch plugin for this tip.

  3. Something strange is going on with relative links within JavaScript GXmlHttp.create calls. Previously, this code worked fine (there’s a .htaccess redirect behind the scenes, but I haven’t changed that):
      request.open( 'GET',
                    'wbmaps-map-info-' + WbMaps.Version + '.php?id=' + mapId,
                    false );
    

    With WordPress 2.0, I needed to change this to the following:

      request.open( 'GET', 
                    '/wb/wbmaps-map-info-' + WbMaps.Version + '.php?id=' + mapId,
                    false );
    

    Note the addition of the absolute directory path on my server, something I’d obviously prefer not to need to hardcode into JavaScript.

  4. The default editor for managing posts provided by WordPress 2.0 fails miserably when formatting the interiors of <pre> tags. Granted, this isn’t an issue that most writers need to care about, but considering the tool offers an “edit as HTML” button, one would hope that it would at least attempt to respect what’s been typed into that field. Also, in the case of Williamsburger, there are enough code snippets posted that <pre> absolutely must work as expected.

    Additionally, the Markdown plugin provided with WordPress 2.0 has major troubles with <ol> and <ul> elements within table <td>’s, turning them into long hex strings, and the Textile plugin inserts unwanted <br>’s between <li> elements. None of this behavior is appropriate, although Markdown’s problems are particularly unacceptable. Markdown worked fine in WordPress 1.5, so I suspect it simply needs patching for WordPress 2.0, especially considering its “Extra” version is the eventual solution I’m now using.

    PHP Markdown Extra 1.0.1 seems to solve all of the other plugins’ problems, and my posts now render as they used to, although it seems that multiple carriage returns within <li>’s don’t seem to act as they do outside of <li>’s, causing some mashed-together paragraphs if extra attention isn’t paid to adding your own <p> tags.

Simple Rules For Clarity In Code
Thursday, January 26th, 2006

As a developer, I constantly find myself reading code, sometimes with its developer at my side to clear up ambiguities, but obviously, far more frequently, the author is nowhere in the vicinity. Maybe I’m trying to sort out a bug, maybe I’m trying to figure out functionality, or maybe I’m trying to optimize performance. My first priority is to understand as much as possible about the code while wasting as little as possible time and effort.

What simple steps can developers take to help out the next reader down the line?

Read the rest of this entry »