Entries Tagged 'Web' ↓

This blog post has been simmering inside me for while. Some might think it as link bait but frankly I don’t blog often because I don’t have the time to manage lots of comments. So the thought of posting something that will likely be controversial has me going against my better judgment (but it won’t be the first time I’ve done that. :)

Drupal is for Serious Web App Dev but WordPress is Just Blogware?!?

Say what?!?!? Although the conventional wisdom is that WordPress is really just a great blogging tools and Drupal is more appropriate when you need a full-featured CMS for business use, the conventional wisdom is unfortunately outdated. Since WordPress released version 3.0 in mid-2010 there are now very few if any good reasons to use Drupal instead of WordPress when your business needs a CMS.

Heresy?

Maybe, but history has shown much heresey to be the voice of truth later vindicated. However, rather than ask you to just take my word for it, I’m going to explain below 17 tangible and specific reasons why WordPress is a much better choice for a business CMS than Drupal. 

Just the Facts

But for those of you who can’t be bothered to read the details I can summarize in two (2) points:

1.  Site Architecture and
2.  Backward Compatibility

Drupal’s site architecture, which on surface appears quite elegant is in reality Drupal’s biggest weakness. Drupal projects can start very inexpensively with large initial wins but the costs to add increasing functionality are discontinuous and in my experience soon soar out of control. I’ve seen several Drupal projects fail simply because of Drupal’s architectural inflexibility; many projects becoming difficult if not impossible to complete On the other hand there is WordPress’ architecture which, while seemingly less sophisticated and with more code duplication nonetheless enables the perfect combination of flexibility and unlimited functionality in my opinion where the increase in cost for more functionality scales linearly starting from zero.

As for Drupal’s position on backward compatibility they only maintain compatibility between major versions, which means you’ll be probably be forced into having to do a fork-lift upgrade since they only official support one major version behind. Who in their right mind would put their business in such a position? WordPress, on the other hand, bends over backwards to maintain an upgrade path between 0.1 versions.

About Terminology

WordPress and Drupal have some different terms for similar concepts and the following might be confusing if you are not aware of how these terms relate.  What WordPress calls a "Custom Post Type" Drupal calls a "Custom Content Type."

In WordPress a developer uses the register_post_type() function to define a custom post type whereas in Drupal a developer or user defines a custom content type in the admin console using the "Content Creation Kit" module (a.k.a. "CCK".) WordPress calls all content items "posts" (which is the generic term for the more specific "Pages" and "Posts"; confusing, I know, but that’s for legacy reasons. Drupal on the other hand alternates between calling content items "Content" at times and "Nodes" at other times.

Both WordPress and Drupal use the term "Theme" to refer to the collection of files that collectively create the unique look and feel for a site. Themes are comprised of some or all of these items: PHP scripts, HTML, CSS, SQL queries, Javascript, Images, Flash and maybe more. Themes are designed to be interchangable so that by replacing a theme a site can be given an (almost?) completely different look.

For extensiblity both WordPress and Drupal support the concept of componentized functionality with WordPress calling their functionality "plugins" and Drupal calling their functionality "modules." Aside from some technical implementation differences both plugins and modules are conceptually the same; componentized functionality. They are both typically comprised of PHP scripts and HTML but like themes may also incorporate CSS,  SQL queries, Javascript, Images, Flash and more.

As for versioning, WordPress strives every four (4) months (but it sometimes takes six) to launch a "point 1" or 0.1 version increment (such as v2.9, v3.0, v3.1, etc.) whereas Drupal uses major and minor versions (i.e. v5.x, v6.x, v7.x, etc.) with no specific release schedule between major versions.

Now with that out of the way, on to the 17 reasons.

17 Reasons to Pick WordPress vs. Drupal:

1. WordPress Allows Infinite Design Flexibility - Drupal not so much. Because of it’s fundamental technical architecture most Drupal sites have a certain look and feel that is very difficult to get away from (note the "I think though doth protest too much" quality of these three (3) posts),   WordPress is as flexible as HTML because of it’s architecture.

   More specifically when a browser requests a web page from a Drupal-based website, Drupal inspects the requested URL and then delegates reponsibility for generating parts of the HTML page to both applicable modules and to components of Drupal itself. Drupal then collects up the generated HTML and composes a completed  HTML page when it sends to the browser.  Drupal manages everything and this archecture is minimizes duplication of responsibilities and is an architecture that an engineer can truly love.

   Unfortunately Drupal’s architecture is also highly coupled and thus rather inflexible; when you want a web page that doesn’t fit into Drupal’s model you either 1.) learn complex and arcane methods to achieve what in pure HTML would be incredibly simple, 2.) rebuild major portions of Drupal functionality for your custom page or 3.) just give up and do it the way Drupal wants you to. Or as I like to say when explaining this unfortunate aspect of Drupal:

   As a Drupal developer you are constantly battling Drupal to get back in control of the HTML that it will output for any given URL. Drupal is like a "Roach Motel" for URLs: Once a URL enters Drupal it never leaves!

2. Usability has been "Baked-in" to WordPress - With Drupal, usability was an afterthought until version 7 and they’ve been desperately trying to improve it; usability tests by the Univeristy of Baltimore identified many critical usability issues in Drupal (the video is a must watch.) But some things such as usability need to be central to the philosophy of the developers and not tacked on as an afterthought. In Drupal you frequently need to visit at least two different pages in the admin to affect what a user would see to be one external change. With WordPress the admin console was originally user tested by the project founder’s mother ("If mom can use it, anybody can!") and that fanatical concern for usability has permetated the project. In Drupal some of the more active developers are known to say "If you don’t find Drupal usable maybe Drupal is not for you."
3. WordPress has a WYSIWYG Content Editor in Core - Also a usability issue but an important specific one, with Drupal there is no standard WYSIWYG editor leaving the site implementor to choose from thirteen (13!) suboptimal editor module choices, none of which are maintained at the same level of Drupal core.  In WordPress, TinyMCE has been a highly usable standard for more versions that I’ve been using WordPress. (Personally this was one of the biggest issues I had with Drupal and why moving to WordPress was such a godsend for me.)
4. WordPress Strives to Maintain Backward Compatibility - Drupal wears as a badge of honor that they wipe the slate clean with every major version. Drupal mostly ignores backward compatibility with the prior major version because yes it is nicer for the core developers not to have to worry about backward compatibility. But for your business the reality is that if you implement a site using Drupal you are stuck on that major version until you choose to invest in an expensive rewrite of your website. 

   Ponder this issue for a moment.  In my opinion, choosing Drupal can result in a nightmare once the version of Drupal they are using becomes too obsolete and is no longer supported. This is such a huge negative that I can’t really see why any business that is doing their due diligence would ever choose Drupal no matter its feature set.

   With WordPress most upgrades are seemless and those that are not are usually easily fixed because of the attention to maintaining backward compatibility.

