The long awaited release of Podcasting 2.0 has arrived! In this release, we have done the following:

• Podcasting is now supported by Spiral Web Consulting.
• Corrects feed URL issues when a category with the name “podcast” existed. Note: Due to this change, the URL for format feeds has changed slightly.
• Fixes a bug that prevented new enclosures from being added.
• Converts Podcasting to a class-based plugin. This will make adding new features easier.
• Drastically improves new/edit enclosure interface to conform with WordPress 2.7 design standards.
• Adds an option to disable WordPress’ automatic enclosing of file URLs.
• Allows HTML to be entered in the text fields surrounding players.
• Adds an option to use the video player for audio files.
• Adds support for handling 404 error situations more gracefully.

For more information on Podcasting 2.0, please check out the Podcasting section of Spiral Web Consulting’s new plugin site.

Google Analyticator 3.0 has also been released! In this release, we have done the following:

• Google Analyticator is now supported by Spiral Web Consulting.
• Corrects bugs preventing both external and download link tracking from working.
• Adds settings to configure the external and download link tracking prefixes.
• Changes the way disabling admin tracking works. Now uses a line of code instead of removing the tracking code altogether. This will allow features like the site overlay to work.

For more information on Google Analyticator 3.0, please check out the Google Analyticator section of Spiral Web Consulting’s new plugin site.

I would also like to announce the release of our newest plugin, SVN Tweet. SVN Tweet is a newly developed Beanstalk to Twitter Web API. This script is developed specifically for using the Beanstalk Web Hooks integration technique. This script will take the information given by Beanstalk from every commit message, strip unnecessary characters, and then pass the correct message to Twitter. This will eliminate extra characters that may be submitted to Twitter by Beanstalk using their normal Twitter integration. This will also allow more of the actual commit message to be displayed because of Twitter’s 140-character limit.

If you like these plugins, feel free to assist us in supporting these plugins by using our new User-to-User Support Forum.

Starting today, there is now a Twitter account called SWC_Plugins. The latest development news (a.k.a. svn commit information for those of you in the know) will constantly be available there for your viewing. Work is occurring on both plugins almost daily at the moment, so feel free to start following that account for your latest development news.

For those of you looking for a status update, today I just finished converting Podcasting to an easier to manage, class-based plugin. This update was long over due on my end, and will make development much easier in the future. With the completion of the class conversion, comes a very important fix for those of you having issues adding new files. There is no ETA on the version at the moment, but I promise it’s not far away.

As for Google Analyticator, I’m very well aware that external links are not currently being tracked. This is very high on my list of things to fix. Again, no ETA, but sooner rather than later.

P.S. For the smart ones, yes, there is a big announcement coming for my plugins, as well as my freelance career in general. Stay tuned, this is going to be good!

In fact, for those Podcasting users out there, you’ll be enjoying Podcasting even more. Over the past few months I have been slaving away adding more features to Podcasting. That release is now available. While 2.0 is still not out of beta, I feel confident enough with my code to call it the official version. Let me know what you think of the new version.

Finally, you will also notice there are quite a few plugins that I have dropped support for. These are plugins that never really found a great user base or are now obsolete. I only have so much time to work with, so unfortunately those plugins are no longer supported. If anyone wants to take over the development of any of those plugins, feel free to. I will happily give you commit access and a redirect if you’re committed to maintaining the plugin.

Fixing My MT WSSE Authentication Problem

Earlier this week I received a great deal of help from two Movable Type developers, Mark Paschal and Byrne Reese. After finding the source of my issue, Mark took a closer look at the specific problem. His diagnosis: I had a bug in my end of the WSSE authentication.

After spending numerous weeks working with the Atom Protocol Exerciser, I came to rely on it as a crutch. Whenever my Atom retrieval failed, the APE always succeeded. Well, that turned out to be a bad habit. Movable Type’s WSSE authentication was implemented differently than the APE, and thus the APE was useless against it. So, when I ran into a problem with my code and the APE didn’t work either, I assumed the issue was on MT’s end. That was simply not the case.

