This link is not “oneboxing” on my site–
Hmmm and I see it isn’t here either. Yet ABC News has (unsurprisingly) a zillion open graph tags including all the Facebook and Twitter OG tags. Is this a bug, possibly? And/or is there nothing Discourse onebox can harvest from all that metadata? 
Thank you!
The two usual culprits are missing open graph tags, or something either blocking the Discourse UA or cloud provider IP ranges. Just because we can see the tags locally in our browser doesn’t mean the server necessarily can.
A bit of tinkering in cURL from your VPS will usually identify the cause.
Use the iframely tool to troubleshoot the opengraph / oembed tags in the page. Lacking a text description of any kind is another reason I sometimes see in the wild.
Hmmm ok. I think I might have figured it out… it is a missing “description” field, perhaps?
Here are 3 links from big sites and the related iframely reports.
https://abcnews.go.com/Politics/federal-appeals-court-overrules-judge-orders-flynn-case/story?id=71426720
ABC News iframely report
https://edition.cnn.com/2020/05/15/health/gallery/coronavirus-people-adopting-pets-photos/index.html
CNN iframely report
The only difference I can see between the ABC News example, above, and this NBC News link is that NBC includes more image sizes, icons, and a date and description. Could any of those be “showstoppers” that prevent onebox from kicking in?
Hmm and CNN is also missing a description, but does have an icon and date. So maybe description is a required field… ?
Yes, no description means no onebox.
Oh. :-/
That seems like… a dramatic step. I don’t see why all the beautiful grace of the onebox should be discarded if just a description is missing. I’ll try to do a PR that allows sites that don’t have a description field (so far, we have found that ABC and CNN are two of them) to still let the image and headline through.
I was actually thinking given the number of times this has come up as a support topic … if the only thing preventing oneboxing is lack of a description (or a too short description), we should probably add a placeholder description, something like:
This page provided no description tags
Then at least it oneboxes and it’s clear what is going on, can you assign that @sam?
I wonder if we should just remove the “description required” rule and make it optional at the site setting level:
The onebox on the OP is pretty reasonable imo, the description feels unnecessary.
With all due respect-- if a description is not available, why display a message like this?!
This is a useful message if you are debugging onebox. For techies like us, great, terrific.
But if you are a normal human being 
who just wants to post a link to some non-tech site and you don’t care about the internal workings of onebox, this message adds nothing except noise. I promise you, a vast majority of the people using Discourse (on sites about cars, software support, communities, audio equipment, etc.) don’t know or care what a “description tag” is, or why it matters, nor do they care if the link they posted “provided” it or not. All they want is their links to look pretty, period, full stop.
That said: yeah, I think we all agree that there’s no need to hobble onebox to work only on sites with a description tag-- especially when a description is not really necessary. A headline and photo not only look perfectly acceptable, but they are far better than nothing.
Neither Facebook nor Twitter require descriptions (and they never add a message like “This page provided no description tags”), and they have no problem working with just a photo and a headline to make a nice looking link. I see no reason that my favorite forward-thinking forum software can’t follow suit. 
This is premature. This may or may not happen, @codinghorror is the PM and gets to choose the implementation we go with.
I think that the no description, no onebox rule should be lifted and be an opt-in thing if we must, but ultimately this is not my call.
If we lift the “no description, no onebox” rule or make it optional we may need a new visual template for for descriptionless oneboxes, this is not a trivial problem. “no description, not onebox” rule was born from people complaining that they did not like how it rendered without descriptions.
Federal appeals court overrules judge, orders Flynn case dismissed as DOJ requested is a lot of blue text. Twitter for example display that text in black, not blue.
Fair enough.
It does seem weird to me that if the choices are:
Hey, check out this article:
Hey, check out this article:
Really, people prefer option A over bption B? (And more to the point-- really, folks complained that option B was ugly? It seems perfectly workable to me, aesthetically…)
Not sure I follow what you are saying here? When I post a link on Twitter, if there’s no description, it still expands fine? Here’s a test I just did with the CNN link from my 1st post in this thread.
And here’s how Discourse currently renders the exact same link:
So glad people are taking care of the doggies…
https://edition.cnn.com/2020/05/15/health/gallery/coronavirus-people-adopting-pets-photos/index.html
Sorry to piggyback but to help reduce support noise could we also have more verbose logging of onebox failures at some point, so site admins are less in the dark when things don’t ‘box?
I am fine with the change as long as the layout doesn’t require a lot of fixing @sam … this has long surpassed the rule of 3 so allowing oneboxes without a description is probably fine at this point.
Thank you @codinghorror and @sam, much appreciated.
Onebox gem now support title-only oneboxes per this commit. Example:
You reverted this a few months later with this PR. What was the reason?