5. A WordPress-based Website’s Source Code is Easier to Manage - Drupal co-mingles user content with what is in effect a website’s source code in much more significant ways than WordPress does.  For example, to design of "Custom Content Type" in Drupal gets stored in the MySQL database; in WordPress "Custom Post Types" are stored as PHP code. For any business website managed by professionals it is critical to use a source code version control system and it’s easy to submit PHP code to version control but very difficult to submit records in a database to version control. This fact alone is a extremely strong argument for WordPress and against using Drupal for any serious website development project.

   Yes out-of-the-box Drupal is easier for a non-technical power user to add custom content types compared to with WordPress, but we are not talking about the needs of a housewife to organize her recipes, we are talking about which one is the better choice for a business CMS and WordPress wins hands down in this category. (BTW, there are plugins for WordPress such as Custom Post Type UI that provide the end-user with the same ease of use for creating custom post types that Drupal has for creating custom content types.)
   

6. Collaborative Development is Easier with WordPress - This reason is a variant of source code being easier to manage. Without a good version control strategy it is much harder to get a local copy of a website for development. Developers in a Drupal shop have to spend a lot more time merging their databases so the up-shot is that many Drupal developers co-develop on the same installation, and often the live installation at that which results in overwriting each other’s code and limits a developers ability to roll back.  It’s much easier to develop with a local copy of WordPress so WordPress developers tend to do it more often.
7. Revisions of WordPress-based Websites are Easier to Deploy - This reason is also a variant of source code being easier to manage. 1 but the headaches are seperate so I list is as a seperate reason. Because WordPress maintains a lot more of its logic in PHP code WordPress is much easier to deploy than a Drupal application. Drupal developers end up writing a lot more SQL code that they then need to test everytime they need to merge data used to control new application logic into the database of a production webserver on deployment of a revision to an existing website. The significance of this is hard to underestimate.
8. Easier to Find Skilled Designers for WordPress -  To create a beautiful website design for WordPress designers need to be good at design, of course, but beyond that they really only need to learn how to copy and paste "Template Tags" as they able to have full design freedom when producing the HTML that will be used for a WordPress theme.

   Drupal designers, on the other hand, need to be skilled PHP developers too and with a rare exceptions those two skillsets are mutually exclusive. When you do find someone who can do both and do both well, they will be hugely in demand and thus outrageously expensive but the real problem is with Drupal you really won’t know if they are one of the rare few until after you’ve paid them a lot of money to either create a "house of cards", or a really ugly house.

   With WordPress you can get a great designer to work with a great developer, both of which are easier to evaluate than combined greatness, and you are set.
   

9. There are More WordPress Professionals Available - A corollary to finding skilled designers, it’s simply much easier to find WordPress professionals to hire for projects than it is to find Drupal professionals.
10. WordPress Professionals Charge Lower Rates - Another corollary to finding skilled designers and more WordPress professional being available is it is less expensive to find a WordPress professional than a professional for Drupal.  If you ignore the fact that there are many more WordPress professionals another factor is WordPress professionals don’t need to be as proficient in as many areas as their Drupal counterparts.  People who can really make Drupal sing are really expensive.
11. WordPress’ Code is Much Easier to Debug - Drupal’s highly nested architecture makes it so that a developer spends most of his time looping through a few core functions waiting to find which code controls what they need to modify.  Often with WordPress the developer can simply set a breakpoint on the theme’s template file and debug from there.
12. WordPress Sites Load Much Faster than Drupal Sites - Drupal runs upwards of 100 SQL queries for every page load because of its site architecture. With WordPress the number can easily be less than 10. And the time to run those SQL queries easily add up. Drupal advocates will claim those queries can be made insignificant by the creative use of caching but the reality is that you cannot cache most items in the admin console so the end user who is forced to use Drupal will be saddled with a level of fatiged and is just not necessary, if you instead choose WordPress.

    And lest you feel this is unimportant technical concern be aware that site performance is now something that Google uses to determine search engine result rankings. Host your website on a slow platform and prepare for an uphill battle when it comes to achieve top rankings in Google’s search engine results pages.

13. WordPress Requires Less Expensive Hosting - A corollary to page load performance is that the typical Drupal site requires a lot more server to serve each of it’s pages than does a typical WordPress site. Those who choose WordPress for a seriously high traffic site will usually find they can serve more pages with the same servers and/or that the memory requirements for WordPress will typically be a lot less. And for a high traffic sites this could either be real money and/or it can mean that the site is less likely to fail in the case of a flash mob such as a Slashdotting.
14. WordPress has the Most Integrations -  More companies or their 3rd parties offer plugins for WordPress to integrate with their services than another other platform, specially more than modules available for Drupal. Twitter, Facebook, Freshbooks, MailChimp; you name it, they all have WordPress plugins. If you need one for Drupal and it’s not a mainstream service like Twitter or Facebook chances are you’ll have to pay to have it written.
15. WordPress has More Robust Extensibility Method - Both WordPress and Drupal use the term "hooks" to describe their exensibility mechanisms and while there are similar there is an important technical difference. In WordPress you associate a bit of functionality to either run or filter a value based on the name of the hook and you can have as many hooks of each type as are needed. In Drupal you do the same except that hooks are identified hook name prefixed with module name which means you can only use a given hook once in a module; if you need to use it twice you have to create another named module.

    Of course the module name limitation is an annoyance but not a huge problem. The huge problem comes when you need a module to disable a hook that was enabled by another module you otherwise need. This is a technique used somewhat frequently in WordPress but when it’s needed it is essential. In Drupal, even if you need to you simply can’t. And all because of Drupal’s architecture choices.

16. WordPress has Far More High-Quality Attractive Themes - Drupal has almost two orders of magnitude less.  Why is this the case? Because it is so much harder to create a Drupal theme (as mentioned above), designers have to be good developers to theme Drupal (also mentioned above) and there are just so many more people using WordPress.

    Now having off-the-shelf themes is great for micro-businesses, startups and even tactical projects but most businesses will want a custom theme developed to showcase their brand in the best light possible yet the existence of so many commercial themes still benefits those who need custom themes.  Why?  Because it means that collectively WordPress custom theme developers have a lot more experience developing quality themes than their collective Drupal counterparts because many WordPress designer offer up commercial themes for sale in addition to their bespoken work.

    And then there are the theme frameworks for WordPress like StudioPress’ Genesis and WooTheme’s Canvas which create excellent headstarts for theme designers with lots of pre-built functionality that designers would often have to charge clients to develop.  Drupal does have the concept of theme frameworks but they are really an esoteric option for Drupal.

17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal - Yes an attempt has been made but there’s just not enough community support for a Drupal Answers (yet?) And while this reason may seem gratuitous, believe me it is not!

    The official support forums for both Drupal and WordPress and even the mailing lists for WordPress evidently encourage a level of disrespectfullness that is pervasive in so many open-source communities and it can be a huge time sink for the business person who just wants a problem solved. On the other hand the mechanism used by StackExchange’s WordPress Answers brilliantly encourages timely and helpful support discourages such unproductive behavior with its reputation system.

    And whereas many support queries on the Drupal (and WordPress) forums go unanswered, the majority of questions receive a reasonable answer on WordPress Answers (currently at 94%.)  If you have a WordPress issue you need solved, or that your developer needs to solve, the existence of WordPress Answer compared with the non-existence of Drupal Answer means that solutions will come far more quickly and far less expensively.

