Last modified: 2014-09-01 15:15:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5843, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3843 - Implement semi-deletion
Implement semi-deletion
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Page deletion (Other open bugs)
unspecified
All All
: Low enhancement with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 2288 (view as bug list)
Depends on: 4857
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-31 02:37 UTC by RSpeer
Modified: 2014-09-01 15:15 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description RSpeer 2005-10-31 02:37:06 UTC
The Pure Wiki Deletion System
(http://en.wikipedia.org/wiki/Wikipedia:Pure_wiki_deletion_system) is gaining a
good deal of support on en:, but before it can go anywhere, it needs to be
implemented in the software. The policy changes will be easier and more relevant
to discuss if the software already supports the new system.

We request these software changes:

* A link to a blank page should show up as a red link.
* When a user follows a link to a blanked page, the page should behave the same
way that deleted pages do now, except there will be an additional message, reading:

"A former version of this article was deleted by [USER NAME/IP] on [DATE]. The
reason given for deletion was: [EDIT SUMMARY]. You may view the article's
history, edit the last version, or type new article into the white space below."

* The blanking or unblanking of a page should be logged, and listed on
watchlists and recent changes like the other logs (the move log, the protection
log, etc.)
* Blanked pages should not show up in searches using Special:Search, random
pages using Special:Randompage, or the list of all pages using Special:Allpages.
* The URL prefix to a blank page should be listed in robots.txt, and the page
will emit "noarchive" and "noindex" and "nofollow" tags, to prevent caching in
search engines.
Comment 1 mysekurity 2005-10-31 03:01:07 UTC
There should be an option to protect pages from being deleted, such as known 
articles (towns, actual things), and articles that are going through AfD 
discussions
Comment 2 RSpeer 2005-10-31 03:02:53 UTC
I'm not sure why that option would be necessary; you can just revert it like any
other edit. Please suggest changes to the proposal on its talk page:
http://en.wikipedia.org/wiki/Wikipedia_talk:Pure_wiki_deletion_system .
Comment 3 Demi @ Wikipedia 2005-11-28 19:31:49 UTC
It might be easier, and more clear, if instead of basing the above logic on a
blank page, there is a purposeful directive ("#DELETED", for example) that can
be edited into the page, like a redirect, for special handling.
Comment 4 mysekurity 2005-11-28 21:00:12 UTC
I agree with Demi. I'm also thinking maybe an intermediate option would be having the page creators 
be able to delete their own pages, or pages that they've created/are the main (not adding 
templates/cats to) of. If this proposal fails, I'd like to see that at least come in, so as to take 
some of the strain off of the Speedy cat.
Comment 5 Rob Church 2005-11-29 00:41:31 UTC
This will need some discussion in the relevant places on Wikipedia. When you
start mentioning the CSD categories, you go out of the scope of BugZilla.
Comment 6 Rob Church 2005-12-23 15:58:19 UTC
*** Bug 2288 has been marked as a duplicate of this bug. ***
Comment 7 Tim Starling 2006-01-06 12:30:35 UTC
As Brion pointed out last time this came up, the problem with it is that it
requires blanking and unblanking to invalidate the caches of all pages which
link to the target page. As such it's predicated on the creation of a purge
daemon which can perform this task in the background, or some other efficient
invalidation or update scheme.
Comment 8 Demi @ Wikipedia 2006-01-13 16:07:06 UTC
I'm not sure I fully understand Tim's comment. When a page is reduced in size,
don't the linked pages change the class of the link so that the (now a) stub can
be displayed in a different color? Or is the cache purging required by a
different feature in the specification?
Comment 9 Rob Church 2006-01-13 16:25:15 UTC
(In reply to comment #8)

The cache for those pages has to be purged in order that they'll be accurately
reparsed on next view. The simplest case which would occur if this didn't happen
is that you'd get "blue links" to nonexistent pages.

Comment 10 Brion Vibber 2006-01-22 04:17:56 UTC
Restored from flood attack.
Comment 11 Ryan Delaney 2006-02-10 10:19:14 UTC
Tim Starling's comment might be alleviated by simply giving every user a
"delete" button which would subsequently blank the article, add the blanking to
the edit history, and perform any other necessary tasks. 
Comment 12 Andrew Garrett 2007-12-05 11:19:07 UTC
No activity on this bug, proposal seems to have died out, and there are no current plans to implement this. => WONTFIX.
Comment 13 Brion Vibber 2007-12-06 19:18:06 UTC
Been on my list for years.
Comment 14 Andrew Garrett 2008-08-08 10:07:27 UTC
I'm working on a deletion queueing extension, which may supersede this bug (uncontested deletion by non-administrators will be allowed).
Comment 15 Aaron Schulz 2008-09-11 06:38:40 UTC
Closing per #12 and #14. Better than the hacks this would need.
Comment 16 tisane2718 2010-03-10 08:12:57 UTC
I will be implementing this via an extension. http://www.mediawiki.org/wiki/Extension:PWD
Comment 17 tisane2718 2010-03-13 16:59:49 UTC
Extension complete. The prototype can be viewed here: http://rped.org/PWDwiki/ The problem mentioned in Comment #9 occurs in this extension, but I'm not sure what can be done about it.
Comment 18 Platonides 2010-05-23 22:02:44 UTC
Look at Article::doDeleteArticle, you should call Article::onArticleDelete( Title ); calling Title::resetArticleID( 0 ); seems also a good idea.
Comment 19 tisane2718 2010-05-25 03:56:03 UTC
Platonides, I implemented your suggestion for article blankings (including when the blanked pages table is populated using the special page). Article unblankings presently trigger touchLinks(), invalidateCache(), and purgeSquid(). That seems to suffice; any other suggestions? Thanks.
Comment 20 Nathan Larson 2013-12-13 22:13:58 UTC
The extension is obsolete, never implemented all the functionality that was called for, and is in need of a rewrite. Therefore, this bug should be reopened.
Comment 21 Nathan Larson 2013-12-13 22:15:48 UTC
"Semi-deletion" seems like a better name, and easier to understand. It's analogous to semi-protection, which gives you some of the advantages of protecting a page and some of the advantages of not protecting it.
Comment 22 Bawolff (Brian Wolff) 2013-12-13 22:25:08 UTC
Why not just give deletedhistory rights to everyone? Then they could view deleted pages like admins can.
Comment 23 Nathan Larson 2013-12-13 23:26:33 UTC
I've thought about that. Is there a downside, aside from what's described at https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Deleted_pages_should_be_visible ?

That change wouldn't go as far as what the proposal calls for, though. To more fully adhere to the wiki way would require that non-sysops also be able to undelete the articles. I'm not sure what the downside of that would be, either, from a technical standpoint, other than that to hide all the revisions from view would require ticking a bunch of checkboxes for a RevisionDelete, rather than just hitting a delete button.
Comment 24 Bawolff (Brian Wolff) 2013-12-14 00:44:24 UTC
(In reply to comment #23)
> I've thought about that. Is there a downside, aside from what's described at
> https://en.wikipedia.org/wiki/Wikipedia:
> Perennial_proposals#Deleted_pages_should_be_visible
> ?
> 
> That change wouldn't go as far as what the proposal calls for, though. To
> more
> fully adhere to the wiki way would require that non-sysops also be able to
> undelete the articles. I'm not sure what the downside of that would be,
> either,


There's an issue where we can't get a list of log items for a specific user if that user is an anon (Its a bug. I think there's someone even working on that). Otherwise I see no technical reason to just use the permission system for people who want this sort of thing.

> from a technical standpoint, other than that to hide all the revisions from
> view would require ticking a bunch of checkboxes for a RevisionDelete, rather
> than just hitting a delete button.

I don't really follow. Revision deletion and normal deletion are totally separate (which is super confusing. Particularly for images). Giving people revision deletion ability is entirely separate from giving them normal deletion ability. You could give everybody both rights, neither rights or one of those two rights.
Comment 25 Nathan Larson 2013-12-14 01:03:24 UTC
(In reply to comment #24)
> I don't really follow. Revision deletion and normal deletion are totally
> separate (which is super confusing. Particularly for images). Giving people
> revision deletion ability is entirely separate from giving them normal
> deletion
> ability. You could give everybody both rights, neither rights or one of those
> two rights.

I'm saying that if sysops want to keep revisions from being viewed by the general public, they'll have to make more use of RevisionDelete, since the public will be able to view the deleted history (i.e. the revisions in the archive table). Hopefully the page deletion revamp will fix that confusing situation. https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion
Comment 26 Nathan Larson 2013-12-18 18:08:11 UTC
(In reply to comment #24)
> There's an issue where we can't get a list of log items for a specific user
> if
> that user is an anon (Its a bug. I think there's someone even working on
> that).
> Otherwise I see no technical reason to just use the permission system for
> people who want this sort of thing.

Yeah, logging actions done by anons may not have been a high priority in the design/programming process (see bug 14735) since most wikis haven't deemed it advisable to let anons take the sort of actions (e.g. page moves) that would be logged.
Comment 27 Nathan Larson 2014-08-04 23:26:00 UTC
I guess another reason to use semi-deletion is that it eliminates the potential for, e.g., issues such as those described in bug 69047. A combination of semi-deletion and revision deletion would enable one to avoid using the archive table altogether.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links