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]]

gerritadmin wrote:

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.

Please see https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=871029729#Diffs_should_include_log_extracts for a current discussion about this.

There is a related discussion at https://wm-bot.wmflabs.org/logs/%23wikimedia-tech/20181128.txt

Most of that IRC log seems to contain arguments that are invalid when implementing this as a null edit rather than doing extra database queries whenever viewing the revison history. The first real point appears at 16:57:22. In my personal opinion, it should not matter how a ticket is written; the existence of a feature request implies that there is use for the feature, and the feature has no downsides, so it should be implemented. This is open since 2014, and people are now wondering (see Village Pump link above) why this is still not a thing.

The idea of generating null revisions on deletions and undeletions has some disadvantages:

• On a wiki with $wgDeleteRevisionsLimit set to a nonzero value n, an administrator without the "bigdelete" right could theoretically delete and undelete a page originally having a single revision half as many times as n each, and then would no longer be able to delete the page again after that.
• In order for page A to be able to be moved to an existing title B by a non-admin, B must be a redirect to A with just a single revision in its history. If an administrator deletes and then undeletes page B, A would no longer be able to be moved to B by a non-admin.
• If one leaves the checkbox for the null revision corresponding to a deletion event unchecked on Special:Undelete, then the page history would only show a null revision for the undeletion event, not the deletion event.
• The rollback link on the history page would no longer make sense after deleting and undeleting a page, unless the user doing the deletion and undeletion was also the last user to edit the page prior to deletion.
• Thanking a null revision for a deletion or undeletion would generate a confusing "Thanker thanked you for your edit on Foo" notification. It is better to use log thank instead for deletions and undeletions, which would generate a "Thanker thanked you for your action relating to Foo" notification.

Thanks.

1. if this happens, the null revisions are not the main problem – the overall high edit count is. It would be wrong to blame the final straw for breaking the camel's back.
2. Ignore null revisions for non-admin overwriting redirect checks.
3. Force a null revision to be made, do not provide a checkbox.
4. Do not show a rollback link if all the affected edits are null revisions.
5. Thanking for a null revision should cause the same message as thanking for the log entry.

I'm on mobile and it's late. I guess the best approach is to create new issue reports for points 2-5, which are valid suggestions independently of this issue here. I may do so tomorrow.

Sub-tasks created.

Another disadvantage I forgot to list above is that if one first restores only the first n deleted revisions, and then restores the later revisions after, one would have to revert the page to how it was before it was deleted. Of course, a similar problem would also occur when one erases the last n revisions' metadata from an XML file prior to importing, and then importing only the later revisions after undoing the erasure of the last n revisions from the XML file and erasing the earlier revisions instead, but usually we leave the XML file alone and import all of the revisions in one step. In fact, we should never generate a null revision when deleting a page, because it is pointless and if one were to be generated, it would always be based on the latest deleted revision (ar_parent_id), yet we allow partial undeletions that restore only the first n revisions. Also, we should generate a null revision on undeletion only when restoring deleted revisions for an existing page.

Advantages of this restriction:

• Admins without the "bigdelete" right could indefinitely continue to alternately delete and undelete a page with a small number of revisions without ever generating a "too many revisions" error.
• Single-revision redirects would remain single-revision redirects after deletion and undeletion, meaning that non-admins could still move the target over the redirect without needing to implement T211504. Also, if a redirect had more than one revision, an admin could delete the page and then restore only the latest revision, and not generating a null revision would allow non-admins to move the target over the redirect, again without needing to implement T211504.
• The rollback link would continue to make sense on the history page. However, it will not be displayed on the user contributions page, because undeletion would insert a row in the page table with "page_is_new = 1". In case of an existing page, one should do the rollback before doing an undeletion. Of course, one should also do rollbacks before moving or protecting an existing page.

@Ammarpad - you've merged my task T62736 (created 6 months before this one in 2014) here as a duplicate. But I share the many concerns expressed by commenters above about the hacky nature of using null revisions. My task imagined using database queries to provide an integrated view of history and deletion events, and as such I don't think it's a duplicate of this at all.

I misread the dates. I read the bzimport importation date (which appears below the graph card) and assumed they were created the same day.

That said, I believe these tasks are essentially the same. You're very free to unmerge them if you or anyone disagree though.

Done.