Page MenuHomePhabricator

Conditionally add AppLinks <meta> tags to page <head>
Open, MediumPublic


Acceptance Criteria

  • Set up a staging environment for iOS (see docs)
  • Implement hooks to add meta tags to page HTML (see below)
  • "Deploy" changes to our staging environment and test it with the app

Markup Spec

Render Universal Links markup on pages in the main namespace (e.g. /wiki/Cat, not /wiki/File:Foobar).

Markup should be rendered with the following "template" and added to the page <head>

<meta property="al:ios:app_name" content="Wikipedia Mobile">
<meta property="al:ios:app_store_id" content="324715238">
<meta property="al:ios:url" content="<page>">

Where <page> is an absolute URL to the current page (e.g.

See a similar patch for Android here:

Event Timeline

Fjalapeno raised the priority of this task from to Needs Triage.
Fjalapeno updated the task description. (Show Details)
Fjalapeno added a subscriber: Fjalapeno.
Jdlrobson added a subscriber: Jdlrobson.
BGerstle-WMF renamed this task from Update MediaWiki to add Deep Link support for iOS to Conditionally add AppLinks <meta> tags to page <head>.Nov 4 2015, 9:33 PM
BGerstle-WMF updated the task description. (Show Details)
BGerstle-WMF added a subscriber: BGerstle-WMF.

@Jdlrobson et. al let me know if there's anything I can do to help. Would be happy to pair on this with someone

Conditionally? That sounds problematic. The page html is cached for not logged-in users (I assume, that applebot isn't logged-in), the parameter name shouldn't be a problem. Wouldn't it be ok, to add the head meta entry for all users?

@Florian Applebot definitely won't be logged in ;-). At this point, our main objective is to figure out the least invasive way to get the markup on the page in a way that won't affect production. Our ideal scenario is:

  • Dev can use a version of the app w/ Universal Links entitlements (OS can detect it handles Universal Links from one or more sites)
  • Dev can navigate to a Wiki page in Safari which has markup
  • Dev can confirm the correct banner is (or isn't) shown, and that the page can be opened in the app

This needs to happen on a MW instance that can serve the site association file over HTTPS (or we need to sign the file with an SSL cert). Might be best if we figure this out over hangout—maybe I'll schedule a meeting and invite you, web leads, and anyone else who's interested so we can figure out how best to accomplish this.

Spoke with @Jhernandez and @dr0ptp4kt, and we determined the iOS team should set up our own MW instance in tools, since we could then:

  • Render universal links markup whenever we want, ultimate flexibility for prototyping
  • Not impact production or need code to be reviewed before we could see changes

Doing this would require:

I'll modify this task's description to reflect the new requirements.

JMinor raised the priority of this task from Low to Medium.Mar 28 2016, 6:25 PM
JMinor added a project: iOS-app-feature-Links.

@JMinor is this task still valid and if so, approximately which iOS release?

There's another New-Readers task which is effectively about OpenGraph tags, and if this here iOS task is still valid, I'm wondering if these things should be grouped under an Epic.

This is still valid, but not a priority right now. As I recall OG tags are an option for supporting this, so please do link this to that effort, since we would want to piggy back/coordinate.

I don't see this as a pure duplicate of the whatsapp elements. I created a parent task to house them both

@dr0ptp4kt There was a question in grooming asking for clearer explanation of what this task is asking for. Could you clarify? Team isn't sure what to do.

I'm not sure why this task is suddenly of such interest. This is a minor follow-on from work that is mostly complete from the requesting teams point of view. I think it was themetically linked to the T142048 ticket which came out of the New Readers project, because they both involve meta tags or 3rd party mark-up. I don't see the need for this to be even on any team's agenda, except if there is some larger meta conversation that happens about how we will decide which tags to add to pages (in which case the policy would apply to this request and provide clear guidance on which tags we will support, how to request/test/deploy them etc, and therefore make further work on this worth anyone's time or effort). If this is being considered in isolation, and is a source of confusion for the web team, I would suggest we stall or close it and I will file a simpler request on the iOS Tracking backlog.

I'll move this to Tracking on Readers-Web-Backlog for the time being.