Customizing the Display of a SharePoint 2010 Blog

I’ve changed pages countless times in SharePoint Designer, but this case, where I wanted to make a relatively small change to the home page of a Blog site, proved especially onerous.

In most cases, overriding the default XSL is as simply as editing what’s there and saving your changes.

It would seem that the team that works on blogs doesn’t chat with the rest of the product group, because blogs work differently. Blog pages use an XSL file called blog.xsl, which live in the _layouts folder on the Web Front Ends (WFEs).

On the home page of a blog site (default.aspx), there are several XLV Web Parts, but the main one is the one which displays the most recent posts. All I wanted to do in this case was display a different column instead of Created By (@Author) . Because in many organizations someone different that the author is the person who types the post, we had added a Written By column to the Posts list. The logic was simple: if the Written By column had a value, show it, otherwise show the Created By column as usual.

I wanted to keep the XLV Web Part in place in case we needed to work with it in the future, plus the markup it emits is a bit crufty and I didn’t want to have to replicate it all with a custom DVWP. (In retrospect, this *may* have been easier.)

It should have been pretty easy to make the change, but I went down some rat holes. I don’t want *you* to go down those rat holes, so here’s what ended up working.

Open the page in SharePoint Designer, position your cursor on the XLV Web Part which displays the posts and in the List View Tools section of the ribbon, choose Customize XSLT / Customize Entire View.


This pulls the XSL from blog.xsl into the page, in theory so that we can customize it. However, don’t go down that path; there be monsters. Instead, find the line:

<xsl:include href="/_layouts/xsl/blog.xsl"/>

and Ctrl-Click on the href link to the blog.xsl file. This will open the blog.xsl file in a different SharePoint Designer window for the root of the Site Collection. This is handy, because you now want to save a copy of blog.xsl in a Document Library in the root site of the Site Collection. I usually create a Document Library called XSL anyway to hold frequently-used XSL templates, like the ones I have in my SPXSLT Codeplex Project. I named my copy BlogWrittenBy.xsl.

Close the default.aspx page you opened in the blog site now WITHOUT saving it. Remember? Monsters. Open it again. See, no monsters.

Since we had added a new custom column called Written By, I needed to add it to the ViewFields section so that the XLV Web Part would retrieve values for it:

  <FieldRef Name="Title"/>
  <FieldRef Name="Body"/>
  <FieldRef Name="Author"/>
  <FieldRef Name="PostedByWithDate"/>
  <FieldRef Name="CategoryWithLink"/>
  <FieldRef Name="Permalink"/>
  <FieldRef Name="EmailPostLink"/>
  <FieldRef Name="NumCommentsWithLink"/>
  <FieldRef Name="PublishedDate"/>
  <FieldRef Name="PostCategory"/>
  <FieldRef Name="Written_x0020_By"/>

Then I saved the file. Yes, that customizes (or unghosts) the file. I’m OK with that.

Back to the BlogWrittenBy.xsl file I saved above. I found the section of the XSL where Created By (@Author) is emitted:

<xsl:when test="@Name='Author'"><span class="ms-postfootercolor"><xsl:value-of select="'by '"/></span><xsl:text disable-output-escaping="yes" ddwrt:nbsp-preserve="yes">&amp;nbsp;</xsl:text><xsl:value-of select="$thisNode/@Author.span" disable-output-escaping="yes" /></xsl:when>

and replaced it with this:

<xsl:when test="@Name='Author'">
  <xsl:variable name="ShowPerson">
      <xsl:when test="string-length($thisNode/ &gt; 0">
        <xsl:value-of select="$thisNode/@Written_x0020_By.span" disable-output-escaping="yes"/>
        <xsl:value-of select="$thisNode/@Author.span" disable-output-escaping="yes"/>
  <span class="ms-postfootercolor"><xsl:value-of select="$thisNode/../@resource.wss.ByPrefix"/></span><xsl:text disable-output-escaping="yes" ddwrt:nbsp-preserve="yes">&amp;nbsp;</xsl:text><xsl:value-of select="$ShowPerson" disable-output-escaping="yes" />

This added the conditional logic we wanted.

Next, off to the browser, where I opened the page for editing. In the Tool Pane for the List View Web Part which shows the blog posts, I went to the Miscellaneous section and added a link to my XSL file in the Xsl Link field. In my case, since it was stored in the root of my Site Collection, the link was /XSL/BlogWrittenBy.xsl.

Then I saved the change and voila! Exactly what I wanted.

There are other ways to accomplish what I did here with a deployable feature and managed code, etc. In this case, it was a small farm with only a production environment and a single blog where we wanted to make the change. All you enterprise types just gasped, but this is the reality in many organizations.

Obviously it wasn’t all as simple as what I outline above. Here are some of the things I found:

  • If I edited the XSL in SharePoint Designer (after the Customize Entire View step), my changes worked great in SharePoint Designer,. However, when I went to the browser, I saw the page the same way it had looked before. I believe this is because the blog.xsl file was pulled in anyway, and no amount of jiggling things could get me past that.
  • If I tried to add the XSLLink in SharePoint Designer, which ought to work, it always stripped off the leading / in the link to the XSL file. This meant that the link was invalid and blog.xsl was used again.
  • The sequence I ran through above seems to be the only reliable way to make this work. It’s pretty quick (after 47 tries) and I did it twice as I was writing this. Of course, I had a copy of the original default.aspx file to work with. Never edit the default files without making a copy.

Here are two threads from the MSDN Forums that helped a bit. I didn’t have any luck with the ddwrt:ghost="hide" approach.

SharePoint ‘Customization’ vs. ‘Development’, aka ‘Is It Code?’

