Using PowerShell to create new sites based on site-scoped WebTemplates
WebTemplates are definitely a powerful new construct in our SharePoint 2010 toolbox. WebTemplates definitely come in handy as they can be deployed as sandbox-compatible features.
Creating a site based on a web template is pretty straightforward via the UI. Basically it just shows up as another site template option. As a user creating a site, you’d never the know the difference between a farm-scoped or site-scoped WebTemplate. However, if you want to use PowerShell, you will notice that your PS scripts will take on a slightly different shape based on how the WebTemplate is scoped.
If the WebTemplate is deployed as a farm-scoped feature, then you can easily use New-SPWeb in the following manner:
where GUID represents the parent feature ID.
If the WebTemplate is deployed as a site-scoped feature, then your PowerShell needs to be adjusted. Otherwise, if you attempt to use new-spweb, you’ll get the following error message: Template is not found and is not applied. This effectively means the cmdlet could not locate a farm-level template to apply to the new site.
For example...
There are two ways to circumvent this problem:
- Once the site is created, call ApplyWebTemplate
- Before the site created, grab a reference to the appropriate WebTemplate and provide it as a value to the SPWebCollection.Add method on the parent site.
Examples
Calling ApplyWebTemplate
$url = "http://sitecollection/site1"
$w = new-spweb $url
$w.ApplyWebTemplate("{GUID}#WebTemplateName")
Calling SPWebCollection.Add
$url = "http://sitecollection"
$w = get-spweb $url
$template = $w.GetAvailableWebTemplates(1033) | ? { $_.name -eq "{GUID}#WebTemplateName" }
$w.Webs.Add("site1", "sample site 1", "sample description", 1033, $template, $false, $false)
The difference between the two methods basically boils down to the language selection for the new site. With the simple call to ApplyWebTemplate, the new site uses the same language as the parent. By grabbing the reference to the web template beforehand, you have more control.
-Maurice
SharePoint Conference 2011 Wrap Up
This year’s SharePoint Conference was probably one of the most interesting conferences that Microsoft has hosted in the past few years. The attendance was solid and presentations covered the spectrum from 101 fundamentals over all the way over to nitty-gritty details.
Monday morning I had a chance to present on managing the Sandboxed Code Service (SP376). I was a little skeptical that we’d fill a room with 700 seats, but I was very pleasantly surprised to see the room fill up before we switched on the microphone. There were a ton of good questions afterwards as well. Thanks to everyone who attended and posted all the great messages on Twitter. If you have any questions I was unable to answer, please feel free to reach out.
The conference was also a great chance to run into folks. I saw many old friends – some that I haven’t seen literally in years – as well as many clients and former Critical Path Training admin and dev students. It’s always amazing to see the positive energy!
The Aptillon team also had record number of presentations at the conference. We had 7 presentations by 6 different teammates. As a company partner, that is definitely very cool stat however the nicer fact is that we had a chance to hang out. Since we’re spread out all over the US and constantly on the go, it’s rare to have more than 2 people in the same room at the same time.
There was also a record number of Microsoft Certified Masters from across the globe at the conference. How cool is that? I remember the days when Spence and I were the only MCMs who weren’t employed by Microsoft. 
MSL also announced a new certification – Microsoft Certified Architect. It’s really nice to see program growing!
Great conversations all around. New projects, new ideas, confirmation of design decisions... chatting about the sandbox, helping folks get a better perspectives on PowerPivot and it’s amazing potential, the cloud, getting out of the sandbox (aka azure), Windows Phone 7, watching cloud-servicing applications such as Sharevolution hit their stride, building new partnerships... truly exciting stuff!
-Maurice
Regex for Wiki Page regions
In an earlier post, I briefly touched on the value of creating your own InsertWebPartIntoWikiPage method. Part 1 – solved. Now comes Part 2 – where am I injecting my web part?
That’s a valid question that is easily answered whenever you’re using the SharePoint wiki page editing tools within the browser. The tools allow users to basically pick a spot in the rendered text, click on Add Web Part, and you are done. The tools know how to safely inject your web part without forming bad html under the hood.
From a programmatic sense, this is much harder because we don’t get the “smarts” of knowing where to insert the web part markup. Most users that try to use InsertWebPartIntoWikiPage invariably fail the first few times because they forget to account for the fact that they are injecting web part markup into an html blob and therefore need to properly account for well-formedness (is that a word?).
The net result is that folks will create code that looks like…
InsertWebPartIntoWikiPage (file, webpart, randomValueKeepFingersCrossedNothingBreaks)
The validity of the resulting HTML becomes something like rolling the dice at the casino. Most folks can start with an empty page and count the number of characters to the first legitimate location where web part markup can be injected. However, once the page is created and populated, all bets are off and IWPIWP becomes more of a hindrance than an aid but it doesn’t have to be that way.
Wouldn’t it be nice to be able to readily determine where the valid injection points are located? Sure! The answer comes in the form of good old fashioned regular expressions.
If you’re like me, you’ve got a nice little regex library for most any html operation (tag stripping, tag collection, validation, etc). Well, here’s one more that you can add to the list… a regex to safely identify the your Wiki page regions!
This little regex allows you to easily determine how many regions are in your Wiki page and, more importantly, where they begin and end. The regex groups the valid editable regions with the name “InnerHtml”. They represent the blue-bordered regions whenever you are editing a wiki page in the browser (as shown below).
In it’s simplest form, you can now inject your web parts in the right places without destroying your existing HTML. For example, in the following clip, we add a web part at the start of the second region in the page.
Done! Page is updated with my web part in the right place and it all just works.
The really nice thing is that since we’re only identifying the HTML within the region, we can easily use the regex to update the text as needed in the region of my choice.
Here’s another example where we identify a region and then replace it with new text.
What other tricks can you come up with? How about identifying the web parts that exist in the page? How about placing the new web parts in mid-stream w/o breaking the existing HTML structure? All possible with regex, especially now that we’ve clearly identified the InnerHtml of your regions!
You got to love the power of regular expressions because with a little ingenuity you can solve each one of those problems.
-Maurice