Dynamic Master Page Logic

I recently had a need to set a specific master page based on a query string. In this particular example, a SharePoint page needed to be loaded within a frame which presented the need to load a custom master page without navigation, header, ribbon, etc. Initially, I took the approach of simply turning off the unwanted elements with CSS but this approach means those DOM elements are still loaded behind the scenes, even if they’re hidden. This produced a higher than desirable load time and I went off looking for a way to set the master page within my page layout, but doing so in such a way that the master used when the page was “framed” would only be used in that scenario, as opposed to all the time. The solution turned out to be quite simple…

On initialization, the page will grab the MasterPageFile property as set by the web’s configuration. Within my custom page layout, I added the following simple script block to override the default OnPreInit of the page and set my custom master.

<script runat="server">
    protected override void OnPreInit(EventArgs e) {
        base.OnPreInit(e);
        if (this.Request.Url.AbsoluteUri.Contains("frame=true")) {
            this.MasterPageFile = "framed.master";
        }
    }
</script>

I’m using the AbsoluteUri property to check the URL for my “frame=true” reference, which is what ultimately triggers the change in master page. If you go to http://lab/Pages/Test.aspx the Test.aspx page will be rendered using the master page the site is configured for. If you go to http://lab/Pages/Test.aspx?frame=true it will be rendered using the “framed.master” master page.

For some additional background, you can take a look at this post by Eric Overfield, and this post by Juan Larios.

Custom CSS and SharePoint Branding (The Right Way)

There was a post on Stack Exchange this morning that struck a bit of a nerve with me. I don’t aggravate easily, but I’m a firm believer that the purpose of public discussions is to promote best practice methods and share that knowledge with people that have asked for answers to their problems. When best practice approaches were suggested by James Love (@jimmywim) and myself, we were practically attacked by people insisting that their practices were the way things should be done. I’m not naive–there’s a lot of people that make a lot of bad decisions–but the purpose of the community should be (and largely is) to help share the right way things should be done. The size of the deployment or scope of the customizations shouldn’t be an excuse for making bad decisions and following bad practices. At the risk of beating a dead horse, this is the best practices approach for deploying custom CSS styling in SharePoint (and why you shouldn’t be using these other methods).

Suggested Method 1: Write your own custom CSS selectors, and put !important on every selector.

The first suggestion on Stack Exchange was that you had to put !Important on all of your selectors to override any SharePoint styles. If you find that you need to use !important to make your CSS take priority over the out of the box CSS, either your selectors are wrong, or your custom CSS is being loaded before the core CSS. When CSS is rendered, the highest priority selectors will be those that are the last to be loaded (unless an !important declaration exists). Not as big of a deal here but in terms of the actual order of operations, your browser will also treat any inline style attribute as a higher priority than your stylesheet (be it embedded or linked).  SharePoint’s core CSS uses nested selectors, so the selectors for your custom CSS must follow suit. If SharePoint us using “body .s4-ca” and you make a custom selector called “.s4-ca”, the browser will render the more specific selector since it has a higher priority. Using !important is a bad practice (for all CSS/web development, not just SharePoint), because it drastically changes the approach you need to use to override that selector/class later. Finally, you need to think about cross-browser compatibility. In SharePoint 2010, this absolutely applies. In a lot of cases, you must write a style one way, then write a modifier to make that style render correctly in older browsers. Flagging !important on all of your styles makes this a real mess.

The use of the !important flag is simply a lack of understanding for how the browser will prioritize CSS markup. There’s a lot of resources out on the web that cover this, but in a nutshell: more specific selectors have priority over less specific ones, and in a scenario where two rules have the same weight, the last one specified will have a higher priority. Use debugging tools such as those in Internet Explorer or the ones within Google Chrome or the Firebug extension for Firefox to identify the selectors that SharePoint uses. Personally, I prefer Chrome because the developer tools are included without the need of an add-on, and you can make real-time changes to the CSS which are rendered in the browser as you edit (making it an excellent development companion when authoring new CSS). Once you know what selector SharePoint is using, use that same selector. Lastly, make sure that your custom style sheet is being loaded into the master AFTER SharePoint’s core files because remember, when rules have the same weight, the last one loaded takes priority. This ensures that your styles take over, without filling your markup with !important flags.

Suggested Method 2: Just modify the core files in SharePoint Designer.

Obviously it’s a bad practice to edit any core files, be it Master Pages, CSS or JavaScript. A particular user was adamant that it was an acceptable method because when you customize a file in SharePoint Designer a local copy is created just for that site, so you’re not affecting any other sites on the farm. While this is true, updates to core files can still be made during service packs or patches, leaving your customized file behind. Granted your custom master pages are never going to be updated, but keeping the core files uncustomized ensures you have a supported rollback plan–something you obviously loose when you start customizing the core files. There’s a lot of talk about SharePoint upgrades these days, and this is one of the things that will potentially make your upgrade an utter nightmare. Sure, you can go in and reset all of the customized files to their definition, but should you have to? Making a copy of a file takes all of a couple seconds and it will make your life 10 times easier if you need to reset to vanilla SharePoint. Can you just edit files, yes. Does it work, yes. Should you do it, no.

