Page MenuHomePhabricator

Recently edited articles lose their preview, and it stays lost for too long
Closed, DuplicatePublic


It seems that hovercard becomes invalid upon edit (showing system message "popups-preview-no-preview"), and rebuilding it is done using some kind of job queue.

the problem with this, is that the job queue is exceptionally slow, so pages edited event 24 hrs ago are unavailable.

this creates the perverted result, that the more an article is popular (and hence, more frequently edited), the smaller its probability of having hovercard.

for instance, on enwiki, practically every article linked from main page (unless protected), does not have hovercard - naturally, pages linked from main page gain high probability of getting edited.

on enwiki, no article in "recent changes" regained its hovercard. even on much slower wiki like hewiki, you need to ask for 5000 recent changes, and then scroll almost all the way to the bottom to find an article with valid hovercard.


  1. enable "preview" on your enwiki account
  2. open main page, note that many (most?) of the links show the "popups-preview-no-preview" message
  3. open "recent changes", filter to article namespace, select 5000 changes, and note that even the oldest article in the list (depending on your filters, can be several hours old) still does not have a valid card.

it seems that some really old articles (e.g., "Nevada State Route 375" on enwiki - last edited a month ago when i write this) still does not have a valid card.
(as a side: the last item may be related to T132467 - i think some weird job queue issues can cause some jobs to be delayed almost indefinitely)

do not invalidate card on edit:
(a) - vast majority of edits do not change the popup anyway
(b) - if this is about trying to prevent vandalism to reflect in card, it does not seem to be very efficient or even successful way to achieve this.

it may be good idea to still invalidate cards on rollback.


Event Timeline

This occurs only on vector. Could someone from the team can see this? It should be fixed before being deployed to the 50 wikis (if I understand correctly from T162672)