Page MenuHomePhabricator

iOS widgets stuck on placeholder/sample content when feed mostread articles lack view_history
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Install the Wikipedia iOS app with the app language set to English
  • Add the Featured Article, Picture of the Day, and/or Top Read widgets to the Home Screen
  • Wait for the widgets to refresh on a day when the feed's most-read list contains newly-trending articles

What happens?:
All three content widgets fail together:

  • Featured Article: gray "content failure" state; tapping only opens the app (no deep link to the article)
  • Picture of the Day: permanently shows the bundled sample image (the 2015 pacu jawi bull race photo) with a 2-hour retry — indistinguishable from real content, so users report "the same picture every day" (see T430692, the existing user report)
  • Top Read: placeholder content

What should have happened instead?:
Each widget should display the current day's content: today's featured article, today's picture of the day, and the current most-read articles.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
iOS app 8.2.x (reproduced on current main), iOS 26

Other information (browser name/version, screenshots, etc.):

Technical analysis

All three widgets share one fetch (WidgetController.fetchFeaturedContent) that decodes the entire feed payload in a single call: JSONDecoder().decode(WidgetFeaturedContent.self, from: data) (WidgetContentFetcher.swift).

WidgetTopRead.Article.viewHistory is declared non-optional, but the feed API omits view_history for some articles — typically ones that newly entered the most-read list. One such article anywhere in mostread.articles makes the whole decode throw, failing all three widgets, including Featured Article and POTD whose data in the same payload is valid.

Reproducible against production:

curl -s "https://en.wikipedia.org/api/rest_v1/feed/featured/2026/07/20"

| jq '[.mostread.articles[] | select(has("view_history") | not) | .titles.normalized]'

Live results (en.wikipedia):
2026-07-19 → 7 of 45 articles missing the field (incl. long-existing pages like "Lionel Messi");
2026-07-20 → 4 of 47. Decoding these payloads with the current models fails with keyNotFound "view_history" at mostread.articles[N]. Given the frequency, the widgets are likely broken on en.wikipedia most days.

Proposed fix: make viewHistory optional (matching WMFFeedResponse in WMFData, which already models this field as optional) and handle nil at its single call site (the Top Read sparkline). Patch incoming with a regression test.

The issue on top reads:

Screenshot 2026-07-20 at 2.09.14 PM.png (1,179×1,189 px, 188 KB)

Top reads in the explore tab:

IMG_2287.PNG (1,179×2,556 px, 1 MB)

Event Timeline

ABorbaWMF subscribed.

Appears to be fixed on 6125-beta-2026-07-24
Tested all the widgets and changed the device date to check other days. Will check tomorrow as well.
Tested on:
iPhone 16, iOS 26.4.2
iPhone XS, iOS 26.2.1
iPad Air 11 inch, iPadOS 26.3.1

Hey @Tsevener, Just checking, would this fix affect this widget that's not deployed yet? T352836: iOS search widget We're planning to release as part of iOS explore work

Hi @HNordeenWMF! The search widget is still behind a flag, so no users will see it as a part of this release. We did reduce the size of the globe image to conserve memory, so y'all might want to double-check that before it goes out to users in Explore release.