OneBox doesn't render boxes for Phabricator URLs

OneBox is not processing Phabricator URLs. Can you help figuring out whether the fix belongs more to OneBox or Phabricator, please? FWIW the Phabricator project itself is using Discourse.

Examples:

A project repository
https://secure.phabricator.com/source/phabricator/

A task
https://phabricator.wikimedia.org/T180854

A commit
https://secure.phabricator.com/D18770

Meanwhile, GitHub equivalents are very informative and look gorgeous:

https://github.com/thingles/foreground/issues/177

https://github.com/discourse/discourse/commit/faa597ff90730c68060137223b881d62a56ad4f9

Simply because phabricator does not have the opengraph tags. ask them to add relevant tags to their <head> section and it will soon start supporting it.

5 Likes

Thank you @itsbhanusharma!

Task created: ⚓ T13018 Support Discourse's specific dialect of OpenGraph metadata tags to enrich Discourse "OneBox" previews

PS: Hm, why this link rendered at least the page title when the links in the first post didn’t?

As per the Onebox Plugin, it uses the same tags used by social networks such as facebook to make them look beautiful. almost every major publication uses it into their websites. The protocol handbook is below and You can consider it for more information.

4 Likes

What I meant is why the URLs in the first post don’t render anything (they also have proper <title> attribute) whereas the URL in my comment above did render a title. I have found a pattern, and now I don’t know whether this is a bug or a feature working as designed.

Here goes a test showing the difference:

A task (URL in new line right below)
https://phabricator.wikimedia.org/T180854

A task (URL in new line with an empty line in between)

https://phabricator.wikimedia.org/T180854

(URL in one line preceded by anything, some text, a blank space)
A task: ⚓ T180854 Create discourse-mediawiki.wmflabs.org (pilot instance)
⚓ T180854 Create discourse-mediawiki.wmflabs.org (pilot instance)

Your first two examples invoke the onebox engine which creates those fancy looking boxes when the linked webpage contains enough metadata (like Open Graph tags). This happens only when there isn’t any other text on the same line. Leading spaces also disable the onebox engine.

In all other cases Discourse tries to create a Mini Onebox, which essentially is just the title of the webpage. By default this works only for internal links on the same Discourse instance.

You probably want to support the following feature request: Should onebox fall back on mini-onebox if no metadata is available?

6 Likes

Just fix your open graph / oEmbed tags, check validity at iframely.com/debug

(Just for clarity, I have no affiliation with the Phabricator project. I happen to use Phabricator in my organization and I link to Phabricator URLs often.)

OK, the bug is on their side, so please follow up with them, not us. Thanks!

1 Like

For clarity, Quim’s examples (of GitHub resources, specifically) are all hard-coded by OneBox and not achievable by Phabricator (or other third-party software) using OpenGraph tags, right?

For example, the “Opened by (author) on (date)”, “changed x files with…”, “Enhancement” tag, and the text formatting in his examples are because OneBox hard codes various GitHub layouts:

https://github.com/discourse/onebox/blob/master/lib/onebox/engine/github_issue_onebox.rb
https://github.com/discourse/onebox/blob/master/templates/githubissue.mustache

…and it doesn’t appear that a similar rendering is possible through OpenGraph.

We could conceivably achieve something similar by submitting a pull request to OneBox, but such a request wouldn’t necessarily need to use OpenGraph (it looks like the GitHub layouts use an Accept header to retrieve the resource in JSON, and ignore the OpenGraph metadata on the pages).

Also, I couldn’t find it documented anywhere, but Discourse appears to require an og:description property in order to OneBox a URL (ultimately in whitelisted_generic_onebox.rb::has_text?). This isn’t required by the OpenGraph spec linked above (og:description is “Optional Metadata”), which led to some confusion.

1 Like

How can you summarize a page without any description? I don’t think an image, or title + image, is a sufficient summary.

In this case, the bare link looks like this:

https://secure.phabricator.com/T13018

The onebox with no description would look like this:

+------------------------------------------------------------------------------+
|  XXX  T13018 Open Graph metadata for beautiful rendering of Phabricator URLs |
|  XXX                                                                         |
|  XXX                                                                         |
+------------------------------------------------------------------------------+

I think this is probably an improvement even without a description because it makes the task title available without clicking through.

This would also be an improvement for OneBox/OpenGraph implementors since they could see that things were working and guess that they might want to add a description, especially if the default rendering had a No description. placeholder.

Maybe for other sites this isn’t an improvement (e.g., the element is largely redundant and wastes more screen real estate), of course. But, offhand, it isn’t obvious to me that requiring og:description produces better behavior.

