Page MenuHomePhabricator

{{main}} template not showing in articles
Closed, ResolvedPublic

Description

Split from T91621#1211438. Quote @DarTar:

{{main}} templates appear to be stripped from the rendered HTML in the app. See these screenshots below taken from the iOS app (latest version) and the stable mobile site on Chrome / iOS (latest version). If confirmed, this is a major issue, preventing readers from finding the best contents associated with the section of an article they are currently reading.

IMG_6904.PNG (1×750 px, 446 KB)
IMG_6905.PNG (1×750 px, 431 KB)

Event Timeline

Deskana raised the priority of this task from to Needs Triage.
Deskana updated the task description. (Show Details)
Deskana added subscribers: Deskana, DarTar.
Deskana set Security to None.

Needs fixing pretty quickly.

This was just a bug fix, so moving directly to "ready for sign-off".

(adding a note for future reference and to keep track of how this may have affected navigation data)

The task is slightly mistitled as the bug affected other section-level templates such as {{see also}} as well as page-level hatnotes such as {{hatnote}}, {{for}}, {{redirect}} etc.

@Deskana Can you point me to where you have documentation about when exactly this bug was introduced and when it was fixed? Thanks.

@Deskana do you know where I should look for when the bug was introduced and fixed?

@Deskana, probably best if I refer this one: @Fjalapeno, @BGerstle-WMF, @Mhurd: got a rough ballpark of when the regression was introduced, and is it clear from the release history when the bugfix was introduced to production?

@leila, are you just curious about the dates, or is there a particular purpose for the dates?

CC @Deskana

@dr0ptp4kt this is valuable data for a natural experiment. Depending on the data, we may be able to understand more about the readers when it comes to the effect of the page composition and lead paragraph on their read experience.

@leila, thanks. So is the thought to look back and then design a new
experiment contingent on the findings?

@dr0ptp4kt we don't need to design a new experiment: we have data (if the logs are still available) from the time the bug was introduced, and we have the logs from the time the bug was resolved. We can compare readers access to content under these two scenarios.

@leila, sweet. Thanks, with any luck the timing for the releases and the
corresponding logs works out.

Hi @Fjalapeno, @BGerstle-WMF, @Mhurd. Can you point me to the time period the bug was present in?

@Mhurd's patch was merged before 4.1.3.96 was released on May 13th, according to our release history.

Sorry, so the fix would've been released in the app store on that date. If you need an app version for when the regression occurred, I'll have to do some more digging.

Hi @BGerstle-WMF. Thanks for the date. So, the fix should be in place starting May 13th. Do you know when the bug was introduced? (We don't need app versions. thank you!)

Ok, so I think we introduced this bug when collapsing info boxes: cff6afe0b30b70759a3616769d27c58f5ebe6836

pasted_file (1×750 px, 512 KB)

Which appeared to ship in version 4.1.2 of the app, which went live April 19th—which also happens to be my birthday. Best present ever!

perfect. thanks a lot, @BGerstle-WMF. We should make sure to prepare a better gift for you next year. (not being sarcastic ;-))

@BGerstle-WMF we just noticed that Dario had created this task on April 16. So the date we're looking for should be before April 19th, right? or we're missing something?