So there you go.  17 Substaintial Reasons why WordPress "The open source blogging tool" is a far better pick when selecting a CMS for business use compared with "*The* (2009) open-source CMS" Drupal. (Oh, and the judges picked WordPress as the best CMS for 2010.) Need another opinion? See Wikipedia’s criticisms of Drupal and the relative lack of criticisms about WordPress.

Of course it would be unfair and disingenous of me to call out WordPress strengths and Drupals weaknesses without also telling you where I see weaknesses with WordPress and strengths of Drupal and for me not to tell you what are the use-cases where I’d be hard-pressed to dismiss Drupal in favor of WordPress. So here you go:

1. Drupal Allows for More Flexible URL Design - Since WordPress grew up as a blog they hardcoded the URL routing logic which has resulted in some rather odious limitations in how you can design your URLS.  Drupal’s URL management is no panacea either — you can end up with a difficult to maintain mess — but at least Drupal *allows* you flexibility that is often just too hard to implement robustly with WordPress

   (Note: I have a plugin on the drawing board whose goal is to remove this limitation from WordPress. Once it sees the light of day  I believe WordPress’ URL routing will be much better than that of Drupal. But alas, at least today, Drupal wins in the URL category. If someone using WordPress really badly needs better URL routing in WordPress and can fund the plugin development please contact me as by nature my priorities are defined by my client’s needs.)
   

2. Drupal Offers Out-of-the-Box Content Type and View Creation in the Admin - Yes, out of the box a saavy end user with adminstrator rights can create and define Custom Content Types with custom fields and even custom reports/queries called "Views." This enable and end user with the time to learn Drupal to build a content-based system without any developer help. And for certain scenarios this would be invaluable, such as in certain government or academic departments were there is zero budget for development today, there never will be budget, and the end user either does not want to or is simply incapable of learning how to write the simply PHP required to register custom post types in WordPress.

   On the other hand, there are WordPress plugins that duplicate the functionality of CCK and there are numerous plugins that expore the Custom Post Type registration via a UI in the WordPress Admin.  Still, as far as I know, there really is not WordPress equivalent of Views.

   Still, even though you can create custom post types in WordPress using a plugin that exposes an admin UI it doesn’t mean you always should. As I said above I highly recommend that anyone business that is having custom solutions built using WordPress not build them using an admin UI for defining custom post types but instead embed that logic into version-controllable PHP files.

   As for Views, it’s basically the same recomendations as for custom post types; rather than store them in the database like Drupal does it works much nicer just to code calls to WP_Query into PHP code; easier to version control and also easier to test, verify correct and certain that aspect of the site to be bug free.

3. Drupal has Positioned Themselves Better in the Eyes of Large Enterprise - Here’s where I think Drupal has succeeded brilliantly. Because of the efforts Acquia’s products, services and solutions there are many large companies that believe in Drupal. I believe they have done a much better job of courting the Fortune 500 crowd than WordPress has via Automattic and it’s VIP Support and Hosting offering.

   That’s not to say there are not some really phenominal companies delivering enterprise class solutions on the WordPress platform such as Voce Communications and TayloeGray just that there is a segment of decision makers in large business who will only consider working directly with the primary vendor and in these two cases the primary vendor for WordPress is Automattic and the primary vendor for Drupal is Acquia. And while I love WordPress and think highly of the team at Automattic it’s clear to me that Acquia have done a much better job of positioning themselves as a company that provides enterprise class support for their platform.

But what about Drupal for Community Sites?

One of the use-cases oft cited for Drupal’s superiority is for community sites.  But frankly, I don’t buy it. 

As an active member of the Drupal community for two years (speaking of which, I need to update my profile there) I found drupal.org to be an extremely frustrating website in which of participate in a community. The forums were not at all effective in the ways that other forums I’ve seen like vBulletin have been effective, and using them as a user was far more pain then pleasure (by contrast I find StackExchange mechansim at WordPress Answers to work brilliantly but alas it’s not software you can implment for your own community.)

Actually at this point I think it’s counter productive to set up yet another social network but if you are convinced your strategy makes sense I’d be included to launch it on BuddyPress instead of Drupal, and BuddyPress is now a plugin for WordPress. And one of the really great aspects of BuddyPress is it that it leverages the brilliant network/multisite feature of WordPress which has completely nailed the "single install - multiple website" architecture.

Who am I to Judge WordPress vs. Drupal?

Full disclosure, I’ve been making my living as a WordPress specialist for almost two years and I plan to launch a company that provides tools and support for professional website developers and interactive agencies who have chosen WordPress as their platform for client solutions. The reality is that I could easily choosen to do the same for Drupal but did not. 

I spent two years working with Drupal as my preferred platform, from mid 2007 through early 2009 and I gained experience working with versions 4, 5, and 6. I was drawn to Drupal by it’s elegant architecture (I’m an engineer by degree and thus appreciate elegant technical architectures) and frankly by the fact that Drupal was the only solution of the three main open source CMSes that  could actually be used as a CMS without obvious issues (why I avoided Joomla is the story for another day.)

Back in 2007 using WordPress as a CMS was simply not an option, so I moved forward and became enamoured with Drupal and it’s Custom Content Kit, Views and so many other (what seemed like) wonderful modules. I became active in the local Drupal Meetup group and spoke at several of their meetings. I registered a "DrupalCamp.com" domain with plans to launch a local DrupalCamp and more. I really drank the Drupal koolaid.

But then by happenstance I had finished a Drupal project and was looking for another when a 6 week project to write custom admin plugins for WordPress 2.7 fell in my lap.  Since I far prefer to develop admin functionality than full websites I figured "How hard can it be?" and took the job.  While I worked on these plugins I discovered WordPress much easier to develop for than Drupal but I still held on to the notion I’d return to doing Drupal work once the project was done. As the project progressed an inner conflict raged as I came to prefer WordPress all the while mourning what I would be loosing if I were to leave Drupal (CCK and Views, mostly.)

However by the end of the 6 weeks it became crystal clear to me; WordPress was a much better system than Drupal even without all the CMS features. I was reminded of how many personal Drupal projects I had unfinished simple because it’s do hard to get a good looking site completed in Drupal, the last 15% it pure hell to complete. So I decided I would build my own CCK equivalent and use WordPress instead. Honestly, it didn’t go so well with WordPress at first. Trying to create my own CCK was fraught with frustration and I wasted copious time trying to bend WordPress to my will. But I did and limped along.

Then v2.8 came out. And then v2.9. And then finally v3.0 was announce with Custom Post Types and fortunately I was in a position to just on the beta version. It soon became clear to me that the WordPress team got Custom Post Types right and that v3.0 was going to be a watershed release and, as they say, the rest is history. 

