Last modified: 2014-11-18 12:17:43 UTC
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.
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.
(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.
Marius: What's the status here?
hoo: What's the status here?
(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.
That patch is now merged \o/
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.