Best Practice Method 1: Branding Deployed via Solution

Hands down, the best practice for branding deployment is a Visual Studio solution packaged into a WSP and deployed to the farm. This method makes maintenance and updates to your branding solution easier, gives you more robust change control, and integration with source control (such as Team Foundation Server). Deployment via solution also makes your branding reusable between multiple site collections. Unlike modification of files in SharePoint Designer, you no longer have to touch 10 master page files to brand 10 sites; simply activate the solution. If you need to deploy an update to your solution, the update will automatically be pushed to each site where the solution is active (assuming you haven’t customized the files in SharePoint Designer). A correctly built branding package will also give you the capability to rollback to vanilla SharePoint with just a few clicks. It may not seem like an important thing now, but when you go to upgrade to the next version of SharePoint you’ll be glad you can do that.

Best Practice Alternative: SharePoint Designer

SharePoint Designer is a tool that has a lot of functionality. Yes, you have the ability to modify master pages and things of that nature, but it doesn’t mean that you should. Simply because you can do something doesn’t make it a best practice. That said, in certain environments you may not have the ability to deploy a solution; either due to a lack of staff with the know-how, a policy restriction, or lack of the necessary access to the server. In those scenarios (and only in those scenarios) should SharePoint Designer be used for branding. If you must use SharePoint Designer, you should follow some common-sense guidelines, one of the fundamental ones being to not modify out of the box files. If you need a custom master page, make a copy of the v4.master and work from that.

Where Should the CSS Live?

The purpose of a stylesheet is to promote reuse. It doesn’t make much sense to include your styles in every page, and in SharePoint 2010 where we have standard and minimal masters, it doesn’t make sense to duplicate your common styles by including them in each master page. Your stylesheet should be an external file, stored where it can be used by all instances of the masterpage(s) using them. If you’re deploying your branding using a solution, then most likely these files should live in a folder within the 14 hive. I’m personally not a fan of putting them in the style library, since (despite being able to manage it from the 14 hive), your browser will treat them as separate files for each site collection. This means that my browser will re-cache my stylesheet for each site I go to, even though they’re exactly the same file. If it’s 10 lines of CSS then this is negligible, but if I’ve got a few hundred it makes a difference.

Continuing Education

I’m not one of those people that usually promotes books, but if this topic is something that you wish to brush up on I suggest you get your hands on a copy of Randy Drisgill’s (@drisgill) book. He covers (in detail) processes for branding as well as the issue of CSS priority.

Demo
James created a great screencast that shows the process for correctly referencing external CSS files using the SharePoint:CSSRegistration tag. Check that out below, and visit his blog at http://e-junkie-chronicles.blogspot.com/.

Validate Application Pools & Identities

I ran into a scenario where I needed to validate what application pool and identity a particular service application was running as. While you can do some round about poking through the UI or through IIS, it’s also pretty simple to grab this information using PowerShell.

Service Applications
First things first, we need to grab a list of all of our service applications. We can skip this step if you already know the name of your service application.

Get-SPServiceApplication

Get-SPServiceApplication will output a list of all service applications configured on your farm. You’ll notice that by default you see three columns (DisplayName, TypeName and Id). As a result of the three columns, PowerShell will truncate the contents of the columns to allow them to all display. This means that if you have long service application names, you probably won’t see the full name. To get around this, we can specify the column(s) we want to see.

Get-SPServiceApplication | Select DisplayName, Id

Once you’ve identified the service application you want to validate (or if you already knew it), we can create a variable containing all of the properties for that particular service application. The “Identity” parameter should match the DisplayName of the service application.

$serviceApp = Get-SPServiceApplication -Identity "My Service Application"

Alternatively, you can also use the GUID to select the service application.

$serviceApp = Get-SPServiceApplication 00000000-0000-0000-0000-000000000000

Now that we have our $serviceApp variable containing all of the properties for our service application, we can view (or set) any of the available properties. The Get-Member cmdlet allows us to view a list of all objects, properties and methods that are children of the current object. In this example, it would list all of the objects, properties and methods of our selected service application.

$serviceApp | Get-Member

We can now determine the application pool and the identity of that application pool by viewing the ApplicationPool property of our service application.

$serviceApp.ApplicationPool

Web Applications
Much like we did with service applications, we first need to identify the web application that we want to work with.

Get-SPWebApplication

Get-SPWebApplication will output a list of all web applications configured on your farm. The nice thing is that web applications are a little more intuitive because we can use the URL of the web application to identify it, and that’s almost certainly something you’re going to know off the top of your head. Once you’ve identified the web application you want to validate, create a variable containing that web application.

