Sitecore SXA metatags

The Sitecore SXA metatags component

A small post on an issue I recently discovered with the SXA metatags component. This is in Sitecore & SXA 10.2 although it might very well be in the later versions as well.

To be honest, I still believe the issue is the content editor - but I have been in the business long enough to realize that sometimes we do have to make our solutions fool-proof.  And I can understand that not all content editors are familiar with all the do's and don't of creating perfect webpages.

So, what is the issue...  some content editors like to use special characters - most of them still harmless... until they decide to start using (double) quotes in the title of a page. This broke the "og:title" and other metatags and the seo monitors went off. 

Of course, they do not fill in the fields for the metatags as that is not really their cup of tea.

Sitecore SXA components - metatags

We are using a few of the out-of-the-box SXA components on the site, and one of them is the metatags component. It worked well for a long time - and still does - but this particular editor managed to break it. 

Adding quotes "" in a text that get injected in a html structure is not a good idea and apparently those characters are not encoded. 

According to another blog I found about non-ascii characters in the metatags, some characters like Japanse and such will be encoded - but not those that make the html invalid. 

 

Anyway, the component is using a view so we could easily intervene with actually just a small change. Not sure if what we did really is the best solution for everyone, but it worked for us and it might work for you as well. 

The view

@functions {
    private static string BuildAttribute(string attribute, string value)
    {
        return (!string.IsNullOrWhiteSpace(value) ? string.Format("{0}=\"{1}\"", attribute, HttpUtility.HtmlAttributeEncode(value)) : string.Empty);
    }
}

This is the new version of the BuildAttribute function inside the view. This is used for all the meta tags in the model so we cover all of them.  The only change is adding HttpUtility.HtmlAttributeEncode around the value. 

So after all, a small fix for an annoying issue that could as well have been resolved in content but as I said in the beginning - we can't always rely on content to be perfect.