Page MenuHomePhabricator

When page is deleted, sitelink should be removed
Closed, ResolvedPublic

Description

When a page is deleted on the local wiki, the sitelink should be removed from Wikidata. https://www.wikidata.org/wiki/Q7247237 is an example of where this did not happen.


Version: master
Severity: normal
Whiteboard: u=dev c=backend p=0
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36729

Details

Reference
bz49100

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:45 AM
bzimport set Reference to bz49100.

pinkampersand.wikimedia wrote:

I think this is a good idea, but Wikibase would also have to detect when the page is either restored or re-created. Provided that that's possible, though, I'd definitely support this (as the logical correlate to bug 36729), and I'd even extend it to allowing the software to automatically delete items where the only sitelink has been deleted, and there are no links pointing to the item elsewhere in the database (though this latter point could perhaps be optional for sites other than Wikidata).

A side note: The need to detect restorations and re-creations could perhaps be mitigated by an effective redirection feature. This has already been discussed in relation to bug 38664, and I see it as another badly needed feature, for the sake of third-party sites using our data.

By the time we are able to propagate moves from the client to the repo this one should be easy as I tried to keep most of the logic abstract.

I'm not sure about restoring links in case of undeletions though, that's probably not this trivial to implement. Maybe we could store the item association after deletion temporary in rc_params so that we can grab it on undelete. But I'm not really sure we need this after all.

pinkampersand.wikimedia wrote:

(In reply to comment #2)

I'm not sure about restoring links in case of undeletions though, that's
probably not this trivial to implement. Maybe we could store the item
association after deletion temporary in rc_params so that we can grab it on
undelete. But I'm not really sure we need this after all.

Yes, I'm aware it would be significantly more complicated than the inverse. But if an article with no other linked articles gets deleted and restored three times, then we'd have four different Q#s for it (albeit three of them deleted). As I said, this could be annoying for third-party sites. But that's why I suggested redirects as a viable alternative. In fact... is there a bug yet for some sort of "RedirectItem" special page? If not, can I file one?

(In reply to comment #1)

I think this is a good idea, but Wikibase would also have to detect when the
page is either restored or re-created.

'Restored' seems to make sense. But for 're-created', it's sometimes a different topic with the same name, so I don't think that should be automatic.

(In reply to Lydia Pintscher from comment #5)

Marius: What's the status here?

If https://gerrit.wikimedia.org/r/119306 gets approved this will be something I can do in a couple of hours.

Change 170528 had a related patch set uploaded by Hoo man:
Add UpdateRepoOnDeleteJob

https://gerrit.wikimedia.org/r/170528

Change 170570 had a related patch set uploaded by Hoo man:
Apply page deletions to the repo

https://gerrit.wikimedia.org/r/170570

Change 170528 merged by jenkins-bot:
Add UpdateRepoOnDeleteJob

https://gerrit.wikimedia.org/r/170528

Just to keep you updated: The first steep to make this work has been merged today. But it will take at least 3 more weeks to get this to actually work.

Change 170570 merged by jenkins-bot:
Apply page deletions to the repo

https://gerrit.wikimedia.org/r/170570

All patches needed to make this work have been merged.

I'll try to get this announced and deployed next week.