Other than WordPress and SharePoint sharing similar a capitalization strategy I noticed some other similarities…

When I left MS just over a year ago I decided that I would move from my older (and far more popular) MSDN blog. It was on an old blog engine that wasn’t great and didn’t offer the stuff the new cool kids were doing.  So I started looselytyped.net and hosted it on wordpress.com.  It was super simple to set up and wordpress.com did a lot of it for me.

WordPress.com is like SharePoint Online in many respects. It’s a hosted version of WordPress and because it is hosted there are things that the hoster lets you fiddle with and things they don’t let you fiddle with. Much like in SharePoint Online you don’t get to poke around under the covers of SharePoint like you can with SharePoint on-prem.

WordPress Plugins … aka full trust solutions

WordPress has a concept of plugins.  In SharePoint land this is the equivalent of full trust solutions being installed on your farm.  Obviously (like SharePoint Online) WordPress.com doesn’t let you add these since they could do anything to the server they like and effect other customers. SharePoint Online is the same, Microsoft want to preserve the stability and security of the system for everyone hosted there.

See the similarities between WordPress and SharePoint now? 🙂

Where SharePoint is evolving is in how we get around this limitation of not being able to add functionality in a pluggable but secure and manageable manner.

Step 1: A more secure plugin model … aka Sandboxed Solutions

In SharePoint 2010 Sandboxed Solutions were introduced to offer a sandboxed execution environment for your code. This was far more limited in what you could do in there, but at least it offered some form of online friendly pluggable system.  I was working on the team that owned Sandboxed Solutions in the SharePoint 2010 release & at the time it seemed like a great solution. Remember this was before Azure existed. This was 2.5 years prior to 2010 releasing and “the cloud” was still being called “servers in a datacenter” by most people.

Step 2: An even more secure and flexible plugin model … aka SharePoint Apps

Hindsight is a wonderful thing and looking back Sandboxed Solutions is the wrong model long term. Hosting other peoples code is hard and there are better places to do that than in SharePoint i.e. Azure.

The new SharePoint App model offering remotely hosted code is a far better model going forward in my opinion.  It’s not that I am deeply into “apps” as such … it’s more that this new model offers interesting new plumbing and APIs that developers can use (see SharePoint’s new Plumbing, great for developer).

Where to from here?

Back to WordPress … it doesn’t yet offer a solutions like this (AFAIK). Plugins are full trust solutions that are installed.  In a similar vein Microsoft CRM offers a sandbox where code can run etc…

I wonder when we will see more products like WordPress and MS CRM move to the same architectural model as SharePoint 2013 for custom code and plugins?

I expect to see the new SharePoint App model, or more correctly, the plumbing and APIs that support the app model to evolve in the coming releases fairly rapidly. Allowing us to do more than is possible today and build solutions that integrate with SharePoint in new and interesting ways. The Sandbox has turned out to be a dead end and the new way forward is getting code out of the host process and into better suited places like Azure.

So what is your point Chris?

Oh … well I started writing this post to fill you in on my blog moving. Its still WordPress … but I decided I wanted plugins and all the stuff WordPress.com doesn’t offer.

So I moved my blog to run on WordPress on Azure Web Sites.

Yes I know this sounds like I am advocating for full trust solutions in SharePoint … really I’m not 🙂 SharePoint has a better long term solution for those now 🙂

I wanted the ability to add plugins and get at features in WordPress not offered in the WordPress.com hosted option.

+ I am a big Azure fan … keep up the great work @ScottGu

I won’t regurgitate all the steps to get WP running in Azure … but will point to a couple of helpful posts from John Papa who recently did a similar move.

http://www.johnpapa.net/wordpress-on-azure/
http://www.johnpapa.net/azurecleardbmysql/

One thing I will mention is that I had a hard time getting Azure configured to serve my site on both looselytyped.net and www.looselytyped.net.  Azure Web Sites recently added support for “naked domains” aka… domains without the “www” on the front.  I found it a wee bit tricky to set up due to the requirement to set up a dummy CNAME DNS record so that Azure can check the DNS settings … so in case you are wondering how to do this I have a few screen shots below.

My DNS is hosted with GoDaddy … and the first thing you need to do is add a special CNAME DNS record that Azure checks for.

You need to create an alias for “awverify” and point it at “awverify.<your azure name>.azurewebsites.net … see below…

Then in the Azure management portal click the manage domains button to map domain names to your web site

Here is my setup…

In order for Azure to allow me to add www.looselytyped.net I needed to set up a CNAME record that pointed at looselytyped.azurewebsites.net

In the same vein … Azure would only allow me to add the “naked domain” (looselytyped.net) once I had added the CNAME for “awverify” and point it at “awverify.<your azure name>.azurewebsites.net.

Anyway … I hope this helps the next person who gets stuck trying to get their Azure web site running on a root “naked” domain.  It stumped me for a while and the documentation wasn’t 100% clear.

Thanks,

-CJ.