Lorelle VanFossen posted the first known permanent WordPress tattoo. I guess (tattoo recipient) Ed Morita didn’t read my post on CMS exit strategies. As with most CMS implementations, the feedback has been mixed. Comments on Lorelle’s blog range from “Woah! I think it’s a good tat! And it is a great location” to “Oh dear I hope that is fake cos that is the lamest tattoo ever!” However, unlike most CMS implementations, which are planned to be in place for less than 5 years, Ed’s tattoo should last a lifetime.
Archive for the ‘wordpress’ Category
Talk about lock-in! How about a WordPress tattoo?
Thursday, March 12th, 2009Joomla! vs WordPress Usability: A Simple Case of Disruption
Tuesday, March 3rd, 2009PlayingWithWire has a usability comparison between WordPress and Joomla! that has gotten a lot of attention on Slashdot and the Joomla! forums. The debate as is as you would expect: WordPress is more usable; Joomla! is more powerful. I don’t disagree with either position.
I think this highlights the fact that WordPress is at a point in its progression where it can handle many simple web content management use cases but has not yet achieved a level of complexity as to detract from its usability. It has truly become a viable lightweight CMS – not just a blogging tool. This makes WordPress and platforms like it (Movable Type, Expression Engine, etc.) disruptive technologies in the classic Christensen disruption model where a simple technology reaches a point where it can compete against a more complex incumbent that over-delivers in functionality.
The disruption model usually focuses on price; the challenger technology is cheaper than the incumbent. Not that long ago, we were talking about open source as the disruptor (we still are. Just look at all the chatter about the Linux powered Netbooks). In this case, however, both are open source and free. Here, the cost is in the effort it takes to understand and use the technology. Writing good content is hard enough without the barrier of a hard to use web content management system.
There is a clear trend of companies leaning toward simpler technologies that may not meet all of the extended requirements but are very effective in the primary use cases (in this case, publishing pages and articles). There comes a point where a simple tool reaches its limitations but many companies are prepared to make compromises or doubt whether they will ever need the fuller feature set – at least in the near term.
The incumbent CMS products are not taking this lying down. Many of the commercial products on the market offer a simplified, “task-based” user interface for the casual user as an alternative to their traditional “power user” interfaces. But even unused and unseen functionality has a cost in the complexity of implementation and the cost to support. If your website is very simple and you don’t have any power users on staff, a simplistic, lightweight CMS (like WordPress) may be sufficient.
Iron CMS
Thursday, February 19th, 2009George DeMet, over at Palantir, has thrown down the gauntlet. He will be hosting a SXSW panel where different CMS compete on implementations of the same website design and specification. There will be three teams representing Drupal, Joomla! and WordPress. Each will have 100 hours to develop the site.
I love the idea of different products going head to head in this way. This is much better than watching canned demos, which are difficult to compare because so many differences stem from the design of the demo rather than the design of the underlying software. My CMS selection methodology relies heavily on comparing prototypes. Then there is the classic Java Pet Store competition between Java and .NET.
Of course, this competition will not legitimately crown the winner as the “best CMS” – it just shows a very good solution (software and implementation team) for building that particular specification. In fact, the deck seems to be stacked in Drupal’s favor. First of all, Palantir is primarily a Drupal shop so it is unlikely that Goerge would write a specification that Drupal would struggle with. Second, the Drupal team is lead by a Palantir employee. Third, the judge Mark Boulton is working for Acquia on Drupal 7 usability (this may play against Drupal because Mark is probably very used to picking apart Drupal 6 by now). I am not saying that this competition is rigged, just that there are bound to be subconscious tendencies. Still, the panel sounds like it will be good fun for the contestants and for the audience. I wish I could be there to see it.
Getting your Google mojo back
Friday, January 2nd, 2009
When I migrated Enter Content Here off of Blogger, moving the content and comments was really easy – literally just the click of a button. This was a nice surprise because my expectations were based on a typically painful CMS migration. Because I use FeedBurner, my RSS readership experienced little disruption either. I already had moved my Blogger blog to a custom domain and WordPress allows you to format your own permalinks so it was easy to map the old URLs to the new with a simple Apache Rewrite Rule. Within my blog.contenthere.net virtual host of my hosting provider, I created the rule:
RewriteRule .* http://www.contenthere.net%{REQUEST_URI}
The one piece of the move that proved to be an issue was getting Google to update its index and move entries from blog.contenthere.net to www.contenthere.net. This was particularly problematic because I wanted to use the Google Custom Search Plugin for WordPress so I could include product pages and other content in my search results. I submitted a dynamically updated Sitemap (using the Wordpress Sitemap Plugin), Google ignored all of my entries (see image on top).
I learned from the support forum that Google probably thought that these new pages (under www.contenthere.net) were duplicates of the blog.contenthere.net pages and was skipping them. I don’t really understand why that is because there is no way that the rendered pages could be identical. I just had to take it on faith. The only way to get Google to update its index is to configure your rewrite to send down a status code of 301 (permanent redirect). The updated rewrite rule looks like this:
RewriteRule .* http://www.contenthere.net%{REQUEST_URI} [R=301]
While I was at writing rewrite rules, I added a few more to handle the situations where WordPress’s permalink algorithm was different than Blogger’s. The biggest difference is that Blogger omits “The” and “A” from a post title when building a permalink. There were also discrepancies where I changed the title of the post after publishing.
To improve my custom Google search in the short term, I added the site blog.contenthere.net to the list of indexed sites. This way people using the onboard search can still find the pages that have not yet been re-indexed and, when they do, Google should get the 301 code.
As for my old blogger blog (contenthere.blogspot.com), I did everything I could to make it as ugly and unappealing as possible. I wrote messages explaining the move all over the template. What I really wanted to do was have a link from each post to the new URL. However, there is no path variable that would allow me to construct a new link by concatenating the new domain (www.contenthere.net) to the current path. Blogger just has a tag for the full URL (data:post.url) and I couldn’t find syntax for substrings. I could have done it with Javascript but didn’t want to bother. Instead, I inserted a search form for my custom search in each post and preloaded it with the blog post title. This approach has the additional benefits of potentially giving the visitor more recent content and also sending them through Google to give it another chance to update its index. I have a free statcounter collecting traffic statistics on that site. When it gets down to 0, I will probably delete the whole blog.
Since making these changes, my search based traffic is back to its pre-migration levels. Google still doesn’t seem to take an interest in my Sitemap but that doesn’t seem to matter. Through the process, I have learned that originally hosting my blog on Blogger did not lock me into the platform. Instead, it allowed me to focus on the content and quickly establish a voice in the blogosphere without worrying about infrastructure. Blogger’s support of custom URL’s was critical to minimizing lock-in. When I migrated to a custom domain, Blogger helped route traffic from the blogspot URL to the new one. This put me in a good position to move to the blog to any platform I chose.
Re-platforming www.contenthere.net
Friday, December 26th, 2008If you have been playing close attention, you might have noticed that www.contenthere.net is now running on WordPress. Prior to the migration, the site was hosted on a combination of Blogger, Yahoo Store, and some hand coded HTML (managed in Subversion of course). That arrangement was fine but I ran into limitations with the integration between Yahoo Store and the rest of the architecture. There were no big show stoppers, just little inconveniences that I was getting tired of working around. Besides, I was itching to tinker – we techies get like that sometimes.
Selecting a new platform was fun because I got to be the client in a process in which I am normally the consultant. I was quite different from a typical Content Here client. First of all, I had no budget. Second, the president of the company (i.e. me) wanted the technology to be fun to program in. Third, I didn’t want to choose a platform that I would recommend to my typical clients because I do not want to appear biased. Incidentally, the last point is a main reason why I have held off implementation of a content management solution for so long.
My first choice was the Django web application framework. I had done some prototyping on the platform and was really impressed with the cleanness of the architecture and how quickly you could build applications. It is a little like Ruby on Rails but in Python. Furthermore, Django has a popular e-commerce application called Satchmo. I installed Satchmo and was able to understand the code and make some quick customizations on it. What really killed Django for me was the lack of a good blogging platform. There are a number of simple django blogging applications out there but nothing seemed to fit the bill. The closest was Banjo but it didn’t seem to be that well supported. There is actually a long standing discussion in the Django community about the framework’s lack of mature blogging applications.
The next two finalists were Drupal and WordPress. I have built sites on Drupal and like the framework a lot. However, the commerce module always seems to be far behind the current release of the core. I also think that Drupal is a little bit more than I need for my simple site (a blog with a shopping cart).
My decision to go with WordPress started as a simple prototype. I was amazed at how quickly I could create a theme to match my old design. The commerce module WP e-Commerce looked pretty solid and I was able to quickly get it working with PayPal as my payment gateway. I also found some useful plugins to provide me the features I was missing in Blogger (like related posts, etc.). The thing that sealed the deal for me was the ease with which WordPress imported all my blogger posts and comments. I was even able to make the permalinks match the same structure as Blogger’s for easier URL re-mapping (just a simple rewrite rule). Wordpress surely has its warts (there are plenty of places where the code gets pretty sketchy) but for a simple, reliable blogging platform with e-commerce capabilities, I am quite pleased.