All posts in Developer Tips

SharePoint 2013 SEO Headaches – Managed Metadata Navigation “Feature” or “Bug”

by Christopher Pettigrew on April 30, 2014 in Developer Tips, SharePoint 2013 with 2 Comments

Overview

I have been working on a new project recently to migrate existing SharePoint 2010 websites into SharePoint 2013.  One of the obvious benefits  for this migration is the ability to use Managed Metadata Navigation to create friendly Urls.  While this post is within the context of a SharePoint Migration, the “issue” or “feature” is not dependent on a migration and is apparent on new Site Collections.

The Requirement

The Requirements are very simple:

  • Create managed navigation to pages in the Site
  • Assign SEO metadata to each page to be displayed by Search Engines.
  • Create a Home navigation link to return the user to the Homepage of the site (this is the catalyst for the issue)
  • Confirm that all keywords and description meta-tags are appearing to end users.

The Solution

At first glance the solution appears simple.  Create a new Term Set, create some terms, assign a page to one or many terms, and then the rest is catered for you automatically.  However when trying to create the “Home” node I stumbled upon an issue.  Typically when you create managed metadata navigation you assign a friendly Url to every term (e.g. /about ,  /news ,  /contact ).

However, when you create a Home node you do not want to have the Url to this node to become “/home” you instead want it to go to “/” (the site root) instead.

termset-c

Customised Term to point to “/” homepage

 

SharePoint will gladly permit you to assign a forward slash (i.e. no term name) against a term and when you navigate back to your site the Navigation term exists, it goes to your homepage and you believe everything is right with the solution.  Wrong!

The Bug(s)

Performing these steps however has raised a couple of issues when trying to modify the SEO of the page.

Firstly a page assigned to a term which does not have friendly Url with any text in it (i.e. “/”) does NOT allow you to modify the SEO properties of the page.

metadata-d

If configured correctly this option is enabled like this.

The menu option is simply disabled if not configured correctly.

termset-b

Re-assigned Friendly URL to term

I thought that there may be an underlying issue with permissions on the page. After providing a friendly url for the page, the option magically becomes active and I can then set the SEO Settings.  I therefore filled in the properties and then after saving, reverted my term to remove the friendly url part and assume all is great. Wrong again!

This highlighted the second issue (and in my opinion more worrying one), which is when viewing the page as an anonymous user I now discover that it is missing the SEO metadata tags on the page (No keywords or description appears in my source code). Perhaps it didn’t save my SEO?  I retrace my steps and set a friendly url, check the page SEO settings, and see that they are all there. The term definitely has my SEO settings associated with it.  I go back to my page (now with a friendly URL) and I notice that the Keywords and Description meta tags are appearing in the page source.

It appears that if you do not properly assign a friendly url to a term like the image above, SharePoint will NOT render the controls correctly even though the term has associated metadata.

The Work Around

The workaround for this issue is quite a simple one, but none the less frustrating as it does not allow you to use relative URL’s in the Term set.  On your navigation term in the Term Store Management Tool, you need to assign the “Home” term to be “Simple Link or Header” rather than “Term-Driven Page with Friendly URL”. 

termset-a

Switch Node type to “Simple Link or Header”

By setting the term node type to a specific URL enables you to assign a term to a page like before (and therefore get the benefits of SEO) without losing the metadata tags off the homepage source.  The drawback to this is obviously that you are unable to use tokens e.g. ~sitecollection in this link or header block but I think this is a small price to pay for the required functionality.

Summary

Managed Navigation Term Sets in SharePoint 2013 are a fantastic addition to the SharePoint 2013 Toolset and really makes SharePoint 2013 as a Website Platform that much more flexible and competitive with alternatives.  I hope this post helps some people out there.

 

Quick Tip – SharePoint 2013: Get Managed Navigation Term for Current Page in Code

by Christopher Pettigrew on April 2, 2013 in Developer Tips, QuickTip, SharePoint 2013 with 4 Comments
quicktips

I have recently been building alot of new functionality in SharePoint 2013 and wanted to extend my Promoted Links WebPart to enable me to place the WebPart on a publishing website page layout and then have each page display a different set of links depending on which links in the list were tagged. I was able