One of the great things about being on the faculty at the USPJ Academy is getting to engage in the type of discussions that I recall as being so rewarding in my academic career.  There’s no immediate business crisis at hand, just a bunch of motivated, interested people kicking around ideas to see what makes sense.

I took the “Is XSL Code?” question into the forums in my Data View Web Part Basics course this last week, and there’s been some interesting banter about it.  Everything from “Semantics… Semantics, semantics…” to

But then there are people like my boss who believe that if I call what I do configuration, and I don’t have to compile, build, and deploy in the traditional sense, then he thinks of it as configuration and not coding and, therefore, as acceptable and not subject to our long drawn out Software Development Life Cycle process. So for practicality’s sake, I don’t call what I do coding. Customers get most of what they want very, very quickly, and everybody’s happy.

This isn’t the first time I’ve heard the “if we call it customization, then we don’t have to follow the SDLC [Software Development Life Cycle]” argument.  I’ve certainly played that game a little in client situations myself.

To me, the issue in those cases isn’t whether we’re doing “real development” in our Middle Tier work, but whether the SDLC that is in place for the real development is a successful one that serves the business well.  In the cases where I’ve taken to calling Middle Tier development ‘customization’, the SDLC, while having the best of intentions, has tended to prevent progress and innovation.  Therefore, we’ve sort of end-run the SDLC to get things done for the business.

On some level that always makes me feel a little “dirty”, but I can rationalize it because I’ve provided solid solutions that met the business needs, often coming in under time and budget.  One of my arguments for the Middle Tier is that the exact same SDLC rules ought not to apply. It’s not that good development practices shouldn’t be followed — good development practices should *always* be followed — it’s that the mechanisms are different, so we should reevaluate the SDLC rules to reflect the different methods.

The example I usually use to illustrate this is one where I was doing some consulting for a bank.  The exact same SDLC was applied to the financial systems that was applied to the CSS changes I wanted to make to fix the branding of the SharePoint platform and the paid time off mini-application that I built for a single department. These are vastly different types of systems, which should be viewed quite differently from a governance perspective.  The risks involved are different (real money vs. a logo being a few pixels to the left or someone getting credit for an extra vacation day) and so the SLAs should be different, the development methods should be different, the QA process should be different, etc.  Otherwise, that little CSS change is going to cost a bloody fortune, and in actual fact may just not get done.

So what it comes down to me is a problem of governance rather than a problem of whether it’s code or not.  I would prefer to help redefine the governance model to get it to the point where the business benefits from solid systems that follow reasonable rules over the semantic arguments about what is or isn’t code.  But this is the way the world works sometimes, unfortunately.

Collaborating on Building SharePoint Solutions

Bjørn Furuknap, never the shrinking wallflower, posted an article today about SharePoint Configuration vs. Development.

One of the things that always seems to be missing is the bridge between the two approaches.  I’ve lived on both sides of the wall, and as long as there’s a wall, things fail.  SharePoint is a collaboration platform, yet it’s amazing how infrequently I see people collaborating their way toward a solution.

I’m a HUGE proponent of what usually gets called customization and that’s where I choose to play the game.  That doesn’t mean that I can’t or won’t write "code", it just means that in the majority of cases, I don’t think you need to.  (BTW, I don’t know why it is so, but apparently XSL, JavaScript, jQuery, CSS, etc. aren’t "code".  I think that’s horse pucky.  Code is code is code, and you need to do the right things regardless which one you choose.  For gosh sakes, words are code: look at the trouble people get into using *them* incorrectly.)

So the key, to me, is to understand the portfolio of tools you have at your disposal and which is right for the task at hand.  Don’t use a hammer to drive in a screw.  There’s also a *lot* of middle, fuzzy ground where the right answer might be the one that is going to get you to a solution that works OK in a reasonable amount of time.  So maybe you use DVWPs instead of custom Web Parts (or vice versa) from time to time.  As long as you are actually solving a business requirement, everyone wins.

To paraphrase Rodney King, “Why can’t we all just get along?”

Customization of Everything SharePoint…

This post is based on another interesting question which I answered over in the MSDN SharePoint – Design and Customization forum.  Here’s the question from SLF05:

…basically, the concept of customized vs. un-customized [object within SharePoint] isn’t 100% clear. When it comes to chrome/layout/CSS type files, it’s best to keep [things] un-customized for various reasons which I’ve read a ton of times, but I am wondering, when creating custom columns, custom web parts etc, are those “customized” in the same sense? Is it best to create custom columns and such on development then move them to production via feature rather than create them on the production separately? Or does it not make a difference.
My gut tells me it doesn’t make a difference, but I haven’t read anything that says so or understood the logic enough to make a strong conclusion.

and my answers:

Sort of.  Most of the old concern about customizing pages away from the Site Collection came from the unghosting behavior of SharePoint 2003. IN SOME CASES, this *could* cause *some* performance issues.  (Note how I am being forceful about this.)  I think it became a sort of “urban myth”, as I’ve heard everyone talking about it for so long with no specific evidence.  In SharePoint 2007, this isn’t really a concern.  All pages live in the DB anyway, and I’ve never seen anyone demonstrate that there are any issues with customization.

What you shouldn’t do is change the “out of the box” files without knowing what you are doing.  For instance, editing files in _layouts is usually unsafe, as a hotfix might clobber your changes.  (My partner Pete Sterpe just published a blog post about one way to manage this, if you need to do it.)  Generally speaking, anything in the file system should stay sacrosanct unless you understand the implications.

As for using features vs. the UI to add custom lists, etc., it’s mainly an issue of deployment.  You want to use features if:

  • You have written managed code which you want to be able to version, etc.
  • You have a rigorous deployment process you must adhere to
  • You want to deploy to many places, which would make doing it manually unsafe or tedious
  • etc.

What do you think?  Am I missing the boat on any of this?