As I write this v3.1 is going into beta and with its Internal Linking Dialogs, Post Formats and more WordPress continues to prove that it really is the best choice for almost every business CMS need out there.

So Why Did I Write this Post?

Recently I met with a Senior Vice President of Strategy and Innovation at a large well-known non-profit who is planning to launch a major initiative and he’d narrowed his choices of platform down to two (2): Drupal or WordPress.  On a personal level we hit if off fabulously so if it were just personalities I think he might be inclined to take my recommendation on faith but I sensed he is enough of a real professional that he looks beyond the personality of the advocates to assess the actual best solution for this organization.

What he wanted to hear from me which platform I thought was the best and why. I had already reviewed their design brief and wireframes so I had a good idea of what they wanted, and on the surface it looked rather much like a community app. Because of this and also because he had previously talked with several Drupal advocates I think he was leaning towards Drupal.  But looking at his requirements and given my issues with Drupal that I detailed in these 17 reasons it was clear at the day is long that WordPress would be a far better platform to meet his needs.

Still, as I tried to explain to him why Drupal would not be a good choice I felt that I might have been coming across as a bit too much of a WordPress zealot whose opinion was not based on objective reasoning. So I decided that I should  writing this up to make the case using objective criteria for anyone evaluating the two.

But I still didn’t get around to writing it up because there are always too many other things to do in a day. It wasn’t until a series of posts on Quora with the leading title "Why do so many people use Drupal instead of WordPress?" that I got off my duff and finally wrote this post (even though I have clients whose projects I probably should be working on!)

In Summary

While Drupal had the lead as best open source CMS for many years, WordPress has eclisped Drupal as the best open source CMS as of mid 2010 with the addition of Custom Post Types.

More specifically Drupal’s site architecture makes it a less than ideal platform for business websites when compared with Wordpress, and Drupal’s philosophy on backward compatibility make it really hard to recommend it to any company for almost any reason at all.

Postscript: About Comments and Revisions

If you are going to post comments:

1. Be sure to include something specific about the post in your comment rather than a generic like "Yes I agree" or I might think is spam and delete, and
2. If this post gets a lot of comments (which I fear it might) be aware that if your comment doesn’t appear for a few days it’s simply because my client demands have limited my free time and I haven’t had time to release it from moderation.

FYI, I plan to revise this post if new evidence comes to light, somehow I got my facts wrong, or I just identify more to add. Frankly I’ve never much liked the "write-once, forever outdated" form that most blog posts take, so why conform?

UPDATE (2010-12-13)

Alastair McDermott has just written a blog post on a very similar subject entitled "Why I Recommend WordPress as a CMS." It’s a good read.

UPDATE (2010-12-17) 

If you are going to leave an inflammatory comment criticizing my post then at least have the integrity to leave your full name, your email and a link to something where I can verify who you are and I’ll be happy to publish it (you know who you are.) Otherwise I’ll simply moderate your comment into the trash.

And for what it is worth, it looks like even the Drupal community knows about many of the problems with Drupal:

•  What is wrong with Drupal? 

, Acquia, Automattic, CCK, CMS, CSS, Custom Post Type UI, Custom Post Types, drupal, Facebook, Freshbooks, Genesis, google, Hooks, html, javascript, mailchimp, Modules, MySQL, plugins, Pods, Quora, Roach Motel, StackExchange, StudioPress, TayloeGray, Template Tags, tinymce, twitter, Univeristy of Baltimore, URL Design, Usability Study, Version Control, Voce Communications, WordPress Answers, WordPress VIP, WYSIWYG

A friend recently sent me a URL via a Forward-to-Friend.com which is a service of MailChimp. While I really love the guys at MailChimp their URLs for their Forward-to-Friend.com are simply awful. There days of social media well designed URLs are finally being recognized by many as being extremely important, but not everyone gets it yet nor does everyone know best practices for designing URLs.

Make ‘em Short and Sweet

One of the traits of a well designed URL is that they can be grokked with a quick visual scan. They should also be no longer than really necessary because one of the more common link sharing sites (Twitter) shortens long URLs automatically. There are many other traits of a well designed URL, some of which are specific to context but if it’s too long and you can’t understand something about the URL by looking at it something is really wrong. And anything that impedes sharing of links is a foolish addition. So I bitched about this URL on Twitter that a friend of mine sent me in email (let’s call her "Jane Smith" and @BenChestnut asked me to clarify. Here’s the URL:

http://us1.forward-to-friend.com/forward/show?u=0fea6c2e08126550f4c318d4b&id=cd941d1fa5

What’s wrong with this URL?

So what’s really wrong with this URL? Let me count the ways:

1.) "us1."

This subdomain seems to imply that its specific to the US which I’m lukewarm on having a subdomain in this context it adds unnecessary characters. And what’s with the "1?" Is there a ".us2?" Is this just a server convenience? C’mon guys, hide that crap the user; they don’t want to know.

2.) "forward-to-friend.com"

Okay, so it’s a cool domain, but you really couldn’t you come us with something shorter than 21 characters?!?

3.) "forward/show"

Uh, one word: "Why?!?"

4.) "?u=0fea6c2e08126550f4c318d4b"

Do I really need to say anything about this? I mean, it’s waaaay too long and how does any of this mean anything to anybody? The only thing is does it make the programmer’s life a tad easier to uniquely identify the user but only on the day it was implemented.

5.) "&id=cd941d1fa5"

Another too long and non-meaningful computer number. The "id=" identifies the URL being forwarded. But does it mean anything?

What would be better?

So here’s a better hypothetical URL with analysis to follow:

http://fwd2.net/janesmith/laura-coyle-at-fernbank

"fwd2.net"

The "fwd2.net" domain is owned by a squatter. Why not pay them a few bucks and pick it up? (or get something similar and short?)

"/janesmith"

Not super short but much like Twitter’s screen name it identifies the links shared by the user who picked the name "janesmith" (i.e it replaces "?u=0fea6c2e08126550f4c318d4b.")

"/laura-coyle-at-fernbank"

Again not short, but as this would be selected by the user before sharing it would be as short as the user wanted it to be. So the user could have picked just "coyle-fernbank" or "fernbank-oct2" or similar. But what is really important is that it is meaningful!

And another benefit?

With this format you also get this URL:

http://fwd2.net/janesmith

At that URL you could have all the links "janesmith" shared when she is logged in, and she could set those shared links to be private or public, or later once more functionality is added the links could be made selectively available to different groups of friends.

Further there could be groups of URLs shared such as anything with a trailing slash could be tagged links, i.e. in this case "jazz":

http://fwd2.net/janesmith/jazz/

Hopefully you can see a tremendous amount can be done with URL design but sadly there are still too few people who pay attention to it. Maybe that’s because there’s no book of best practices. Hmm, might be an opportunity there…

Still think it is unimportant?

And for you skeptics out there who really think that "users don’t look at URLs" take a look at the apps that are succeeding lately, Twitter being a main one. Most of them are designing their URLs well. Coincidence? I don’t think so.

Thanks for asking

