Page MenuHomePhabricator

Entire history of Deleted page permanently lost (when using "Creates pages with form::..." in Property)
Closed, DeclinedPublic

Description

Author: alj62888

Description:
How to reproduce:

There is a property called Color which has the following in it's page:

[[Creates pages with form::ColorForm]]

Create a new page, MyColors with the following:

[[Color::Red]]

The Red page does not currently exist, but will be created by ColorForm.

Go to the Red page (after it is auto-created) and do some edits.

Delete Red.

At some point, either reloading MyColors or a background job (not sure), the Red page gets recreated (because the property [[Color::Red]] still exists on MyColors) with it's default page content.

Going to the Red page shows a new page, with default values, of course.

Going to the history of Red shows only one entry, which is for the newly created Red. Past edit history is lost.

Going to the deleted log for Red shows only one entry of when it was deleted. But, if you select the entry to restore, you can then select an older revision to restore specifically. However, it doesn't matter how far back in history you go, it still restores to the newly created blank page...

**Restoring only restores it to the last entry which was the newly created Red.

So, the page Red cannot be restored.


Version: unspecified
Severity: minor
OS: Linux

Details

Reference
bz45087

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:34 AM
bzimport set Reference to bz45087.

alj62888 wrote:

Clarification: the "Going to the deleted log..." paragraph above may sound confusing. The FIRST time deleted, the deleted log shows only one entry. But, while troubleshooting, I deleted it again and then the deleted log shows more entries going a little further back.

Hi Al,

Is this behavior any different from what normally happens when a page is deleted and then re-created?

alj62888 wrote:

Hi Yaron,

Certainly. If you want to restore a page after it was deleted, you will have to hurry before it get's automatically recreated by the "Creates pages with form" directive or else it's recreated without it's page history and only with the default values from the specified form, of course. Because the revision history starts anew, you can't get access to the content before the deletion. Also, restoring via the delete log does not work.

Hi,

Well, there are two possible ways to restore a page after it's deleted:

  1. Undelete the page so that its entire page history is restored.
  2. Just create a new page where the old page was.

MediaWiki allows both, so it's not clear to me that #1 is the better option, for "Creates pages with form". Actually, I would think #2 is, just because the first is open only to administrators, while the second is open to everyone.

All of this brings up another question, though: if this page is meant to be automatically created, why was it deleted in the first place?

alj62888 wrote:

You make good points. If there was at least the feature or series of steps for admins to restore with full history, then I think that would free us of this gotcha situation.

I suppose a simple solution would be to just recreate the page with the history restored, or an option for that if this breaks some design rules.

To your question, the problem is just a matter of ordering of steps during the removal process. The property of the parent page should be removed first before deleting the child page to keep it from being recreated. I suppose these could be the possible steps I just referred to, as long as one is careful. And what if there are many pages pointing to the soon-to-be-deleted page?

I think the main concern is that you can't make a mistake anymore when deleting certain pages under certain semantic setups.

Hi - well, if the issue is just that there a bunch of pages that need to be deleted at around the same time, to make sure that they don't recreate one another, then you could always use an extension like DeleteBatch to do it.

Although, if the page you're talking about is going to be deleted anyway, then what does it matter whether the version history is kept or not, in the brief period of time when it exists again?

alj62888 wrote:

I haven't mentioned anything about many pages being deleted. The use case is one page to be deleted (which, incidentally, may have more than one page pointing to it).

The issue is that a delete can no longer be undone, as is the usual case. A delete is permanent and the previous content is lost forever. No restore. No workaround.

alj62888 wrote:

Just tested with a regular page, that is, not auto-created with a form... just a regular wiki page.

Even after you delete it and the recreate it, you can still restore the older version (before is was recreated). So, this issue states that the normal restore operation/capability has changed in some way.

alj62888 wrote:

Downgraded to minor since I found a workaround; maybe only needs documenation. You have to delete the recreated page and then hurry and restore from a previous revision before it get's recreated. Either hurry or stop the jobs from running in the mean time... and stop access to all parent pages or the wiki.

I confess I still don't understand why the page is deleted in the first place (just by mistake, I guess?), but if the behavior is different from when the page is reconstructed by heaven, then this is indeed a bug.

alj62888 wrote:

lol, well, it was a TEST of a mistake. Ya know, one of those things that people do. /^)

Well, it was good to hear the explanation.

Setting this to "wontfix" - this is just standard MediaWiki behavior when a page is deleted and then recreated, for better or worse. If you want the behavior to change, you would probably have to talk to the MediaWiki people about it.

alj62888 wrote:

Understandable, Yaron. I just see this as a documentation issue... you have to delete or remove the links to the soon-to-be-deleted pages first.