After Marked looked at my code, he informed me my nonces were repeating. The AtomPub library I had be using did not rebuild the nonce after each sequential request, and therefore failed to authenticate on the second Atom request, the list of posts. After I added a snippet of code Mark suggested, everything started authenticating perfectly.

So, this entire issue came down to one line of code on my end, and it could have been completely avoided had a took a closer look at my end of the code. Had I approached the problem differently, I am confident I would have found the repeating nonces, but I didn’t even look in that direction. I will definitely be taking this programming lesson with me into future projects.

The Status of the Movable Type Importer

Now that everything is authenticating, the MT importer is not far behind. I’m currently putting the finishing touches on some changes I had to make that differed from TypePad. Once those changes have been made, the importer should be working fine. I expect the MT importer to be completed over the next couple of days, and I should finally have everything submitted to WordPress’ Trac.

The WSSE Authentication Problem

I want to preface my findings with this advisory. I do not have a full understanding of Perl, and my statements may be wrong. If anyone can correct me, please do. I would rather be told I’m completely wrong than continue down the wrong path.

Late last night while inspecting MT’s Atom API code, I found the troublesome line of code (/lib/MT/AtomServer.pm, line 168-170):

if ($nonce_record && $nonce_record->id eq $auth->{Nonce}) {
        return $app->auth_failure(403, "Nonce already used");
}

When commenting out this line of code, the authentication passed, and I was finally seeing a list of posts stored in Movable Type’s database. Once I realized this was the problematic line, I started investigating what this line is doing. From my limited understanding of Perl, this line is checking to see if the nonce has been used in the past. If it has, the check fails to authenticate.

Once I realized this, I looked at my nonces being sent. I verified each nonce generated was different from the last one, eliminating the possibility of the problem being on my end. This tells me somehow Movable Type is incorrectly adding the current nonce to the list of previous nonces before performing that check.

Looking at the slightly bigger picture:

my $app = shift;
my $auth = $app->get_auth_info
    or return $app->auth_failure(401, "Unauthorized");
for my $f (qw( Username PasswordDigest Nonce Created )) {
    return $app->auth_failure(400, "X-WSSE requires $f")
        unless $auth->{$f};
}
require MT::Session;
my $nonce_record = MT::Session->load($auth->{Nonce});

if ($nonce_record && $nonce_record->id eq $auth->{Nonce}) {
    return $app->auth_failure(403, "Nonce already used");
}
$nonce_record = new MT::Session();
$nonce_record->set_values({
    id => $auth->{Nonce},
    start => time,
    kind => 'AN'
});
$nonce_record->save();

From what I’m understanding, the code appears to add the nonce to the record after checking, however, the nonce is passed through MT::Session->load before the check is performed, indicating that may the source of the issue. Sure enough, MT::Session->load is the problem. After replacing the passed nonce with a blank string, the nonce is no longer in the list of previous nonces and the check passes.

I have notified Movable Type’s developers of this problem, and I hope to hear back soon. The good news is once this error is resolved in Movable Type, the importer should work wonders. The bad news is it may be a bit until the next version of MT is released or the bug is fixed. I’ll try to keep everyone updated on the status as I hear back from the developers.

Future Branches of the Atom Importer

Beyond working with Movable Type, after talking with Lloyd this week, we have decided to look into the possibility of porting the importer to other platforms; namely Vox and WordPress itself. We talked about Vox as there is currently no importer at all, as Vox lacks export methods and APIs such as XML-RPC. The idea for WordPress came up because we thought it might be a great way to move a blog from location to location without having to deal with export files.

Over the next week I will be looking at creating those branches of the importer. Thankfully, since the Atom API is a standard, I should be able to quickly and easily make the ports. We’ll see how that goes next week.

Bad: Regular Expressions Are Not My Thing