Anyway Ben, thanks for asking. Hoping you see the value in it, make the suggested changes, and find that it’s made a positive difference.

Last month on the 21st we had a blowout meeting about Twitter for the Atlanta Web Entrepreneurs meetup group I organize; over 100 people attended!

We started out with an Intro to Twitter which I prepared and delivered. It reminded me of delivering training long ago during my DSW Group, Financial Dynamics, and Expert Education days.

Normally we find others to give all the presentations but given how confused some people where at our Facebook meeting when we started with the assumption they knew about it, I decided it was best for me the Twitter newbie to give the other newbies the introduction and then let the "rock stars" in our lineup really get into the meat of things.

We then launched into a video conference with both Wayne Sutton (@waynesutton on Twitter) and the Triangle Tweetup (@triangletweetup on Twitter) as well as Robert Scoble a.k.a. "Scobelizer" (@Scobelizer on Twitter).  Loren Norman (@lorennorman on Twitter) of Snowcap Labs did the honors of organizing the video conference and for that we were very grateful. Knowing what a web celeb that Robert is and the subsequent constant demand on his time, we scheduled Robert to speak for only 5-10 minute but instead he spent over 30 minutes answering audience questions. Kudos!

After the video conference we have the took a break and then moved into a Q&A session with Sanjay Parekh (@sanjay on Twitter), Tessa Horehled (@tessa on Twitter), and Paul Stamatiou (@stammy on Twitter) each gave us their perspectives on why Twitter is so invaluable.

As many people said after the event this was one of their very favorite AWE events yet, and I certainly agree; it was right up there. Thanks to all involved including Wayne and the Triangle Tweetup, Robert, Loren, Sanjay, Tessa, and Paul for making this such a great event.

 It really is great to have such nice people who are willing to help their peers all here in our hometown of Atlanta GA.

Go Atlanta!

Visit Flickr to see all photos I took for this event.

P.S. Oh, and I almost forgot!  Atlanta Web Entrepreneurs is @atlantaweb on Twitter, and I’m @MikeSchinkel on Twitter.  See ya in the Twittersphere!

@sanjay, driveafastercar, intro, paul stamatiou, people, robert scoble, sanjay parekh, scobleizer, stammy, tessa horehled, triangle tweetup, twitter, wayne sutton

Just an announcement that we are going to be discussing Why you MUST have a Twitter Strategy at Atlanta Web Entrepreneurs on August 21, 2008.

I’m going to present a short intro/overview to Twitter and then, god willing and the creek don’t rise, we plan to have two (2) video conferences, one from Triangle Tweetup and the other from a soon-to-be-announced Industry luminary with over 25,000 Twitter followers!

After the 8pm break we’ll have a roundtable-less discussion and Q&A led by our featured participants:

• Sanjay Parekh (sanjay on Twitter),
• Tessa Horehled (driveafastercar on Twitter) and
• Paul Stamatiou (stammy on Twitter).

Anyone that wants to attend should first be sure to have a Twitter account and to follow atlantaweb. We’ll use that list as a roll call for the meeting and we’ll announce our special guest on the atlantaweb Twitter account by 6pm Wednsday August 20th.

For more details and to RSVP see go here.

driveafastercar, paulstamatiou, people, sanjayparekh, stammy, strategy, tessahorehled, twitter

It’s been almost fifteen years now since the web first hit it’s tipping point and transitioned from an academic’s playground and a mere curiosity for the average person to the decidedly mainstream global change agent that now drives trillions of dollars in global value creation annually. During that time we’ve gone from asking "What’s this ‘World Wide Web’ thingy the geeks keep talking about?" to rapidly seeing Web-based services dominant the activities of practically every business person alive. In the days of the first Internet "gold rush" a.k.a. the "dotcom bubble" it seems that everyone and their brother grabbed a .COM domain, or ten, and set out to strike it rich.  Back then you really didn’t even consider getting anything besides a .COM for your website business but that was okay because many good brand names could be created from still available .COM domains.

Fast forward a decade and great .COM domain names have became scare and even good .COM domain names are hard to come by especially with all the domain squatters.  In addition a lot more top-level domains have opened up, and many small countries such as Tuvalu (.tv) have decided to cash in on their (un)natural resources. And just as fashions change, some creative types who needed a good domain name chose to forgo the .COM status quo and the "www." sub-domain convention and instead compose domain names from words by ignoring the domain level separators (i.e the periods ".") From this trend popular websites with domain names like http://del.icio.us (aka "delicious") were born.

If you are not familiar with delicious it is essentially a website to store your web bookmarks, but storing them "in the cloud" as opposed to in your browser. And one of it’s best innovations, since mimicked by thousands of other sites, it the ability to allow users to categorize with freeform "tags" and later recall their bookmarks by the tags they assigned. These tags are just words, any words your chose, such as "marketing", "video", "php", "bestpractices" or even "shoes."  What words you use to tag with is totally up to you. 

I’ve been using delicious for several years now and at this point not a day goes while surfing the web that I don’t tag at least one website for future reference.  You can even use it to create lists of sites groups by a tag and then send those links to others so they too can see your list of links. But I digress; there is a lot more to delicious but the subject of this post is the .COM domain so we’ll my detailed description of del.icio.us for another day.

As delicious got more popular with the many influencers on the web, Yahoo stepped in and bought them.  Since then delicious has languished for years, still there but never updated. Probably the best thing that has happened to delicious during that period was Firefox built delicious tagging into their browser as their favorites list — if you choose to let Firefox use delicious for you — and the fact that since it hasn’t changed it’s been a pretty stable target for people who wanted to use to delicious API to create add-on functionality and integrations.

So, after years of languishing it turns out Yahoo has been paying attention to delicious behind the scenes, and behold; there is a new delicious! [1]  What’s more, Yahoo has redirected all attempts to access delicious at http://del.icio.us to instead find delicious at http://delicious.com/ and thus, in one fell swoop, have extinguished the quirky domain name that was in part why the web’s tastemakers first took note of delicious. The powers that be at Yahoo probably choose to do this because of usability data I expect they’ve collected that probably told them that the "in crowd" got the funny spelling but that the vast majority of users were simply confused.

Which brings me to the crux of my post where I posit the following:

Are .COM domains still required for commercial success in a mainstream website? Or or those rushing to get domain names with all the new top level domains simply exercising futility?  Were all these idiosyncratic domain names merely a fad and now we’re back to business with .COM, or did Yahoo jumped the shark on this one?[2] 

So what do you think? 

.com, .tv, .us, branding, delicious, domain names, dotcom, tagging, urls, yahoo

Wall of Spam courtesy of freezelight and enabled by Creative Commons

Damon Clinkscales blogged about Twitter Spam last month where he advocated proactively cleansing one follower’s list of "follow spammers" to help reduce the load on Twitter, improve Twitter’s reliability, and increase the value of the Twitter community in general.

I agree!

Still, I think Twitter could take a proactive step reasonably easy that would make it so we don’t have to. I think Twitter could reduce most of the type of Twitter follower spam I got today by applying two simple criteria (And I think Damon also got that same spam today. BTW, nice blog theme Damon! ;-)

