Last modified: 2014-09-01 19:56:17 UTC
Add null revisions for page delete and restore events. In the case of a page deletion event, the null revision would be stored as a new archive table row.
Could you explain what problem are you trying to solve, or why would it be useful?
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #1) > Could you explain what problem are you trying to solve, or why would it be > useful? Then the page history (index.php?action=history) can display the deletion and restoration log events. That seems like a pretty important part of the history of what's been happening with the page, much like imports. [[mw:Manual:Null revision]]
Change 157636 had a related patch set uploaded by leucosticte: Save a null revision in page history notifying of deletion/undeletion When a page is deleted or undeleted, save a null revision in the page history. https://gerrit.wikimedia.org/r/157636
History splits/merges/etc. are already really messy as it is, and this would make them even worse for virtually no gain. There's no good reason to duplicate this information that's already in the logs.
(In reply to Jackmcbarn from comment #4) > History splits/merges/etc. are already really messy as it is, and this would > make them even worse for virtually no gain. There's no good reason to > duplicate this information that's already in the logs. I wonder if there are some other log events that don't need to have null revisions either? Like page protection events?
(In reply to Jackmcbarn from comment #4) > History splits/merges/etc. are already really messy as it is, and this would > make them even worse for virtually no gain. There's no good reason to > duplicate this information that's already in the logs. ?action=history (that is, the page's history) probably should include matching items from Special:Log. The fact that page protections and page moves leave a visible entry and administrative actions such as page deletion and page restoration do not leave an entry in the page history is strange and unexpected, I think. We're logging this information, why oddly segregate it? It should be integrated. There's some parity with Special:Contributions and Special:Log (cf. bug 3716). There's a real design issue here: in the GUI, we're currently poorly exposing what should be internal implementation details. Yes, there's a revision table and a logging table, but only people working on MediaWiki need to care about this. There are a few different approaches we can take to address this issue. This bug report is probably a duplicate of bug 4172.
(In reply to MZMcBride from comment #6) > need to care about this. There are a few different approaches we can take to > address this issue. This bug report is probably a duplicate of bug 4172. What approaches did you have in mind?
(In reply to Nathan Larson from comment #7) > (In reply to MZMcBride from comment #6) >> need to care about this. There are a few different approaches we can take to >> address this issue. This bug report is probably a duplicate of bug 4172. > > What approaches did you have in mind? Figuring out a way to fold Special:Log entries into ?action=history and Special:Contributions is one approach. Another approach would be adding null revisions when deleting or undeleting. But I'm not a huge fan of this idea, as it feels messy. Even the null revisions being inserted for page protection and page moves feel kind of hackish to me.
Don't null revisions also have the drawback that changing the visibility of a log event doesn't automatically change the visibility of the null revision?
(In reply to Nathan Larson from comment #9) > Don't null revisions also have the drawback that changing the visibility of > a log event doesn't automatically change the visibility of the null revision? Yes.
(In reply to Jackmcbarn from comment #10) > Yes. Filed as bug 70261.
> (In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #1) > > Could you explain what problem are you trying to solve, or why would it be > > useful? > > Then the page history (index.php?action=history) can display the deletion > and restoration log events. That seems like a pretty important part of the > history of what's been happening with the page, much like imports. > [[mw:Manual:Null revision]] "Add null revisions for page delete and restore events" This is an implementation design/decision, not a valid issue. Please see the summary description in the "how to report a bug" guide [1]. Changing accordingly. The problem with this patch is that it will "fix" it for new deletions and restores, but old actions won't have that null revision. (In reply to MZMcBride from comment #6) > The fact that page protections and page > moves leave a visible entry and administrative actions such as page deletion > and page restoration do not leave an entry in the page history is strange > and unexpected, I think. We're logging this information, why oddly segregate > it? It should be integrated. Yes, that's not very consistent. But when you delete the whole page, you delete the entire history, so there's no point in having an entry in the history about that unless you restore the page again. (In reply to MZMcBride from comment #6) > There's a real design issue here: in the GUI, we're currently poorly > exposing what should be internal implementation details. Yes, there's a > revision table and a logging table, but only people working on MediaWiki > need to care about this. There are a few different approaches we can take to > address this issue. This bug report is probably a duplicate of bug 4172. Agreed. Although page moves can mess the things. Imagine you have a lot of logs in page A, you then move page A to B (without leaving a redirect), and then move page C to A. With the current logging system, if this approach would be implemented, the page history of A would have the history of the old page C mixed with logs of the new page B. ---- [1] https://www.mediawiki.org/wiki/How_to_report_a_bug(In reply to Nathan Larson from comment #2)
If the inconsistency is a problem, I'd much rather see it fixed by removing the null revisions from the things that cause them now, rather than by adding them in even more places.