While working towards media importing this week, I had to write a few regex statements. I’ll admit it, I completely suck at regular expressions. They bring me back to my not so fond days of Discrete Mathmatics; days I would rather forget. Regardless, I managed to get through them and ended with some working code.

Good: Faster Response Times From TypePad

I noticed while working on media importing, TypePad’s server have greatly increased in speed this week. I found that importing took roughly half the time it did in the previous week, with no code optimizations on my part. The speed increases managed to stay consistent through the week, so I’m hoping the changes are here to stay.

Bad: Media Importing is Near Impossible

Wednesday came to a grinding halt when I noticed there was no way to reliably import media by parsing images from posts. There are several reasons to this:

• TypePad has two different methods for uploading images.
• The markup TypePad generates for images is unclean and is not standardized. Users have the ability to modify the output code template.
• TypePad puts the full size image on a separate HTML page that is linked to via a URL that tells nothing about the original file. Due to this, it is near impossible to link the full size image with the originating link.

So, media importing is unfortunately looking very glum. I will try to come up with something since importing media is a crucial feature in my book, but I’m not sure what. More on this in the coming weeks.

Good: WordPress 2.6 Released

The new version of WordPress was released this week, and I was happy for several reasons. First off, I was able update my blog and take advantage of the new features, but more importantly, trunk is going bleeding again. Hopefully in the next week or so the TypePad importer should land in trunk. Stay on the lookout!

Good/Bad: Headway Made on Movable Type Authentication Issue

I managed to get in touch with the developer over at Six Apart who originally wrote Movable Type’s Atom API implementation. The good news is he confirmed I’m not crazy and MT is authenticating differently than TypePad. The bad news is he couldn’t remember off hand what is different with the implementation.

From what it sounds like, MT is not following the RFC 5023 spec in regards to WSSE, simply because the specification was not standardized when the original code was written. I’m not sure where this leaves me, because I don’t really know what is different with authentication at the moment. Also, I’m unsure if Movable Type will correct the authentication difference in the near future.

At the moment, it appears I will be brushing up on my Perl skills and looking at the source code for Movable Type next week. With a little luck, this issue will finally be ironed out. Who knows, maybe I’ll even figure out something for media importing next week as well. Right now, I’m just hoping next week is the week of miracles.

Why Import Media?

The first question I asked myself this week is why should TypePad’s media be imported into WordPress. This was a relatively easy question to answer. TypePad, being a paid service, will delete and remove all content when canceled. This includes images uploaded and stored in TypePad’s cloud. So, importing images and the like is important if a TypePad switcher does not want to see broken images all over the place.

Can TypePad Media Be Imported?

After determining media importing is essential, I explored my options for getting media into WordPress. Thankfully, TypePad has an AtomAPI for their web galleries. Unfortunately, from my testing this Atom API does not include single image uploads. So, the Atom API may be out of the question for media importing.

Since Atom API media importing appears out of the question, I started looking at their XML-RPC documentation. To no surprise, they do not have a method for retrieving media through XML-RPC. Therefore, I’m left with one option: finding media through URLs during the import process.

Sadly, this option is not ideal. For one, it will add time to the already slow import process. Also, this option will force media to be imported at the time of the initial import, since the content can only easily be traversed during the post import. So, I’m not too pleased with my options.

Next Week

Next week I plan on starting to code the media importing during the import process. I plan on making this optional, since it will most likely add significant time to the import process. However, before I do that, I will go through my options one more time. If anyone thinks of any alternatives from now until then, I’d love to hear them.

This Week

This week saw the addition of Atom URI detection based on the straight blog URL. To detect the Atom URI, I have to parse the HTML page for the RSD page, then parse the RSD page for the Atom URI. It’s a multi-step process, but the most reliable should TypePad ever change the Atom URI on me. In fact, I’d like to mention that every single URI (comments, paging, etc) is automatically detecting within the importer, so the importer should be URI future proof.