Also, this is admittedly a bit of a stretch, but in the case of Phabricator the page content is user-generated, and the values which make the most sense to use to populate an og:description tag may be empty. For example, it’s valid to create a task with no description, a code review with no summary, a blank wiki page, a commit with no message, and so on.

Since an og:description tag with an empty value doesn’t count (at least, based on testing it), these resources won’t OneBox, even though a OneBox with an empty description would be the most faithful representation of the resource. To get these resources to OneBox consistently, we’ll need to add a placeholder “No task description.” value so og:description is nonempty.

Er what? There is in fact a description on that page, it’s even titled “description”!

The description reads fine to me, and should be in the og:description field in the metadata for the page, at least the first (x) chars of it, like so:

I haven’t found a similar suggestion, so here it goes:

Have you considered adding Open Graph metadata in Phabricator pages? The use case is to render Phabricator URLs into informative and beautiful boxes in the services supporting that feature.

For an example, here is a comparison between Phabricator and GitHub URLs, as rendered by Discourse:

There’s no og:description tag on that page. I’m suggesting that a rendering like the ASCII art example would, at least for this specific kind of content – with no og:description tag – be better than the link.

In this case, we’ll add an og:description tag when we move forward with this, since the task description is obviously a better description than no description. However, the description may not exist at all, as here:

https://secure.phabricator.com/T13021

Or it may just be a picture of a dog:

https://secure.phabricator.com/T13022

In many other cases, resources do not have a meaningful or obvious description, even though they have a meaningful title. What’s the description of an Almanac service record (this is similar to a DNS entry)?

https://secure.phabricator.com/almanac/service/view/srepox001.phacility.net/

Obviously, this isn’t intractable, it just raises the implementation cost substantially, especially if we don’t want to get bug reports from users like “some pages render fancy and others don’t”.

I just found the behavior (requiring more fields than the OpenGraph spec requires) confusing, and figured I’d mention it in case it it wasn’t an intentional behavior.

In the case of “no actual description” you should synthesize one. Like, what the heck is Phabricator? Why is that picture of the dog there? What’s going on at that link, because I have zero idea even after clicking the link? How would you explain that page to me if I had never seen it before? Heck can you explain it to me even now that I’ve seen it, because I remain confused about what the purpose of any those pages are :confounded:

So if the description field on your side is blank, I suggest something like

This is a phabricator post titled ‘this is the title’, which is used for :question:

The general purpose of opengraph and oneboxing is to explain what the user will get if they click on the link.

Failing to do that, is failing your users.

(Is it some kind of bug tracking system?)

Phabricator is a collection of software development applications similar to the Atlassian suite (code review, wiki, repositories, bug tracking, etc).

All the content is user-generated, so we can’t generate a useful synthetic description in the general case: we have no idea what a particular wiki page is for, or why a user didn’t add a description to a bug, or why a commit message is blank, why a cluster topology record exists, or why a blog post is just a picture of a cat. In many cases, these resources are still useful and relevant in context.

I imagine users posting or reading links to Phabricator are likely have a good understanding of that context. It’s unlikely that you’d go to discourse.digimon-enthusiasts.net and post a link to a Phabricator install, and more likely that you’d go to discourse.seriouscompany.com and post a link to, e.g., a bug in that company’s bug tracker or a page in their software documentation which might be hosted on Phabricator, which most users reading the discussion would understand.

In fact, OneBox already generates a similar box for GitHub issues with no description:

https://github.com/epriestley/poems/issues/4

And for commits with no message:

https://github.com/epriestley/poems/commit/da741f11202f505ead4514591d837b729bb8ce63

So maybe this is a bug with many existing OneBox integrations instead, where the implementation fails users when resources have no natural description?

What I suggest in this case for the og:description is

No description was provided for this wiki page

or

No description was provided for this bug

or

No description was provided for this {whatever it is}

This requirement for description won’t be changing on our end, and I think it’s a bad user experience to allow bad / empty opengraph tags. If you can’t describe the page, then that page has no reason to exist.

1 Like

Alternately if description is not provided by the user, you could repeat the title in the description, with some additional info around state:

Picture of a dog

This is a closed, resolved bug report titled ‘picture of a dog’

or even

Picture of a dog

This is a closed, resolved bug report with an image instead of a proper description.

I think there’s a lot of interesting, useful-to-the-user things you could do here for opengraph descriptions, rather than throwing up your hands and saying “can’t be done, it’s impossible!”

2 Likes