Page MenuHomePhabricator

[Bug] Special:UnconnectedPages lists connected pages
Closed, ResolvedPublic

Description

One example from hu.wikipedia (there are lots): first item on this list
https://hu.wikipedia.org/wiki/Speci%C3%A1lis:UnconnectedPages?page=1977%E2%80%931978-as+spanyol+labdar%C3%BAg%C3%B3-bajnoks%C3%A1g+%28m%C3%A1sodoszt%C3%A1ly%29&submit=Go
is in fact connected to Q597748; according to page history, that connection was made at the end of 2012.

Details

Reference
bz53562

Related Objects

StatusAssignedTask
OpenNone
Resolvedhoo
InvalidNone
Resolveddaniel
Resolveddaniel
OpenNone
DeclinedNone
OpenNone
OpenNone
ResolvedLadsgroup
ResolvedRicordisamoa
Resolveddaniel
Resolved Addshore
Resolvedaude
OpenNone
ResolvedLydia_Pintscher
DeclinedNone
OpenNone
OpenNone

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz53562.
bzimport added a subscriber: Unknown Object (MLST).
Tgr created this task.Aug 29 2013, 8:54 PM

This happens because the database isn't up to date yet. A null edit on the page solves this.

Use a bot to do null edits on all these pages. I've compiled a list for you at http://toolserver.org/~multichill/temp/queries/wikidata/huwiki_touch_bot.txt . The query is at http://toolserver.org/~multichill/temp/queries/wikidata/huwiki_touch_bot.sql

The list contains 16855 items. Ask one of you local (pywikipedia) bot operators to run over this file:

touch.py -lang:hu -family:wikipedia -file:huwiki_touch_bot.txt

That will kill the false positives.

Samat added a comment.Sep 29 2013, 6:37 PM

I went though the list and I did null edit on every page, but I don't see any different on the linked special page.

It seems fine to me now. Is there still an issue that can't be fixed by a null edit?

Similar issues have been reported in my talk page on the Italian Wikipedia, too: https://it.wikipedia.org/w/index.php?diff=61662325

However, I found that even using the MediaWiki purge API https://www.mediawiki.org/wiki/API:Purge with the 'forcelinkupdate' parameter enabled solves the problem.

So:

  • we can consider this bug as RESOLVED (INVALID / WONTFIX), having users to manually purge the cache, or:
  • we state that this bug pertains to WikidataRepo; also the 'Component' field of this bug should be changed accordingly. Wikibase *Repo* (not *Client*) should automatically query the purge API of the corresponding client when adding/editing a sitelink. This is a client-side problem, but only a change on the server-side can fix it.

Lydia, which option would you prefer?

I set it to lower. It should still be fixed. But the priority is lower now. (I'm leaving it in client because that's where the issue is seen.)

Qgil added a comment.Jan 22 2014, 6:36 AM

https://ca.wikipedia.org/wiki/Especial:UnconnectedPages also lists many connected pages as unconnected. Could you help providing the list of pages awaiting a null edit? Thank you.

I have just searched out when this happens. It happens only by pages which include some old interwiki. See for example https://cs.wikisource.org/wiki/Speciální:UnconnectedPages?page=Author%3A-&submit=Prov%C3%A9st&iwdata=only (the most pages are connected) or https://en.wikipedia.org/wiki/Special:UnconnectedPages?page=Category%3A-&submit=Prov%C3%A9st&iwdata=only (some are connected).

I hope this will help solve the problem.

Qgil added a comment.Feb 27 2014, 9:15 PM

(In reply to Maarten Dammers from comment #8)

I made a list for the Catalan wikipedia

Thank you! https://ca.wikipedia.org/wiki/Especial:UnconnectedPages?page=&submit=V%C3%A9s-hi&iwdata=only is now clean.

PS: according to ca.wiki admin Vriullop, who run the bot using Maarten's list, this exercise has been useful to detect potentially systematic vandalism deleting links to ca.wiki but leaving the labels, something that we will have to watch closer at https://www.wikidata.org/w/index.php?title=Special:RecentChanges&tagfilter=new+editor+removing+sitelink

(In reply to Quim Gil from comment #9)

systematic vandalism deleting links to ca.wiki but leaving the labels, something that we will have to watch closer

[[d:User:LinkRecoveryBot]] is doing that for us ;-)

example: [[d:Special:Diff/106570700/108694713]]

  • Bug 68945 has been marked as a duplicate of this bug. ***
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Jonas renamed this task from Special:UnconnectedPages lists connected pages to [Bug] Special:UnconnectedPages lists connected pages.Aug 13 2015, 6:55 PM
Jonas set Security to None.

Per recent improvements in Special:UnconnectedPages I highly doubt this bug is still valid.

Qgil removed a subscriber: Qgil.Mar 8 2016, 9:19 AM
Nikki added a subscriber: Nikki.Mar 30 2016, 10:37 AM

It seems like there's still some issues. I see "1692 nî Sūi-tián" listed here even though the page itself shows the page as being connected to Wikidata.

I see "1692 nî Sūi-tián" listed here even though the page itself shows the page as being connected to Wikidata.

Forcelinkupdate solved.

hoo closed this task as Resolved.Apr 4 2017, 3:21 PM
hoo claimed this task.

This is not actionable.

Due to infrastructure problems very rarely such things might happen, but that's not specific to Wikibase. Also this is only derived data, so it's acceptable if it goes out of sync in extremely rare cases.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 4 2017, 3:21 PM
matej_suchanek updated the task description. (Show Details)
matej_suchanek removed a subscriber: matej_suchanek.