In addition to AtomPub URI detection, I added a progress bar this week. I thought this would be a huge process, but thankfully the coding was relatively simple. I learned some techniques to force PHP to dump the output buffer, essentially updating the page. Paired with some simple Javascript, I was able to create a fairly responsive progress bar. I chose this method over a completely Javascript method since the Javascript method would require additional time to run (I can explain this technically if anyone wants to know why).

Overall Status

Since we’re at the midway point, I thought now would be a great time to look back at the overall status. As I mentioned earlier in the post, I choose this date as the ready for core inclusion date. Since the release cycle for WordPress 2.6 has been pushed up, core inclusion will most likely be pushed back since the AtomPub importer will not be ready for 2.6. Regardless of the actual core inclusion, the deadlines have not changed in my mind.

According my requirements for core inclusion, by now the importer should be converting AtomPub data in to actual WordPress data. That’s occurring, so I’m definitely still on track.

The Second Half

So, where’s the importer going from here? Well, I plan to start working on the media importing portion of the importer next week. I’m figuring that may take at least two weeks. By then, WordPress 2.6 should be near release, so core inclusion can be considered once trunk goes bleeding again. After the importer is included in core, I can start getting real feedback from users. That should allow me to find and fix bugs, in addition to working on speed enhancements on a much larger scale.

The Importer In Action

I thought I would leave you this week with a look at the importer action. A few notes for the video:

1. The first item takes a while to display since the first 20 posts need to be requested, plus two requests for comments, in additional to the standard trackback and draft checks.
2. I would like to add a throbber to the in progress page to make the wait for the first post less painful.
3. You’ll notice the importer semi-stall after 20 posts. This is because it needs to request another group of 20 posts.
4. By the time the average WordPress user sees this, I would really love to see the importer work ever faster than this, and will strive the second half to make that happen.

New Issues Found

Additional testing early in the week by my mentor Lloyd brought forth some coding challenges. First off, Lloyd found a few error messages on import. Those were quickly resolved, but once Lloyd made it past the error messages, he found the performance of the importing to be subpar.

After adding some performance measurements to the importer, the source of the problem was revealed. The multiple requests of different feeds of data adds up over time. Essentially, for every post the importer needs to ping the post URL to check for a 404 (draft status), request the comments feed, and request the trackbacks XML-RPC data. Each post was taking over a second, quickly adding up over time.

Progress, Progress, Progress

Unfortunately, nothing can be done at this time to lower the request time; the feed requests are at the mercy of the internet. However, the notifications can be enhanced so a user is not wondering why the importer has not finished.

So, after discussing the issue with Lloyd, I think a progress bar is needed in this situation. Unfortunately, due to the nature of PHP applications, I can’t just add a progress bar out of nowhere. I will need to modularize the importer into a more AJAXy interface, so an AJAX progress bar can be updated with the import status. I will begin looking at solutions for this later in the upcoming week.

Even More Issues

The performance issues was not my only problem this week. Lloyd found that when importing from a blog with 3,000 entries, the importer ran out of memory. Surprisingly, it ran out of memory around 130MB, which would be crazy under a normal web server, given PHP is typically limited to 16MB of RAM.

Once this issue was pointed out to me, I quickly found the problem. I had been putting all entries in a massive array before looping through them to import. So, to correct this I limited the importer to batches of 20 posts at a time, freeing the memory between each set of posts. This appears to have corrected the problem.

In addition to the memory leak, I found out that the comments feed has the same 20 comments as time restriction that the main feed had. Already familiar with the issue for the main feed, I corrected that issue and all comments started to be imported.

Outlook Looks Good

Despite the massive amounts of issues discovered this week, I think the future of the importer is looking better than ever. Some major hurdles were overcome this week, and because of that, this week ends with a more memory efficient, error-free version of the importer.

With the new discoveries, obviously the plan has been changed a bit. Currently, I’m looking at finally (and yes, I mean finally) writing the code to automatically detect the Atom API feed at the beginning of next week. From there, I will begin working on updating the interface to be more AJAXy, providing notifications along the way.

Trackbacks Are Go