$webApp = Get-SPWebApplication http://mywebapp.corp.tld

Just like we did with our service application, we can use the Get-Member cmdlet to list all of the objects, properties and methods of our web application.

$webApp | Get-Member

We can now determine the application pool and the identity of that application pool by viewing the ApplicationPool property of our web application. Note that Microsoft hasn’t been this consistent throughout SharePoint as a whole, and there’s a lot of cases where you’ll find differences between property names on objects where you’d think they would be the same. Learn to love the Get-Member cmdlet, which will always show you what you’ve got to work with.

$webApp.ApplicationPool

Executing all SharePoint 2010 Health Analyzer Jobs

One of the most useful lines of PowerShell script (as far as SharePoint 2010 goes) has to be the ability to kick off all of the SharePoint Health Analyzer timer jobs in one shot. This single-line of PowerShell is something you should always have in your back pocket, whether you’re validating a newly built farm or performing post-maintenance testing. Once you’ve loaded the SharePoint snapin, simply execute the following line of PowerShell, then surf over to Central Administration to check the farm health.

Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} | Start-SPTimerJob

Delivering SharePoint Success

Here's a few photos I captured today of @meetdux getting the crowd excited about SharePoint Project Mgmt. @trispug http://t.co/nhgRGuW #in

August 30, 2011 18:52 via HootSuiteReplyRetweetFavorite

@webdes03

Michael Greene

We just finished wrapping up a great event with the Triangle SharePoint User Group focused on the project management side of SharePoint adoption and deployment. Special thanks to Dux Raymond Sy (@meetdux) for coming down to Raleigh for this special event. The Triangle SharePoint User Group meets on the first Tuesday of every month, and additional details about meeting topics and group information can be found on our website, or via our LinkedIn group.

An Introduction to PowerShell

This marks the first post in a new series on using Windows PowerShell with SharePoint 2010 (possibly the best marriage of concepts since Hewlett and Packard—a befitting reference given all of the mention of WebOS in the news this week).

In order to take advantage of the true power of PowerShell (no pun intended), you need to have at least a little bit of background on how to get started. While we will be using the SharePoint 2010 object model with PowerShell, you don’t need to be a true developer to take advantage of (some of) the powerful capabilities contained within the beast. As we progress toward the path of writing our own cmdlets and such, the discussion will inevitably turn more dev-focused, but for now let’s focus on the basics.

PowerShell as a Technology

Windows PowerShell is just that, a “Windows” product. In fact, it’s the native Windows management shell, not a technology that’s unique to SharePoint. The nice thing about this is that we can use PowerShell to interact with Windows components, such as services and operating system configuration, in addition to Active Directory, SQL, and other products (including SharePoint).

PowerShell vs. SharePoint Management Shell

If you’ve been poking around on your SharePoint server, you may have noticed that you have two separate shell’s on your system—PowerShell itself, and the SharePoint Management Shell . Aesthetically, the only difference between the two is that the SharePoint Management Shell is black (which gives it more of a command prompt look), and the PowerShell console is actually blue. Both consoles are technically PowerShell, and I’ve got no idea why the SharePoint one is black—unless it was simply to ease the transition from STSADM to PowerShell.

You can open the SharePoint Management Shell from the “Microsoft SharePoint 2010 Products” folder in the start menu. Native Windows PowerShell can be opened either via the PowerShell icon on the task bar, or by navigating to “Accessories” -> “Windows PowerShell” from the start menu.

Functionally, there are a few differences under the covers. When you load the SharePoint Management Shell, it will automatically load the necessary SharePoint components without you having to do any additional steps. In short, you can open it up and fire away. The native PowerShell console won’t (by default) load the SharePoint components, so if I were to open PowerShell and execute something like a simple Get-SPSite command, I’d be greeted with a big red error message saying that it doesn’t know what the Get-SPSite cmdlet is.

So what are these “components” that are being loaded? PowerShell components are broken into two categories: Snapins and Modules. Snapins can be easily loaded by executing Add-PSSnapin and Modules can be loaded by using Import-Module. You can load a snapin anytime you need to, or you can build a custom profile for PowerShell that’ll automatically execute every time you load the console—loading the snapins and modules you frequently use (such as the SharePoint snapin).

SharePoint for Public Facing Government Sites

Tasha (@TashasEv) re-tweeted a post by @TopSharePoint this morning with a list of public facing government sites built on SharePoint 2010. The list comprises of government sites from around the world, and while some of them aren’t terribly new it is still a great showcase of major organizations and agencies leaning on SharePoint for their public site needs.

RT @TopSharepoint: Showcase of Government websites built on SharePoint platform http://t.co/6fRpak7 #sharepoint -> interesting...

August 21, 2011 09:10 via TweetDeckReplyRetweetFavorite

@TashasEv

Tasha Scott