A recent Twitter API limitation has prevented some discourse forum oneboxes from being displayed. This theme component enables Discourse to support native Twitter embeds without requiring any of Twitter’s APIs.
The theme component requests a twitter javascript from platform.twitter.com, so if twitter wanted to, it could track you in this javascript and cause privacy issues. You need to weigh whether to trust this social platform that is getting more and more ridiculous now.
To use this component, you must add the Twitter link to the content security policy permission range in the site settings and add twitter.com & x.com to blocked onebox domains
Thanks, I figured it out. After removing the Twitter consumer key and secret from settings it now works as intended, I think it was defaulting to trying to embed using the API because I hadn’t removed those. Thanks again for doing this, would be great if something like this was possible for Instagram as well
It’s working as advertised for me, but maybe not as clear is that in preview one just sees the tweet URL as a hyperlink, the embed happens when the reply or post is submitted.
We’ve done all the modifications recommended above. Our issue now is only if trying to post using a mobile device… embedding a Tweet using a laptop/desktop works fine now.
Some folks want embeds and no need for “login” functionality, and so this component is going to be very popular and yes I see request for other platforms too.
Personally I like the more natural looking twitter embed style than the Onebox, if the more popular platform embeds carry over the native look it differentiates them well in the flow of a topic. Truly great work and can’t help thinking why we didn’t have this before to avoid all the complexities of the dev account setup, but there you go, needs must and the valiant and brave rise to the challenge.
On another point of the fragility of embeds as content after looking at the twitter imploding topic. made me think again of an old idea I had.
If embeds were able to generate a backup bitmap of the embed preview as part of the embed function, that would guard against photobucket outcomes and similar.
I have no idea how that could be coded up but I imagine it would work in principle much like the function that grabs the image of posted image link and is stored int eh native database, while I assume that is easier since it’s an already existing file out there on a server somewhere, it would act as I suppose the same as a custom screen grab function on the fly, that occurs when an embed is committed to a discourse post.
Sites archiving a level of their content is helpful as the net ages, stuff does disappear form time to time.
I’m going to suggest another feature along these lines too here
This is important and just discovered, by putting 2 and 2 together - if you had not CSP enabled before and you use say Google Adsense, you will nuke you ads turning on CSP if using encryption (DM’s) to get the twitter component to work as there is a potential conflict!
I would like to be proven wrong with a super solution or “you did it wrong”
Presuming that oneboxing via API now requires a paid Twitter subscription, this method could/should be added to the Discourse core? Big enterprise communities can afford Elon’s fees, but it is out of reach for non-profits and small time communities.
Twitter’s erosion is a challenging case to handle. It is still the no.1 source for most news and events, used by media houses, corporations and persons of interest. Despite Elon’s shakedown, there is no credible challenger or alternative for the platform.
Losing rich embeds is certainly not wanted, and we’re discussing it to see what can be done properly about this.
When you paste a twitter link in the composer, what does the network tab of your browser dev tools returns?
Are there errors in the javascript console?
We are thinking about it but there are two very big problems that need to be confronted here:
IFRAME means we are allowing twitter to track users. There are privacy concerns.
IFRAME means we need to fight the war of “unknown” height. If we have no height and only get it after we have a chat with Twitter, the page goes jumpy jumpy which can heavily impact the Discourse experience. Figuring out the height upfront is super hard.
Absolutely. This theme component workaround loads JavaScript from Twitters servers, and considering how Twitter is doing in general, this is a massive privacy risk. Therefore I am reluctant to apply this theme component, at least for now.