If you remember last week, I had some difficulties getting trackbacks working. Well, thankfully that is no longer the case. Earlier this week Joseph Scott helped me figure out the code needed for accessing TypePad’s XML-RPC API. With this addition, all standard blog data is now being imported.

Importing is Go

After solving the trackback dilemma, I started working on actually importing the array’s retrieved from the AtomPub server. Since much of the import code is shared between other WordPress importers, this process went fairly quickly. I only needed to make a few minor adjustments on some code, and by Thursday arrays were becoming rows in WordPress’ database.

Notifications Are Go

After testing importing several times, a logical enhancement occurred to me. Occasionally the AtomPub server can take a while to respond and feed the data into WordPress. During this time, a user would be sitting at the initial page with no notification of activity other than the browser’s loading notification. This event could have raised suspicions that the page was not loading, when in fact everything was working perfectly. So, I added a small throbber and message text while the importing occurs. The enhancement is small, but it should bring a piece of mind to those getting antsy.

Bugs Are Go

What would a coding project be without bugs. Today, my mentor Lloyd notified me of several small bugs. It turns out the importer has been generating warning messages left and right. I’ve been oblivious to this since apparently MAMP had PHP error reporting disabled. I have since enabled error reporting, and will start fixing the small bugs early next week.

Unfortunately, a major bug was also discovered. Lloyd found that only 20 entries will import. Since I’ve been working with only a few entries at a time, I had not run into this problem yet. I suspect the issue is with the AtomPub server, and an additional request will be needed for each set entries over 20. I’ll know more next week when I take a closer look at the issue.

Ronald is coding …and he has a plan.

I hope someone gets the above reference. Anyway, as you may have guessed, the early part of next week will focus solely on tackling the bugs found today. Hopefully the issues will not be problematic so I can begin the next task: allowing users to select an author to import all entries under. Once the author override code is committed, the next step on my coding agenda is to finally write the code to automatically the detect the AtomPub URL based on the website’s blog address. Those three items should keep me busy next week, and as always, I’ll let you know next week how the coding went.

The XML Parser

I started the week off by writing the custom XML parser I talked about last week. To do this, I researched several different methods for utilizing PHP’s xml_parse function. Since the parsing occured on an established standard where the tag names will not change on me, I decided to parse the tags based on a tag name switch. This worked well until I started running into nested tags. Although, that problem was quickly resolved with the use of a few class variables.

Missing Data

Once the XML was in a parsed array, I began looking over the array and envisioned how this data would import into WordPress. During this process, I realized the AtomPub feed was missing two bits of key data: the draft status of posts and a list of trackbacks. I immediately began looking into possible workarounds.

While I investigated solutions, my mentor Lloyd discussed the missing data with Six Apart. We were assured support for app:draft was on their todo list, but they did not commit to any date for availability. So, Lloyd gave me the go ahead for workarounds.

To solve the draft problem, I ended up creating a 404 checker. Assuming that drafts will not be published, the URL for the post should result in a 404. Knowing this, while posts are imported I loop through the URLs and check the HTTP status codes. The workaround certainly isn’t the best as it’s resource intensive, but for the time being it works.

After fixing the draft problem, I looked into solutions for the missing trackbacks. I found this function on TypePad’s XML-RPC developer site, however, attempts to implement the function call have failed me. So, I continued to search for alternatives.

I found out today that Movable Type has a hidden RSS feed for trackbacks. I tested this and indeed is it true. Unfortunately, TypePad does not seem to have this feed. My guess is this is because of their premium pricing model, removing support for additional and custom templates in the lower tiers. If anyone happens to know the super-secret URL for a post’s trackbacks on TypePad, I would love to know, but I truly believe that feed does not exist.

Therefore, the search for a trackback solution continues. For the time being this is being put on the back-burner. When I get some free time over the next couple of weeks or during the second half of the Summer of Code I will revisit this problem, but at the moment trackback support is being forgone.

Next Week’s Plan

