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.
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.
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.
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.
(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.)
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:
âŚ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.
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.
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:
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)?
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
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
The general purpose of opengraph and oneboxing is to explain what the user will get if they click on the link.
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:
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.
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!â