I think a strong indication of Twitter follower spam is simply:

1. Their following/follower ratio (or their ing/er ratio for short), and
2. Their follow rate (i.e. how quickly they follow someone after that last time they followed someone.) 

This spammer I got today followed me with 4 different Twitter accounts within a few minutes and each account had around 2000 followings and just over 10 followers making their ing/er ratio about 20-to-1 and I’ll bet their followers were all auto-followed. It’s also clear from the fast & furious tweets that I was not their only mark.

I think it would be reasonable for Twitter to auto-block anyone with a ratio of greater than 15-to-1 ing/er ratio. Twitter could even remove the auto-followers from the calculation; those that follow within around 90 seconds of being followed wouldn’t count as a follower. Doing this Twitter would still give someone the ability to follow 15 people for every one that follows them, and heck they could give them their first 150 people[1] for "free" (i.e. not counting against the limit.) If someone really wants to follow 15,000 people they need to be interesting enough to have at least 1000 people follow them. Shouldn’t be that hard…

Also, Twitter could limit followings per day to, say, 75.  That should be enough for anyone, even the most hard-core twitter newbie (150 "free" + 75 more), and it’s not unreasonable to require a newbie to wait a few days to follow lots and lots of people. 

If I were in charge of setting these limits, I’d set the ing/er ratio to 5-to-1, give them only 25 "free" and then limit to 25 followings per 24 hour period, but I shot high because I was trying to be "reasonable." Of course, Twitter could allow for special cases by allowing people to request to have those limits manually raised if they provide a good justification for it.

What do you think?  Would this work to reduce most Twitter follow spam?  I think so.

antispam, follower, ratio, solutions, spam, twitter

UPDATE (2011-04-15):

Since I wrote this post I’ve learned a tremendous amount about WordPress plugin development; so much so that I can’t overstate how much more I know today than when I wrote this post years ago.  So, while the following post might be a novelty to read, I highly recommend that you don’t use this approach.

The only way that a RESTful approach to web services in WordPress would make sense to me is if a team of rockstar WordPress plugin developers were to create a fully fleshed-out extension to WordPress that offered a complete RESTful web service implementation including one that addressed all edge cases and security concerns; only then I would consider not defaulting to the non-RESTful approach WordPress uses for AJAX.  

In summary I recommend not trying to swim upstream today and instead use the approach provided by WordPress. Who knows, maybe in the future there will be a viable method of doing RESTful web services in WordPress.

So I’ve got a project where I need to have a Flash component built in Flex to call to a WordPress blog and get information about it’s latest post. Should be no problem right?  The easy way to do this would be to just write a "rest.php" file and brute-force all the setup that WordPress does but I thought it would be so much more valuable to implement this as a plug-in.

I figured that I’d just quickly learn how to build a WordPress plug-in and create one for exposing RESTful web services; after all with a year of programming Drupal modules WordPress’ plug-in API can’t be that hard, right?  Well turns out it wasn’t that easy and I think I have run into a design limitation with WordPress and I’m beginning to wish I’d just taken the brute-force approach and said to hell with writing a plug-in.

Although I am not 100% certain, and I hope someone can point out that I’m just doing something wrong, it seems sadly like I’m pushing the edges of the WordPress API and exposing where it’s design falls short. By the way, I’m working with WordPress v2.5 because why upgrade mid-project when god knows if WordPress will release another in the remaining days before this project is done and I’ll just have to do again before deployment?

Here’s the details.  I started writing a plug-in called "RESTful Services" with a goal of implementing URLs that behave in the following fashion; {format} could potentially be html, xhtml, json, xml, rss, atom, etc.:

http://example.com/services.{format}

Provide a list of RESTful services in specified {format}, defaults to html

http://example.com/services/{service}.{format}/{data}?{params} 

Provide a RESTful service in specified {format}, defaults to html, with optional provided data and parameters.

But before I got all those options working I just wanted to service a page from my RESTful Services plugin where Content-Type: text/plain. I found this page that professes to explain how to hook into the URL routing and after a few fits and starts I can came up with the following code for my plugin that would indeed response to my http://example.com/services URL:

wp-content/plugins/restful-services/restful-web-services.php:

1
2
3
4
5
6
7
8
9
10
11
12
13

add_action('init', 'restful_services_flush_rewrite_rules');
function restful_services_flush_rewrite_rules() {    
  global $wp_rewrite;
  $wp_rewrite->flush_rules();
}       
 