So, what’s up for next week? Early next week I plan on working on the actual importing of data into WordPress. All the arrays are prepped and the functions are ready, so the importing process should go fairly quickly. I’m actually anticipating finishing up the import code by the middle of next week, but if things don’t go to plan I have until the end of the following week. Should I finish early, I will revisit some of the priority two items accumulated over the past few weeks. With a little luck, next week will bring a functioning importer with some additional fixes.

Movable Type Hates Me

Almost immediately, I was retrieving the RAW XML of TypePad’s AtomPub feed. Unfortunately, I could not say the same for Movable Type. Due to some server configuration issues on my end or possibly a bug in Movable Type, I am unable to retrieve Movable Type AtomPub feeds at the moment. I’ve tried various methods of parsing the feed and each method returns the same cryptographic error message. I’ve called in the experts (my mentor, Lloyd) to help me, but if anyone has any clue as to why Movable Type hates me, I would appreciate the feedback.

Parsing the Feed

Regardless of the error, I kept on trucking with the TypePad AtomPub feed, knowing that Movable Type will fall in line once I can figure out my retrieval problems. Working with TypePad’s feed, I started trying different methods of Atom parsing. I first tried WordPress’ built in Magpie parser, but due to Magpie not supporting Atom 1.0, that was little help. I then tried some code snippets on php.net, but unfortunately none of the snippets parsed in the manner I required. So, I started writing my own basic XML parser.

That’s where I stand today. This coming week I will continue writing my custom XML parser, completing the parser by the end of next week. The goal is to have all AtomPub data in array, so I certainly have my work cut out for me.

Since the AtomPub spec (RFC 5023) is so new, this should prove to be an interesting summer. I will be one of the first to implement a real world use of AtomPub, and I suspect documentation will be scarce. Regardless, I am up for the challenge and can’t wait to see how the end product turns out.

If you’re interested in the progress of this project, just stayed tuned to this blog. I will be blogging weekly updates on my progress, so you will always know where I stand.

Now four weeks later, I am seriously considering developing my first non-web application. The iPhone seems like the perfect platform for such a task, thanks to its powerful SDK and numerous development tools.

The Beginnings of Native Application Development

I know what you’re thinking. Why haven’t I developed a native application yet? Well, while I know C++ and Java, neither of my courses ever entered the realm of graphical user interfaces. Everything I have done thus far with native application development has been strictly confined to the command-line. Not very helpful in today’s GUI-driven world. Also, while C++ is useful on the Windows side, Mac OS X is strictly Objective-C, presenting a minor barrier to my development entrance.

That is all about to change, though. I just scheduled a required course next semester in object-oriented programming. If I am unable to learn Objective-C on my own, IST 311 should help me fill in the gaps.

Although, more importantly, the iPhone SDK offers something I have yet to fully discover in Mac OS X development: an interface builder. The iPhone interface builder looks drop-dead simple, hopefully helping me cross over into GUI development.

Picking an Application to Develop

Now that the technical hurdles have been overcome, the real challenge lies ahead. I need to come up with an application to develop. While I’m learning I will stick to simplistic applications, such as “Hello World” and others, however eventually I would love to develop an application that others will use. That should not be difficult as the iPhone, being a new platform, will have numerous voids to fill.

I will be sure to keep you updated in my crossover into native application development. In the mean time, if anyone has any ideas for applications, I would enjoy hearing them. I am trying to stay unique, as I am certain when the Apple Store is launched there will be a plethora of To Do applications and so on, but do not hold back on your suggestions. Anyway, I hope to see you on the flip-side, a native iPhone application, soon.

Phone Review: Motorola RIZR Z6tv

Back in November I purchased a new phone, and I promised I would review it. While this will be no spectacular review, here are my thoughts on my new phone.

