True openness in government

Aaron Swartz notes that the stimulus bill requires that each government agency report the money they give out with Atom or RSS.

For each of the near term reporting requirements (major communications, formula block grant allocations, weekly reports) agencies are required to provide a feed (preferred: Atom 1.0, acceptable: RSS) of the information so that content can be delivered via subscription.

Furthermore, the recovery.gov website is based on Drupal.

WordPress Conversion Notes

I’ve cleaned up a few more issues with the Drupal to WordPress conversion. The major remaining issue is converting users. If I can get an acceptable solution for users, I’ll set up a public test site. I may just have to require all users to reset their password the first time they log in.

One common issue when switching content management systems is changing permalinks. If a lot of sites link to specific articles, all of their links could get broken. However, there’s a very simple solution with WordPress. Go to Permalink settings and create a custom link structure of /node/%post_id%. The article URLs will then remain the same as they were with Drupal.

Most WordPress themes include the full article on the home page, but for MacMegasite I’d like to have only an excerpt. That’s also very easy to fix: in the theme’s index.php, look for the_content() and change it to the_excerpt().

If you’d like to try out my conversion script or have any ideas to improve it, it’s available at drupal2wp.php.

Drupal Disappointment

I’m becoming very disappointed with Drupal, due to version 6’s lack of backward compatibility. A lot of very basic modules still haven’t been upgraded to work with Drupal 6, yet they’re already working on Drupal 7. I still haven’t upgraded any of my sites to Drupal 6 and I probably won’t upgrade them. I doubt if I’ll be able to upgrade to version 7 either, without first upgrading to 6.

Corey Smith wrote about moving from WordPress to Drupal, but I’m thinking of going the opposite way. Daniel first brought up the idea of moving MacMegasite to WordPress, which I discounted at first because it would lose a lot of functionality.

I would be losing the forums, buddy lists, the point system, and some of the less-used features like feed aggregators & user blogs. Some of these features could be implemented with WordPress plugins and a separate forum system. The most critical feature is the ability to have multiple authors, which WordPress supports.

On the plus side, WordPress is a lot more attractive, with more professional looking themes, and a much nicer content entry screen. I’m concerned that WordPress seems to use more GPU according to MediaTemple’s GPU usage report. My Drupal sites use anywhere from 0.0005 to 0.0014 GPUs per hit, while this site uses 0.0017 or more GPUs per hit. It may be a due to the plugin configuration.

I’ve seen a few articles about moving from Drupal to WordPress, so I know it’s been done. It would be a big project, so I probably won’t do it until after I finish my current projects and release the iPhone apps I’m working on.

Spambots running rampant?

I noticed something very unexpected in my MediaTemple account GPU usage report: an unusually high number of hits for /user/register and /user/login, which I would expect to account for little or no usage. The only explanation I can figure is spambots attempting automated logins & registrations.

GPU Usage Reports
Uploaded with plasq‘s Skitch!

prMac simplified my workflow

A lot of the news I post at MacMegasite comes from prMac. Until now I received the news articles via email and would clean up, reformat, and post the items manually. Recently the people at prMac released a Drupal module that automatically retrieves and post news. For the last few days I’ve been having it automatically post news, since I haven’t been available to post anything myself.

Drupal 6 disappointment

I’m starting to get pretty disgusted with Drupal 6. I took another look at it today and the module compatibility situation is still dismal. Common modules like CCK and Views still aren’t fully compatible with Drupal 6. For MacMegasite, I would lose the buddy lists, user points, and custom home pages. The situation is even worse for WorldBeatPlanet and my2unz, where I depend on media support and custom node types.

I realize most of the Drupal modules aren’t developed by the core team, but they should make an effort to work with module contributors to ensure compatibility and officially support some of the more critical modules such as CCK & Views.

Evaluating Drupal 6.0

I’ve been trying out Drupal 6.0 and it looks like this will be one of the most painful upgrades. I tried it with a local copy of MacMegasite and I found that it broke almost everything.

I don’t use too many modules, but I use some pretty basic stuff like user points, buddy list, bbcode filter, adsense, service links, and twitter. None of them are compatible with Drupal 6 yet. It’s been in development for over a year, and most modules still haven’t been upgraded to work with it.

I avoided using betas of 6.0 because of the module compatibility problems, and I find that the problem still exists in the release version. It looks like I won’t be upgrading any of my sites too soon.

Drupal 6.0 Released

Drupal 6.0 has finally been released. This weekend I will probably start working on upgrading MacMegasite, since it will be a lot more straightforward than worldbeatplanet or my2unz, which depend on a lot of extra modules for content types and features.

Some of the enhancements in Drupal 6.0 I’m especially excited about include:

  • Simplified administration: instead of entering weight values to reorder menus & blocks, you can drag and drop to rearrange them.
  • OpenID support: I can allow logins using OpenID to simplify registration.
  • Improved theming: Themes use less PHP code, so most customization can be done only with CSS & HTML templates.
  • Improved security
  • Improved performance