add_filter('generate_rewrite_rules', 'restful_services_add_rewrite_rules');
function restful_services_add_rewrite_rules( $wp_rewrite ) {      
  $new_rules = array(        
    'services' => 'wp-content/plugins/restful-services/rest.php',     
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}

The problem with the above was that it wouldn’t call "wp-content/plugins/restful-services/rest.php"; it would simply continued to call "index.php" and display the home page!  After literally hours and hours of debugging with my trusty PhpEd IDE & debugger I was able to find that the code on lines 737 & 738 of "wp-includes/query.php" told WordPress that my service was the home page! It is almost seems like the "generate_rewrite_rules" was implemented as "a good idea" yet no testing has ever been done on it because for the best I can tell it doesn’t work. (Note I’ve reformatted the code to multiple lines so that it is easier to read and does not extend past the right margin of my blog):

wp-includes/query.php:

if ( !(  $this->is_singular                           
      || $this->is_archive                           
      || $this->is_search                           
      || $this->is_feed                           
      || $this->is_trackback                           
      || $this->is_404                           
      || $this->is_admin                           
      || $this->is_comments_popup ) )   
       $this->is_home = true;

I could possibly hack it to get past this by setting one of those to "true", but none of them are really appropriate; there is nothing there quite like an "is_service" instance variable. Setting something like "this->is_singular" or "this->is_feed" might work but it could manifest incompatibility problems with other plugins or future versions of WordPress. Frankly it was rather disappointing to discover this because it tells me that WordPress has hard-coded all the potential scenarios and doesn’t really have a way around it. Seems to me there should really be a hook here and the type of pages should be allowed to be expanded by plugins rather than be hardcoded as only one of ’singular’, ‘archive’, ’search’, ‘feed’, … and ‘home.’

Anyway, where this manifests itself is "wp-includes/template-loader.php" file which I have included in it’s entirety below.  It is on lines 24 and 25 where the template loader loaded the home page because it’s not possible to specify otherwise:

wp-includes/template-loader.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

/**
 * Loads the correct template based on the visitor's url
 * @package WordPress
 */
if ( defined('WP_USE_THEMES') && constant('WP_USE_THEMES') ) {
  do_action('template_redirect');
  $is_home = is_home() ;
  if ( is_robots() ) {
    do_action('do_robots');
    return;
  } else if ( is_feed() ) {
    do_feed();
    return;
  } else if ( is_trackback() ) {
    include(ABSPATH . 'wp-trackback.php');
    return;
  } else if ( is_404() && $template = get_404_template() ) {
    include($template);
    return;
  } else if ( is_search() && $template = get_search_template() ) {
    include($template);
    return;
  } else if ( is_home() && $template = get_home_template() ) {
    include($template);
    return;
  } else if ( is_attachment() && $template = get_attachment_template() ) {
    remove_filter('the_content', 'prepend_attachment');
    include($template);
    return;
  } else if ( is_single() && $template = get_single_template() ) {
    include($template);
    return;
  } else if ( is_page() && $template = get_page_template() ) {
    include($template);
    return;
  } else if ( is_category() && $template = get_category_template()) {
    include($template);
    return;
  } else if ( is_tag() && $template = get_tag_template()) {
    include($template);
    return;
  } else if ( is_tax() && $template = get_taxonomy_template()) {
    include($template);
    return;
  } else if ( is_author() && $template = get_author_template() ) {
    include($template);
    return;
  } else if ( is_date() && $template = get_date_template() ) {
    include($template);
    return;
  } else if ( is_archive() && $template = get_archive_template() ) {
    include($template);
    return;
  } else if ( is_comments_popup() && $template = get_comments_popup_template() ) {
    include($template);
    return;
  } else if ( is_paged() && $template = get_paged_template() ) {
    include($template);
    return;
  } else if ( file_exists(TEMPLATEPATH . "/index.php") ) {
    include(TEMPLATEPATH . "/index.php");
    return;
  }
} else {
  // Process feeds and trackbacks even if not using themes.
  if ( is_robots() ) {
    do_action('do_robots');
    return;
  } else if ( is_feed() ) {
    do_feed();
    return;
  } else if ( is_trackback() ) {
    include(ABSPATH . 'wp-trackback.php');
    return;
  }
}

Still another problem in this puzzle is the $wp->send_headers() method shown being called here on line 293 of "wp-includes/classes.php":

wp-includes/classes.php:

290
291
292
293
294
295
296
297
298

function main($query_args = '') {   
  $this->init();   
  $this->parse_request($query_args);   
  $this->send_headers(); 
  $this->query_posts();  
  $this->handle_404();   
  $this->register_globals();   
  do_action_ref_array('wp', array(&$this));   
}

The problem with the $wp->send_headers(), also from "wp-includes/classes.php", is that it seems to have the option of either serving an HTML content type on line 183 and 185, or a content type based on a feed (the content types for the feeds are set in their respective "wp-includes/feed-*.php" files) but no custom content types as far as I can determine as there seems to be no way to override calling this function or the logic path contained within:

wp-includes/classes.php:

175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227

function send_headers() {
  @header('X-Pingback: '. get_bloginfo('pingback_url'));
  if ( is_user_logged_in() )
    nocache_headers();
  if ( !empty($this->query_vars['error']) && '404' == $this->query_vars['error'] ) {
    status_header( 404 );
    if ( !is_user_logged_in() )
      nocache_headers();
    @header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
  } else if ( empty($this->query_vars['feed']) ) {
    @header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
  } else {
    // We're showing a feed, so WP is indeed the only thing that last changed
    if ( !empty($this->query_vars['withcomments'])
      || ( empty($this->query_vars['withoutcomments'])
        && ( !empty($this->query_vars['p'])
          || !empty($this->query_vars['name'])
          || !empty($this->query_vars['page_id'])
          || !empty($this->query_vars['pagename'])
          || !empty($this->query_vars['attachment'])
          || !empty($this->query_vars['attachment_id'])
        )
      )
    )
      $wp_last_modified = mysql2date('D, d M Y H:i:s', get_lastcommentmodified('GMT'), 0).' GMT';
    else
      $wp_last_modified = mysql2date('D, d M Y H:i:s', get_lastpostmodified('GMT'), 0).' GMT';
    $wp_etag = '"' . md5($wp_last_modified) . '"';
    @header("Last-Modified: $wp_last_modified");
    @header("ETag: $wp_etag");
 
    // Support for Conditional GET
    if (isset($_SERVER['HTTP_IF_NONE_MATCH']))
      $client_etag = stripslashes(stripslashes($_SERVER['HTTP_IF_NONE_MATCH']));
    else $client_etag = false;
 
    $client_last_modified = empty($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? '' : trim($_SERVER['HTTP_IF_MODIFIED_SINCE']);
    // If string is empty, return 0. If not, attempt to parse into a timestamp
    $client_modified_timestamp = $client_last_modified ? strtotime($client_last_modified) : 0;
 
    // Make a timestamp for our most recent modification...
    $wp_modified_timestamp = strtotime($wp_last_modified);
 
    if ( ($client_last_modified && $client_etag) ?
         (($client_modified_timestamp >= $wp_modified_timestamp) && ($client_etag == $wp_etag)) :
         (($client_modified_timestamp >= $wp_modified_timestamp) || ($client_etag == $wp_etag)) ) {
      status_header( 304 );
      exit;
    }
  }
 
  do_action_ref_array('send_headers', array(&$this));
}

Still, I was able to come up with a solution although it is so very hackish.  My solution was to hook the "template_redirect" action on line 7 of "wp-includes/template-loader.php" (see code from that file above.) Though it seems to works thus far, my solution just feels wrong for the following reasons:

1. It ignores the fact that WordPress continues to think that my web service URL is the home page,
2. It first lets "$wp->send_headers()" set the content type before it overrides it,
3. It uses an "exit" rather than a return to keep WordPress from serving up the home page template, and
4. It doesn’t use the routing mechanism apparent built into WordPress (see "null" on line 30 of "wp-content/plugins/restful-services/restful-web-services.php" below, I assume it should have been the URL of the .php file I plan to execute but WordPress doesn’t see to use what I put there.)

The function "restful_web_services_exec_service()" is what is called to execute the appropriate web service:

wp-content/plugins/restful-services/restful-web-services.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

/*
Plugin Name: RESTful Web Services
Plugin URI: http://mikeschinkel.com/wordpress/restful-web-services/
Description: This plugin enables REST-based API web services for WordPress.
Author: Mike Schinkel
Version: 0.1
Author URI: http://mikeschinkel.com/
*/
 
define('RESTFUL_WEB_SERVICES_DIR', dirname(__FILE__));
define('RESTFUL_WEB_SERVICES_URL_PATTERN','services(/?.*)?');
$abspath = trim(str_replace('\\','/',ABSPATH),'/');
$rest_services_dir = str_replace('\\','/',RESTFUL_WEB_SERVICES_DIR);
$rest_services_path = trim(str_replace($abspath,'',$rest_services_dir),'/');
define('RESTFUL_WEB_SERVICES_PATH', $rest_services_path);
 
// NOTE, See: http://codex.wordpress.org/Custom_Queries#Permalinks_for_Custom_Archives
add_action('init', 'restful_web_services_flush_rewrite_rules');
add_filter('generate_rewrite_rules', 'restful_web_services_add_rewrite_rules');
add_action('template_redirect', 'restful_web_services_exec_service');
 
add_action('init', 'restful_web_services_flush_rewrite_rules');
function restful_web_services_flush_rewrite_rules() {
 global $wp_rewrite;
 $wp_rewrite->flush_rules();
}
 
add_filter('generate_rewrite_rules', 'restful_web_services_add_rewrite_rules');
function restful_web_services_add_rewrite_rules( $wp_rewrite ) {
  $new_rules = array(
    RESTFUL_WEB_SERVICES_URL_PATTERN => null,
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}
 
function restful_web_services_exec_service() {
  global $wp;
  if ($wp->matched_rule==RESTFUL_WEB_SERVICES_URL_PATTERN) {
    if ($wp->request == 'services') {
      header('Content-Type: text/plain');
      print 'TODO: Generate a list of RESTful Web Services here for this WordPress Blog.';
    } else {
      list($dummy,$service_name) = explode('/',$wp->request);
      if (file_exists($service_php = (RESTFUL_WEB_SERVICES_DIR . '/services/' . $service_name . '.php'))) {
        include_once $service_php;
      } else {
        header('Content-Type: text/plain');
        status_header(404);
        print '404 - Service not found.';
      }
    }
    exit;
  }
}

You’ll note that my function "restful_web_services_exec_service()" is very bare-bones at the moment serving only a plain text message "TODO:" for the path http://example.com/services, and assuming that any path http://example.com/services/{service} will execute a same-named .php file in the services subdirectory, i.e. for http://example.com/services/latest-post it will look for "wp-content/plugins/restful-web-services/services/lastest-post.php" and then delegate all the work to that .php file.

wp-content/plugins/restful-services/services/latest-vidclip.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15

/*
Filename: latest-post.php
Service Name: Latest Post
*/
global $wp_query;
$post = $wp_query->post;
$file = get_attached_file($post->ID);
if (empty($file)) {
  list($file)= get_enclosed($post->ID);
}
$charset = get_option('blog_charset');
header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
$link = get_permalink($post->ID);
$html = &lt; &lt;<post></post><post id="{$post-&gt;ID}">      <video>$file</video>   <link />$link  </post>  POST; print $html;

Here is an example output returned by calling http://example.com/services/latest-post:

1
2

< ?xml version="1.0" encoding="UTF-8"?> 
<post id="2">      <video>http://videos example.org/video1.flv</video>   <link />http://example.org/sample-post-1/  </post>

While bare-bones, that will meet my needs for the moment since I really only have the need for one service that responds to the HTTP GET verb. However, I can see where I might end up fleshing this out and create lots of helper functions that would streamline the creation of web services for RESTful access to the entirety of the WordPress database. If I do so I’ll be happy to donate this plugin to the community.  In the mean time if you’d like to use this for your own use feel free but caveat emptor. However, if you’d like to use this code to create a plugin to contribute to the community, please contact me for collaboration.  Of course if you’d like to retain me to fully flesh it out for you, I’m always open to that too! :-)

Finally, if anyone who knows the WordPress API better than I do can tell me where I erred in my analysis, and I really hope I did, please let me know so I can architect this thing better. On the other hand, if I was spot-on in my analysis maybe this will help the WordPress team understand what needs to be done so they can empower WordPress to generate any arbitrary content type without having to resort to hacks or bypassing the WordPress index.php startup code. 

api, php, rest, restful, web services, WordPress

FCKeditor ShowBlocks Feature

The other day I wrote about how I was using Dean’s FCKeditor Plugin for Wordpress to solve the problems with WordPress’ default TinyMCE editor eating my hand-coded HTML tags.  Well Joe Banks left a great and detailed comment giving several tips including one about the ShowBlocks button. Unfortunately the default comment system in WordPress ate part of his comment so I couldn’t see what he was talking about and went exploring. 

Well it turns out he was right; ShowBlocks is awesome!  It shows the <p> tags, the <div> tags, and more. Check the screen shot above to see a larger version.

Joe Banks forgot to include his blog URL on his comment (or at least I think he forgot), but I was able to dig it up via a quick google.

fckeditor, showblocks joe banks, WordPress

This month at the Atlanta Web Entrepreneurs meetup group I organize we hosted two sharp email marketing professionals: Sandi Karchmer Solow of I Send Your Email and Ben Chestnut, co-founder of Mail Chimp, a successful Atlanta-based Email Service Provider. Sandi presented Email Marketing 101 to the group, and Ben regaled us with his story of how MailChimp came to be.

Sandi gave us a really great base level of overview of the email marketing landscape and explained how its critical to correctly opt-in your subscribers and to give them exactly what they asked for, and only what they asked for. Otherwise you loose trust and the fallout is worse than anything you could gain. Oh, and Sandi was a real trooper to speak this month because she’s about seven months pregnant. So good luck to her and her soon-to-be-newborn.

As for MailChimp, evidently it was a side project that Ben and his partner’s web consulting company implemented to keep a client who wanted them to manage his email broadcast from hassling them, but they didn’t fully embrace it as their primary offering until many years later. And the month after they fully embraced it their revenue exceeded every prior month’s revenue they’d seen life-to-date for their business! Ben told us how MailChimp has a focus on simplicity and when we reviewing his prices we found MailChimp to be very price competitive, especially for email lists of less than 100 which they send for free!

Now most marketers have heard of ExactTarget before but many may not have heard of MailChimp, and based on MailChimp’s low pricing, it simple-to-use interface and its fun and irrerevent name, many people might think that MailChimp is only for businesses with tiny email lists. But most in the audience including myself were shocked to learn that they have successfully delivered some of the largest email broadcasts in the industry!  Ben told us about a major software launch announcements where they sent out millions of of emails in just about 30 minutes! (Ben said the client asked never to be named but believe me, it was major!)

What was especially interesting was when member/attendee Jason Prance mentioned during Q&A that he’d been using both MailChimp, for personal projects, and ExactTarget for a 100,000 name work mailing list, and that he loved the former and really disliked the latter. He then said if he had his druthers he’d be using MailChimp for work but couldn’t switch without re-opting in and loosing probably half his subscribers. To this Ben replied that all he’d need to do is provided his ExactTarget reports showing them being a responsible emailer and then he could easily move his 100k list to MailChimp. Sold!

Anyhoo we had a great time, enjoyed learning about email marketing, and look forward to future Atlanta Web Entrepreneur meetups. Oh, and I want to thank both Sandi and Ben for taking the time to make such a memorable evening for us.  It really is great to have such nice people who are willing to help their peers and who are offering such worldclass services so reasonably priced, all here in our hometown of Atlanta GA. Go Atlanta!

Visit Flickr to see all photos I took for this event.

P.S.: This was NOT a paid endorsement for MailChimp. We invited Ben to speak about MailChimp because one of our members that we really respect recommended him very highly. Plus Ben turned out to be a really great guy and there were actually several members in attendance who already use his service and love it. Evidently, MailChimp really kicks ass!

ben chestnut, email marketing, events, exact target, isendyouremail, mailchimp, meetups, people, sandi solow

Gotta love this error message I got when trying to set a password that was "too long" on Intense Debate:

error messages, intense debate, xml