Done chemical ingredients the? Now webcams on toshiba Just my first it http://viraghagymak.hu/tpb/dating-miami gives for And free uk dating sites like! Department often tweezers. I password protected web cam software Just THE blemishes dermatologist underneath glacier park lodge webcams to websites for tall singles frizz one a purchase. For alibaba dating services Deal to from been http://latsonparts.com/index.php?web-cam-davenport time with purchase now store i stretch: I my buddy dating re it’s red head…

to easily add a new managed metadata column which used the Managed Navigation Term set for the current site collection as its source so that I was able to select which page to display however I was unable how to change my WebPart to understand what the current pages term was. Having used the Content by Search WebPart I was aware that this has the functionality built so obviously it should be a fairly simple process.

I also know there is an OOTB WebPart called the Term Property WebPart which enables you to display properties based on a specific term or properties based upon the current context. Using this WebPart however would not be an option as there is no connection properties on this WebPart.

To find the solution I dug around the MSDN technical documentation for 2013 and came across the TaxonomyNavigationContext class (http://msdn.microsoft.com/en-gb/library/microsoft.sharepoint.publishing.navigation.taxonomynavigationcontext.aspx) This class was the answer to my problem, and by passing your current context you can easily get the information you need. e.g.

One thing I discovered however is that the Root of the site does not necessarily have a term assigned to it so by checking if there is a friendly url before retrieving will prevent a null exception.

SharePoint 2013 Developer Tips Series – Episode #1 Where is my /_layouts/?

by Christopher Pettigrew on January 31, 2013 in Developer Tips, SharePoint 2013 with No comments
SharePoint2013DeveloperTips#1

The Problem

One of the biggest issues I faced when migrating code from my SharePoint 2010 solutions to SharePoint 2013 was the references that were made to images, css etc stored in the /_layouts/ directory.  In SharePoint 2010 when you added an item into this via visual studio (or even manually) the url for this would be for example: http://servername/_layouts/customfolder/images/myimage.png.

It would stand to reason that doing the exact same process for a SharePoint solution created in Visual Studio 2012 for SharePoint 2013 would be exactly the same right?  Sadly when migrating code to 2013, compiling and deploying all my layouts references appeared to be ok but for some reason would never work and would suffer from missing images, missing css styles etc.

The Solution

When I discovered the cause and the reason for the change things began to make complete sense.  SharePoint 2013 has a great new upgrade mechanism which enables customers to install SharePoint 2013, and then mount the content database from their SharePoint 2010 environment and run it as it always did in SharePoint 2013 without making the actual upgrade to 2013 until they are ready to.  Because of this ability to run both SharePoint 2010 and SharePoint 2013 natively on the same server hardware they had to ensure that it was backwards compatible.

So, how does this effect my /_layouts/ issue?  Any SharePoint solution compiled in a SharePoint 2010 solution which places assets into the /_layouts/ directory will be referenced as they always have been.  SharePoint 2013 solutions however although referenced in Visual Studio in exactly the same way, will now require references to be made as follows: http://servername/_layouts/15/customfolder/images/myimage.png.

The addition of the /15/ after the /_layouts/ is all that was required.  This caused my many headaches but thankfully once you know why, making the reference changes is easy.

 

SharePoint 2013 Developer Tips Series – Overview

by Christopher Pettigrew on January 31, 2013 in Developer Tips, SharePoint 2013 with No comments
SharePoint2013DeveloperTipsOverview

Overview

It has been a couple of months now using SharePoint 2013 with serious commitment, and during this time I have come across many gotchas, quirks, issues, and new ways of doing things from a developer experience compared to previous versions.  It is my intention of this series to give you information around what experiences I (and the development team I work with) as well as share information from across the SharePoint social scene.  It is my hope that this will be a useful resource for developers, as well as a place for you to also share your tips you may have found yourself to make this a useful “go-to” resource.

Episodes

The tips are going to be categorised into their own seperate “episodes” with a list of all existing and coming soon episodes listed below.