What's the SharePoint

Wednesday, 19 June 2013

Composed Looks in SP2013 and the SPCOLOR file

The reason for this post is to explain some of the SPCOLOR attributes and their purpose - where they are used and what for. A colleague and myself put this together (so thanks to Olly for the majority of this work) and I'm sure some people may be able to add more details to some of the explanations below.

While Composed Looks in SharePoint 2013 have opened up a whole new way to design SharePoint it comes with some serious limitations. Heather Solomon's blog on "When to use a SharePoint 29013 Composed Look" is an excellent starter to understand some of these limitations and explains things much better than I could.

Microsoft have also put out some pretty decent articles on Composed Looks (http://msdn.microsoft.com/en-us/library/jj927175(v=office.15).aspx is a good starting point) but the main article has one bit missing IMHO: there are no updates to the SPWeb Master Page properties (MasterUrl and CustomMasterUrl).

So here is the file: please feel free to cut and paste into something more readable and use as a starting point for your own exploration.

<?xml version="1.0" encoding="utf-8"?>
<s:colorPalette isInverted="false" previewSlot1="BackgroundOverlay" previewSlot2="BodyText" previewSlot3="AccentText" xmlns:s="http://schemas.microsoft.com/sharepoint/">
    
    
    <s:color name="BodyText" value="444444" /> 
    <s:color name="SubtleBodyText" value="777777" /> 
    <s:color name="StrongBodyText" value="262626" /> 
    <s:color name="DisabledText" value="B1B1B1" /> 
    <s:color name="SiteTitle" value="262626" /> 
    <s:color name="WebPartHeading" value="444444" /> 
    <s:color name="ErrorText" value="FF0000" /> 
    <s:color name="AccentText" value="f44c0a" /> 
    <s:color name="SearchURL" value="358700" /> 
    
    <s:color name="Hyperlink" value="f44c0a" /> 
    <s:color name="Hyperlinkfollowed" value="4F6DBB" /> 
    <s:color name="HyperlinkActive" value="1789C1" /> 
    
    <s:color name="CommandLinks" value="666666" /> 
    <s:color name="CommandLinksSecondary" value="262626" /> 
    <s:color name="CommandLinksHover" value="f44c0a" /> 
    <s:color name="CommandLinksPressed" value="1789C1" /> 
    <s:color name="CommandLinksDisabled" value="B1B1B1" /> 
    
    <s:color name="BackgroundOverlay" value="E5FFFFFF" /> 
    <s:color name="DisabledBackground" value="FDFDFD" /> 
    <s:color name="PageBackground" value="FFFFFF" /> 
    <s:color name="HeaderBackground" value="D9F8F8F8" /> 
    <s:color name="FooterBackground" value="CBEFEFEF" /> 
    <s:color name="SelectionBackground" value="7F95D3F1" /> 
    <s:color name="HoverBackground" value="65CDE9F7" /> 

    
    <s:color name="RowAccent" value="f44c0a" /> 
    <s:color name="StrongLines" value="78C8EE" /> 
    <s:color name="Lines" value="ABABAB" /> 
    <s:color name="SubtleLines" value="E5E5E5" /> 
    <s:color name="DisabledLines" value="E1E1E1" /> 
    <s:color name="AccentLines" value="3BAFE7" /> 
    <s:color name="DialogBorder" value="E5E5E5" /> 

    
    <s:color name="Navigation" value="666666" /> 
    <s:color name="NavigationAccent" value="f44c0a" /> 
    <s:color name="NavigationHover" value="f44c0a" /> 
    <s:color name="NavigationPressed" value="1789C1" /> 
    <s:color name="NavigationHoverBackground" value="65CDE9F7" /> 
    <s:color name="NavigationSelectedBackground" value="C6EFEFEF" /> 
    
    <s:color name="EmphasisText" value="FFFFFF" /> 
    <s:color name="EmphasisBackground" value="f44c0a" /> 
    <s:color name="EmphasisHoverBackground" value="1789C1" /> 
    <s:color name="EmphasisBorder" value="1789C1" /> 
    <s:color name="EmphasisHoverBorder" value="1375A5" /> 

    
    <s:color name="SubtleEmphasisText" value="666666" /> 
    <s:color name="SubtleEmphasisCommandLinks" value="262626" /> 
    <s:color name="SubtleEmphasisBackground" value="C6EFEFEF" /> 

    
    <s:color name="TopBarText" value="333333" /> 
    <s:color name="TopBarBackground" value="CBEFEFEF" /> 
    <s:color name="TopBarHoverText" value="333333" /> 
    <s:color name="TopBarPressedText" value="333333" /> 
    
    <s:color name="HeaderText" value="444444" /> 
    <s:color name="HeaderSubtleText" value="777777" /> 
    <s:color name="HeaderDisableText" value="B1B1B1" /> 
    <s:color name="HeaderNavigationText" value="666666" /> 
    <s:color name="HeaderNavigationHoverText" value="f44c0a" /> 
    <s:color name="HeaderNavigationPressedText" value="1789C1" /> 
    <s:color name="HeaderNavigationSelectedText" value="f44c0a" /> 
    <s:color name="HeaderLines" value="ABABAB" /> 
    <s:color name="HeaderStrongLines" value="78C8EE" /> 
    <s:color name="HeaderAccentLines" value="3BAFE7" /> 
    <s:color name="HeaderSubtleLines" value="C6C6C6" /> 
    <s:color name="HeaderDisabledLines" value="E1E1E1" /> 
    <s:color name="HeaderDisabledBackground" value="FDFDFD" /> 
    <s:color name="HeaderFlyoutBorder" value="D1D1D1" /> 
    <s:color name="HeaderSiteTitle" value="262626" /> 

     
    <s:color name="SuiteBarBackground" value="f44c0a" /> 
    <s:color name="SuiteBarHoverBackground" value="63BFEC" /> 
    <s:color name="SuiteBarText" value="FFFFFF" /> 
    <s:color name="SuiteBarDisabledText" value="D3D3D3" /> 

    
    <s:color name="ButtonText" value="444444" /> 
    <s:color name="ButtonDisabledText" value="B1B1B1" /> 
    <s:color name="ButtonBackground" value="FDFDFD" /> 
    <s:color name="ButtonHoverBackground" value="D9EFFA" /> 
    <s:color name="ButtonPressedBackground" value="9ED7F2" /> 
    <s:color name="ButtonDisabledBackground" value="FDFDFD" /> 
    <s:color name="ButtonBorder" value="ABABAB" /> 
    <s:color name="ButtonHoverBorder" value="9ED7F2" /> 
    <s:color name="ButtonPressedBorder" value="63BFEC" /> 
    <s:color name="ButtonDisabledBorder" value="E1E1E1" /> 
    <s:color name="ButtonGlyph" value="666666" /> 
    <s:color name="ButtonGlyphActive" value="444444" /> 
    <s:color name="ButtonGlyphDisabled" value="B1B1B1" /> 
    
    <s:color name="TileText" value="FFFFFF" /> 
    <s:color name="TileBackgroundOverlay" value="99000000" /> 
    
    <s:color name="ContentAccent1" value="f44c0a" /> 
    <s:color name="ContentAccent2" value="FF0097" /> 
    <s:color name="ContentAccent3" value="996600" /> 
    <s:color name="ContentAccent4" value="F09609" /> 
    <s:color name="ContentAccent5" value="A200FF" /> 
    <s:color name="ContentAccent6" value="00ABA9" /> 
</s:colorPalette>

Wednesday, 1 May 2013

Xslt Timeout

Following on from an earlier article I wrote (XslLink Property and XsltListViewWebParts), I've continued to see intermittent performance issues with XsltListViewWebParts where custom Xsl has been implemented - both in remote files or added as an inline property to a page. The performance problem surfaces in the UI as a correlation ID on a List View Web Part which, when the page is refreshed, works fine. Most often the error occurs following an IISRESET or the deployment of a solution package. When interrogating the SharePoint ULS logs to investigate, the log files reveal problems with the Xslt Transform process going on behind the scenes.

While investigating yet another occurrence of the same problem recently, the error showed up in the logs as a Stack Overflow error. As usual, I started to search the internet for any more advice about the same problem to see if any further advances had been made.

Fortunately, there does appear to now be some help in the February 2012 CU which adds or allows access to a new property on the Farm called XsltTransformTimeout which, by default, is set to 1 second. Using PowerShell we can update this to cater for high demand peaks in service levels.

Here's the details from a Microsoft SharePoint TechCenter issue: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneralprevious/thread/1a38bdff-e40a-4e50-a2e8-47cbcb31cc6b/

Also see: http://support.microsoft.com/default.aspx?scid=kb;EN-US;2639184 for symptoms and also the MSDN blogs: http://blogs.msdn.com/b/joerg_sinemus/archive/2012/03/07/xslt-and-timeout-problem-when-transforming-runs-more-than-one-second.aspx.

Friday, 1 March 2013

XslLink Property and the XsltListViewWebPart

In some recent deployments for different clients, I've had problems with the XsltListViewWebPart when custom XSL is used, specifically when the custom XSL is deployed to the server and the XslLink property of the Web Part is used.

There's a couple of specific problems that I've encountered and I thought it useful to blog about their symptoms to help anyone else that might have similar issues.

One of the problems I've seen is based on a significant performance degradation (see this post: http://blog.vossers.com/2012/01/28/how-the-xsltlistviewwebpart-in-sharepoint-2010-can-be-a-real-performance-killer/). If there are multiple XsltListViewWebParts on a page that employ custom XSL using the XslLink property of the web part then this issue might show up. It appears that the way the XSL on the server is cached, especially on load-balanced environments, can cause a problem if the timestamps are different, i.e. the files deployed at different times. Microsoft appear to have issued a HotFix to resolve some of this problem, but based on the blog post I link to above, I don't think that this will always fix everything. The way the XSL is cached by SharePoint appears to have an issue and can randomly drop all the compiled XSL and attempt to re-compile, using a single thread. In a page with multiple XsltListViewWebParts you can see why this might cause random performance degradation issues. One of the suggested work-arounds is to place the XSL using the XSL web part property, instead of XslLink. I'll come back to this in a moment.

The second problem has recently come to light. I had a deployment that put XSL onto the server. However, I had several XsltListViewWebParts on a page using several different custom XSL files all set up to be used via the XslLink property. Internally it all worked fine, but when the files were deployed into the customer environment, older versions of the XSL files appeared to be used to generate the HTML, and not the newer versions. Without any action on our part, the problem resolved itself overnight. Later on that same day, the problem re-surfaced and the HTML generated was back to the old version. Later again, on the same day, the problem disappeared again without any interference from us.

Having reviewed the problem and found the following article (from October 2012) from Microsoft, I would suggest that any customisation of XSL for the XsltListViewWebPart is done using the XSL property of the web part, and not the XslLink property. In both scenarios, this appears to mitigate any potential problems, so from now on when I do these kinds of customisations, I will always adopt this approach: http://blogs.msdn.com/b/spses/archive/2012/10/23/guidance-for-xsllink-property-with-the-xsltlistviewwebpart.aspx

Tuesday, 29 January 2013

SharePoint Content Organiser and Custom Routing

I recently received a request to spend some time reviewing whether or not Content Organiser Routing could be extended and customised.

The request came out of a problem encountered by one of our consultants when he set up a Content Organiser Rule which routed a document to a separate Site Collection. The destination Site Collection then had its own Content Organiser rules to add a document into a specific library existing in the site and implementing a folder structure based on the metadata included with the document. The folder structure would pre-exist and be set up using a custom Content Type and pre-populated metadata which the document, when it was added into the folder, would inherit.

This worked fine when a folder matching the metadata in the document already existed, however, if the folder did not already exist, despite setting the Content Organiser rule to create a new folder, SharePoint displayed a strange "security validation time out". After a little digging, I founder references to a "security validation time out" error from Microsoft who had already resolved the problem in the form of a requestable Hotfix (KB2596584 - http://support.microsoft.com/kb/2596584) which as far as I could see did not form part of SharePoint SP1 (which is what the server was running). I requested, downloaded and installed the Hotfix (after snapshotting our VMware Server) and it resolved the issue and functionally the system was working as expected.

That was great, so from a client perspective, there was no more odd message that didn't mean much, and not only that but the Content Organiser rule now appeared to working properly.

However, based on our requirement it was necessary that the folder that was created automatically would have to use our own custom Content Type, not the standard Folder Content Type. Despite removing the New Folder options from the destination library and making the custom Content Type available, the Content Organiser would always create any new folder using the standard Folder Content Type, which was pretty much what I expected. So, I started looking into Custom Routers.

A Custom Router can be created using the simple Interface ICustomRouter. It implements a single method OnSubmitFile in which you can do some additional or alternate processing before handing back to the EcmDocumentRouter. Registering a Custom Router is straight-forwards. I used a very simple Console Application as I was only researching the issue, but ideally this would be a Web or Site Feature that registers the Custom Router on activation (and removes it on deactivation).

Once the Custom Router is registered (using the EcmDocumentRoutingWeb.AddCustomRouter method) it becomes available through the UI when you add or edit a Content Organiser Rule:

When you register the Custom Router the first parameter is the Name - this is what appears in the dropdown above. Once this is set up on the Content Organiser Rule it means that the Content Organiser does its normal processing up to a point and then makes the call into the Custom Router. It appears from what I've seen that the call is made to the Custom Router just prior to actually saving the file to its final destination, therefore, any processing that may be required to make this happen would have already been done, i.e. creating a new folder, which I'll come back to in a moment.

The Custom Router's OnSubmitFile method call can return one of two CustomRouterResult options: SuccessContinueProcess and SuccessCancelFurtherProcessing (obviously no room for failure here)...

As I just mentioned, if you are setting a rule up to create a folder if it doesn't exist (which we are in our scenario), regardless of which result you return, the folder will always get created. The difference in result types is more apparent from what happens to the routed file. Returning SuccessContinueProcessing does exactly what it says, it carries on after the Custom Router code and performs the standard and expected behaviour, i.e. routes the document according to what rules you have and actually performs the save to the final destination. SuccessCancelFurtherProcessing, however, doesn't process any further, as the name suggests, therefore, as you can see in the MSDN example, it useful if you are going to handle what happens yourself and you don't need the out-of-the-box routing to do anything. What I would say is that returning SuccessCancelFurtherProcessing will mean that the file is lost: I returned this value during my testing and the routed file disappeared from the Drop-Off Library as expected and never appeared in the destination library which only makes me think that this option is really only useful if you are going to implement the saving of the file yourself.

Back to our scenario, I was able to use the Custom Router to reset the metadata and Content Type of the already created folder (as we get a reference to this in the OnSubmitFile method) which fitted what we were looking for. I had a quick try and yes, it worked, however, there is a caveat. What I expected was that items subsequently added into the updated folder would inherit the metadata set on the folder. In my short trial of this, it didn't work that way, so I suspect I'm not setting something or some configuration is missing, so just be aware that it may be an issue.

Hopefully this has been of some use.

Thursday, 25 October 2012

X-UA-Compatible Meta Tag Not Working

You may or may not be aware that you can force IE to render a web page is a specific document mode, which means that an IE9 browser can be forced to render a page as if it was IE8 or IE7. Why you'd do this is most likely due to the fact that forcing an newer browser to render like an older one (for instance, forcing IE9 to render like IE7) provides a convenient baseline when trying to style a page.

You do this by adding the X-UA-Compatible meta tag to the head block of a page as follows:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

This particular line forces IE to render using IE8 mode. You can read more about it here: http://msdn.microsoft.com/en-us/library/cc288325(v=vs.85).aspx.

There are a couple of caveats to adding this meta tag. The first one is that it must be the first meta tag in the head block (there are a coupld of exceptions to this). The second one is not so obvious, and is the main reason for this article.

If you use conditional comments to render the opening HTML tag of a page (see http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ for details about this) the meta tag just plain doesn't work. It doesn't matter where you place it in the head block, it just doesn't work. If you have the same issue, the way around it, as it turns out, is rather simple if a little weird: move it to before the conditional comments like so:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>




 <html class=""> 

I've tested this and it appears to continue to work as expected with no downside (apart from ugly HTML). Hopefully this will help someone out there.

Thursday, 16 February 2012

Cookies...and not the munching kind

What am I talking about? Well, due to an amendment to the law (the Privacy and Electronic Communications (EC Directive) Regulations 2003, and the new Directive 2009/136/EC) in May last year, the way information is stored by technology is being changed, and primarily how cookies should and can be used and stored - hence the nick-name for this amendment: "The Cookie Law".

The UK government has given businesses a year to comply with the changes, which means that as from May 2012, any organisation that does business in the UK (and EU) is affected.

To find out more: http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/cookie_rules_prepare.aspx

Just so you don't panic too much, this doesn't appear to affect intranets! It only applies to public-facing websites.

Wednesday, 15 February 2012

Learning jQuery

If you ever wanted to learn jQuery but couldn't find the time or the discipline to do so, you can get some daily force-fed lessons by visiting http://learnjquery.tutsplus.com/ and signing up for the "30 days to Learn jQuery" course from Tuts+.

If you're starting out learning this stuff it should provide some structure (hopefully) to your initial learning. Have fun.