MFW another API just stops working without returning any errors

How to fix Twitter embed in SharePoint

Antti K. KoskelaConfiguration, Tech, Tech Tips

Twitter has always been good for developers, except for those who’d like to embed anything – hence making it possible to interact with their contents on other sites than Twitter. I guess it’s understandable, but they seem to hate anyone trying to embed feeds, searches or anything on their sites. And they express their hate by making the developers’ lives more difficult… This time by silently breaking the embed script in a way, that’s tricky to work around.

The Problem

In February 2018, Twitter announced that their widgets will start rendering fallback markup on IE9 and IE10 “in the near future”. Since SharePoint 2013 and 2016 are locked in document mode of IE 10 (i.e. using IE on SharePoint sites causes the user agent to be roughly that of IE10), that means trouble for SharePoint admins. Basically everyone, who’s using Twitter embeds on SharePoint, will be seeing empty feeds henceforth.

Well, save for SharePoint Online users, since SharePoint Online renders in whatever mode Microsoft chooses that week! For them, Twitter feeds will act like erratically, and I feel bad for whomever has to debug the behavior!

Anyway – that change’s immediate effects were surprisingly small. Widgets still rendered, until roughly 2 weeks ago (early May 2018). We started getting reports of Twitter being utterly broken – the embed being completely empty without any fallback rendering whatsoever. What’s worse, the embed fails silently, without any errors anywhere. Looking at the code, it looks like it just checks the user agent and ends the execution – thanks a lot, Twitter, much appreciated!

What’s even worse, is that it applies to IE11 users, too – if they’re in SharePoint, or on a site that’s running in compatibility mode (such as all sites on “intranet” zone). And since IE seems to be most actively used in large organizations, especially on internal communication channels, Twitter just decided to block the majority of IE users in the world from accessing their service via embeds. 

Great.

Luckily, there’s a dirty hack for this situation!

Solution: Spoofing the user agent in SharePoint to fix Twitter

What makes things worse, is the fact that you shouldn’t change the document mode of SharePoint 2013/2016. You should not edit master pages, and if you do, you’ll probably break a dozen OTHER things, since SharePoint relies on being shown in IE10 mode (like IE11 does in compatibility mode – more info about that here). And you can’t really trust the users to change it either, so you’re left with changing it via code.

That way, we can only change it on the pages where Twitter exists, thus isolating the changes and hence the risks of breaking SharePoint completely. The code below is something you can selectively insert on the pages where you have Twitter embed.

A low-tech solution would be to throw this piece of code right here on a page. The easiest way would be by inserting it into a script editor web part:

<script type="text/javascript">

function setUserAgent(window, userAgent) {
    // Works on Firefox, Chrome, Opera and IE9+
    if (navigator.__defineGetter__) {
        navigator.__defineGetter__('userAgent', function () {
            return userAgent;
        });
    } else if (Object.defineProperty) {
        Object.defineProperty(navigator, 'userAgent', {
            get: function () {
                return userAgent;
            }
        });
    }
    // Works on Safari
    if (window.navigator.userAgent !== userAgent) {
        var userAgentProp = {
            get: function () {
                return userAgent;
            }
        };
        try {
            Object.defineProperty(window.navigator, 'userAgent', userAgentProp);
        } catch (e) {
            window.navigator = Object.create(navigator, {
                userAgent: userAgentProp
            });
        }
    }
}

try
{
    setUserAgent(window, "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136");
} catch (e) {
 console.log(e);
}
</script>

<!-- the Twitter a-element and the platform/js code goes here -->
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

This piece of code uses a function (from here), to change the User Agent of the browser runtime. This particular User Agent (“Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”) is actually for Microsoft Edge, as Twitter supports that. This causes the annoying, execution ending User Agent -string check to fail in Twitter’s code… :)

Further reading

If you want to further tweak the embed, there’s a number of parameters you could use. For example, you can limit the number of shown tweets (probably the most typical scenario). Refer to these pages for a reference of attributes you could use:

The following two tabs change content below.
mm
My Twitter profileMy Google+ profileMy LinkedIn profileMy Instagram profileMy YouTube channel

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Posts Related to "How to fix Twitter embed in SharePoint":

Let me know your thoughts!