I absolutely love the RIZR Z6tv. Although the Z6tv has nowhere near the functionality of the iPhone (I have an iPod touch for that), it functions just fine as a traditional cellular headset. The features are great, all Bluetooth profiles are enabled, the new Verizon user interface is a welcome improvement, and the reception is marvelous. In fact, I would say the reception is the best “new” feature of the phone. I’m seeing coverage in areas where I previously had little to no signal, and I’m picking up EVDO in areas where I previously had a weak 1x signal. If you’re in the market for a traditional cell phone with Verizon, I would not hesitate picking up a Motorola RIZR Z6tv.

FreeNAS Revisted

Early February, Paul Stamatiou managed to generate some buzz with his 200 Dollar PC series. I took the bait and ended up significantly upgrading my FreeNAS box. While I had originally planned the upgrade purely around saving space with the Mini-ITX form factor, a few weeks later I found myself completely overhauling the storage as well. I’m glad I did, as my FreeNAS box is now my central storage hub. I backup with Time Machine, rsync website backups, connect remotely over FTP, and store nearly every season of my favorite television shows directly to my small, slick server. Here are the specs to get your geek on:

• Apex MI-100 Mini-ITX Case
• Intel BLKD201GLYL Mini-ITX Motherboard with Integrated Celeron 215
• Kingston 512MB DDR2 RAM
• 3x500GB Western Digital Caviar Hard Drives in 1TB RAID5
• Secondary NIC for Wireless and Wired Backups
• External USB 320GB Seagate Barracuda (Time Machine)

WordPress 2.5

I’d like to now give an awesome shout-out to the WordPress commit crew and Happy Cog for a great release of WordPress 2.5. I’ve upgraded my blog earlier this week and couldn’t be happier. I thought WordPress 2.3 was amazing from a developer standpoint, but you blew that out of the water with an even better user release. Here’s to many more.

With that said, earlier in the week I completed my plugin and theme upgrades to WordPress 2.5. All plugins that I currently support should now work fine under WordPress 2.5. However, WordPress 2.3 users be weary. I dropped support for WordPress 2.3 in the majority of my releases to help speed up adoption of WordPress 2.5.

Funny Moment of the Week

I’d like to bring this post to close with perhaps the greatest moment of this South Park season so far. I don’t want to spoil the funny, so just sit back and enjoy the next two clips. If you like what you see, watch the full episode.

What is AtomPub?

AtomPub is an established standard for editing web resources (RFC 5023). Through AtomPub, content and media can be retrieved and edited with ease. Many content management systems have started implementing the standard, including WordPress as of version 2.3. Movable Type and TypePad, the targeted import environments, have added official support as of the beginning of this year.

What would an AtomPub-based Movable Type / TypePad Importer Bring to WordPress?

The number one added benefit of an AtomPub-based importer would be convenience. Currently, importing from Movable Type / TypePad requires an export file to be created. While uploading this file is easy enough, the process could be simplified.

By importing through AtomPub, only the URL location of the former blog and login credentials are needed; similar to the way the current Blogger importer works. The importer would be able to retrieve all required content information and complete the process with a single click, entirely over the internet.

My Proposed Solution

• Import all content information (posts, pages, categories, tags, etc) from an AtomPub-based Movable Type / TypePad installation in as few clicks as possible.
• Investigate providing a media import option. This option, if feasible, would import all media (pictures, etc) from a TypePad / Movable Type installation into WordPress 2.5′s new media manager, copying the content to /wp-content as needed.
• Investigate the possibility of extending AtomPub-based importers to other blogging platforms.

Additional Information

• AtomPub RFC Spec
• WordPress’ AtomPub Support
• Movable Type’s Announcement of AtomPub Support

Feel free to email me any problems you experience, and I will address them when I return from Spring Break. Enjoy WordPress 2.5, and I will talk to you later this week.

A few minutes ago I released Google Analyticator 2.0. If you’re new to my plugins, Google Analyticator is a WordPress-based Google Analytics tracking plugin. Version 2.0 adds support for Google’s latest tracking code (ga.js), and brings along all the great new tracking features with it. Check out the new version over in the code section of my site.