When migrating a SharePoint site collection from 2007 to 2010, you have the option to put your site through the “visual upgrade” process, which basically means trading in all the 2007 UI features for their 2010 counterparts. For most simple sites this is a good idea, but for highly customized publishing sites it can cause quite a few problems. Apparently Microsoft didn’t think about those problems, because once the site collection is on the 2010 server, any new subsites created within it will default to the 2010 UI, and no option is available to prevent this.
Recently at work we migrated a large and highly customized site (research.wustl.edu) from SharePoint 2007 to 2010. Because of the nature of the site and the needs of the client, we did not put the site through the visual upgrade process during the migration, instead opting to leave the site using the 2007 UI. It wasn’t until after we pushed the migrated site into production that one of the clients tried to create a new subsite and noticed that everything in that new site was broken.
Some research on our part revealed that this was, in fact, expected behavior. I’m sure the decision to make all new sites created on a 2010 server use the 2010 UI was a well-intentioned one, but in the case of this site (and several others we tried afterwards), the results were disastrous.
Since this is a publishing site that uses a custom masterpage, all of the server controls on that masterpage either ceased functioning completely, or returned the results that would be expected from a 2010 site. The 2010 corev4.css was linked, which threw the styling of the new subsite into complete disarray, and the 2010 init.js broke just about everything it could. The worst was that the page editing panel that SharePoint 2007 uses was not displayed, and since we didn’t have the 2010 ribbon controls in the masterpage the SharePoint ribbon wasn’t displayed either, meaning there were no page editing controls available anywhere in the subsite. In short, it was a bad time.
It turns out it could have been much worse though. We tried this out on another one of our migrated sites that still used the 2007 UI, and new subsites just didn’t work at all. The masterpage there was completely incompatible with the 2010 UI, and no pages in the new subsite could be reached due to that error.
With all the carnage this caused us, I was somewhat surprised to find that there wasn’t more of an uproar about this online. I did find one social.technet.microsoft thread about it (from which I borrowed some code for my solution), but I suppose there aren’t too many people trying to migrate publishing sites from SharePoint 2007 to 2010 without undergoing the visual upgrade.
I discovered in the aforementioned social.technet.microsoft thread that it was possible to revert a 2010 site to the 2007 UI using SharePoint’s .NET object model. I proved this concept out with a quick console app, and then started looking for a permanent solution. We want our clients to be able to manage content on their sites without our help, so having our server admins run a console app every time someone wanted to create a new subsite was not an option.
After some discussion I realized that the best way to approach this solution was through an event receiver. This would allow us to use the power of the SharePoint object model without requiring each subsite be manually addressed after its creation. By using the “Web Provisioned” event, I created a solution that alters the state of each new subsite as soon as it is created.
The solution itself is fairly straightforward, just a default VS2010 SharePoint event receiver with Web Provisioned as the only targeted event. No customizations were necessary other than adding the custom code to the event receiver CS file.
public override void WebProvisioned(SPWebEventProperties properties)
using (SPWeb oWeb = properties.Web)
//get the masterpage references of the parent site
string parentMaster = oWeb.ParentWeb.MasterUrl;
string parentCustom = oWeb.ParentWeb.CustomMasterUrl;
oWeb.Site.AllowUnsafeUpdates = true;
oWeb.AllowUnsafeUpdates = true;
//enable the option to switch between UI versions
oWeb.UIVersionConfigurationEnabled = true;
//set the UI of the site to version 3 (2007)
oWeb.UIVersion = 3;
//set the masterpage references of the current site to those of its parent
oWeb.CustomMasterUrl = parentCustom;
oWeb.MasterUrl = parentMaster;
//set the current site to inherit both masterpages from its parent
oWeb.AllProperties["__InheritsCustomMasterUrl"] = "True";
oWeb.AllProperties["__InheritsMasterUrl"] = "True";
oWeb.AllowUnsafeUpdates = false;
oWeb.Site.AllowUnsafeUpdates = false;
As you can see in that code, there’s not a ton that goes into this, and most of it is just making sure the masterpage references don’t get screwed up. Running the code without those lines regarding the masterpages caused serious problems, as SharePoint seemed to default to the alphabetically first masterpage as soon as the UI was changed.
Once this solution is deployed to a web application, the corresponding feature will need to be activated in site collection administration. At that point, all new subsites created in that site collection will default to the 2007 UI, and the option to run the visual upgrade will appear in the site settings, just as if nothing ever happened.