Page MenuHomePhabricator

Add hover-card like summary (og:description) to open graph meta data printing plain summary
Open, MediumPublic


Currently, shared items via FB, google+, or Whatsapp use indiscriminate text extracts from the lead of an article. We have put a lot of effort into developing a 'card' summary for link preview, related pages and hover cards. We should provide that to social sites so that we are putting our best foot forward to potential users:

FB extracts its own, which often looks awful.

Here is an example from FB:

vs. Hovercards;



Acceptance criteria

  • A feature flag that when enabled adds a og:description meta tag to all pages in main namespace. It's disabled by default
  • og:description is only added if a feature flag is enabled
  • the description should be sourced from TextExtracts or the mobile content service
  • verify the description shows up in WhatsApp, Facebook and Twitter shares.

Developer notes

        OutputPage $out;
	$out->addMeta( 'og:description', $summaryTextNoHtml);

Open questions

Ideally we'd use the new summary endpoint from the MCS for this. However it's unclear if we can use this for every page view and how we would go about doing that. We can use the TextExtracts endpoint, but that would provide sub-par summaries.

Some guidance on the right approach from services and infrastructure here would be useful.

Before he left, Gabriel had this to say.

Out of scope for this task. We may need to sync with the performance team+ops and let them know we're doing this in case it impacts TTFB.

Related: T162328

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson updated the task description. (Show Details)Jan 25 2017, 9:10 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a project: New-Readers.
putnik added a subscriber: putnik.Jan 26 2017, 10:46 AM

@Nirzar @Ladsgroup @thiemowmde any interest on getting this opengraph work wrapped up? I think Wikidata shows wikidata descriptions, but we'd like to show TextExtracts (I'm not sure if it would be better to ship as part of the Popups or TextExtracts extension). How can we ensure we don't end up with both/don't end up with a text extract on Wikidata? Using a config flag?

This seems to be the final piece of the puzzle...

Change 336179 had a related patch set uploaded (by Ladsgroup):
[WIP] Add support for OpenGraph description meta tags

^ This is very basic and I can't work on it until the next weekend. Feel free to take over if you want to get this done before next week.

@Ladsgroup please remove this tag when/if you've taken this further.

Change 336179 abandoned by Ladsgroup:
[WIP] Add support for OpenGraph description meta tags

I don't have time to do this. Hopefully someone pick this up. :(

Calexit added a subscriber: Calexit.

The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally.

Yet this ticket and sisters, under priority "normal," stagnate for years that other developers work on ad-hoc fixes for each for their sites.

@Calexit there's a bunch of problems with MediaWiki and this is just one of them and as the initial attempt showed there's lots of difficulty in doing this.

It would be AWESOME if other developers working on ad-hoc fixes instead helped us improve the code in this open source project for everyone...

Patches and attempts to solve this problem are highly welcomed. You are empowered to fix this and help us reach this goal. I'd be happy to review any patches for this problem. I'd love to see this fixed.

Jdlrobson updated the task description. (Show Details)Jun 5 2017, 5:34 PM
Jdlrobson renamed this task from Add hover-card like summary (og:description) to open graph meta data to Add hover-card like summary (og:description) to open graph meta data printing plain text extract.Jul 13 2017, 7:03 PM
Jdlrobson removed a project: TextExtracts.
Jdlrobson added a project: TextExtracts.
Nirzar added a comment.EditedJul 18 2017, 10:00 PM

@Jdlrobson I found this in Triaged but future, do you think the description is an estimate-able state? I wanted to nominate it for upcoming sprint as the design debt card

Jdlrobson updated the task description. (Show Details)EditedJul 24 2017, 10:10 PM
Jdlrobson added a subscriber: ovasileva.

@Nirzar @ovasileva after some thinking, provided we default this to false (ie. don't enable this anywhere just yet - just do the implementation) I think we can do this whenever - this mitigates the risk of a release. I've updated description to capture this.

default this to false?

Jdlrobson updated the task description. (Show Details)Aug 22 2017, 3:16 PM
Jdlrobson edited projects, added Services; removed patch-welcome.Aug 22 2017, 3:20 PM
Jdlrobson added subscribers: mobrovac, GWicke.

@mobrovac @GWicke is there any possibility we can source the content for og:description from RESTBase within MediaWiki? The new summary endpoint will produce better data than TextExtracts so it would be much more preferable to use that. We'd need to do this for every page view (but only once for a cold cache). I'm not sure if there are any other extensions doing this sort of thing.

@Jdlrobson, in general MW can (and does) certainly fetch data from the REST API. However, there are some potential issues if we wanted to fetch the summary on each parse or skin render:

  • Availability and performance: We should make sure that an outage of the summary service would not cause an outage or serious performance degradation of MW content. We could set an aggressive timeout, and return an empty description in case of failures. Ideally, we would fetch the summary in parallel with other work, but this would require the use of async HHVM extensions / Hack. The current HTML client in MediaWiki only supports making several HTTP requests in parallel, but does not allow overlapping HTTP requests with other code execution.
  • Consistency / race conditions: Most parses happen right after an edit, and often before a summary has been regenerated (there is a race). If MW pulled & cached a stale summary, vandalism affecting the summary could be persisted longer than we would like.

None of these issues would apply if the description was linked from the response, instead of embedded. However, I do not see href support for og:description in

GWicke moved this task from Backlog to watching on the Services board.Aug 29 2017, 3:51 PM
GWicke edited projects, added Services (watching); removed Services.
Jdlrobson renamed this task from Add hover-card like summary (og:description) to open graph meta data printing plain text extract to Add hover-card like summary (og:description) to open graph meta data printing plain summary.Dec 7 2017, 8:57 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

I'm going to do research on this in the near term to figure out what the path forward is

@Fjalapeno I thought the path forward was to do this change? it's been de-prioritised many times but we should make this happen

@Nirzar the issues are technical. The remaining problem is where does the summary come from? We use a RESTBase service for but Minerva's HTML is generated by MediaWiki.

bearND added a subscriber: bearND.Mar 26 2018, 8:41 PM
MtMNC added a subscriber: MtMNC.Aug 30 2018, 10:19 PM
awight added a subscriber: awight.Nov 15 2018, 8:08 AM
Jdlrobson added a subscriber: Jhernandez.

@Fjalapeno any updated on T142090#4082216 ?
I'd love to see the summary HTML response being embedded as a meta tag in the HTML. This would improve sharing for all our users.
Would this be @Jhernandez domain now?
Is this just as simple as adding an HTTP request in a hook in mediawiki?

@Jdlrobson actually @Jhernandez were just hypothetically discussing using MCR to hold a summary data that is editable by editors. So it is possible to have the summary actually be in the page, but we need product buy in on adding this user facing feature first.

This isn't HTML, but of course HTML can be generated from the structured data, which is probably a good strategy anyways.

I've just noticed the VirtualRESTServiceClient exists so I guess that could be used to inject those descriptions

Jhernandez added a subscriber: Tgr.Jan 9 2019, 6:52 PM

@Tgr will be looking into it and making a proposal for implementation.

Relying on the external service on the parser pipeline has a bunch of complications so it is not straight forward. We've been talking about it lately and the pros/cons of the different approaches.

awight removed a subscriber: awight.Mar 21 2019, 4:00 PM
Jhernandez removed a subscriber: Jhernandez.Apr 2 2020, 6:46 PM