Further to my earlier post about "All Pages, Including Deleted" broken, I have tested this on a new vanilla install untainted by any subsite pollution.

I belive this feature to be significantly broken mostly because get_including_deleted() uses a"latest_version" case in Versioned.php augmentSQL(). The observed behaviour mimics what the code should do.

Try this. Create a new page and then delete it. Do it as draft only or publish it then unpublish and delete draft. When you delete it you will see it appear as a marked deletion until you do a refresh and then it's gone. For good. Selecting the view "All Pages, Including Deleted" does not reveal the missing file because it's not in the SiteTree table. The function I believe is very broken.

If I am wrong or barking up the wrong tree please tell me and put me out of my misery or what the devil I have done wrong. I have spent nearly a week chasing my tail on this one and have posted several times about it.

Silverstripe 2.x does it very differently - using temp tables and it works fine

You are right. I found this myself a couple of days ago. I'll go log a ticket for it.

I believe I am getting somewhere with this. There are two issues. One minor and one major.

In Versioned.php around L238 you will find this line

$query->selectField(sprintf('"%s_versions"."%s"', $baseTable, 'RecordID'), "ID");

The ID it returns is ambiguous and does not override the id in the table swapped by renameTable() above. Thus the IDs returned are the versioned IDs and not the page IDs

Even when this is fixed by renaming it and the corresponding place in CMSSiteTreefilter populateIDS() the function is still broken as then populateIDs() goes on to select the page from SiteTree, where of course if deleted, it does not exist. I have experimented changing SiteTree to SiteTree_versions in the filter but then of course the next stage returns null and so on.

I have not yet figured a neat way around this. It goes right to the top of the cms page tree which uses SiteTree whereas in this case it should use SiteTree_version. In my view it's a major defect as it does not work at all.

I have updated ticket 7975

The query code that exists as input to the "latest_versions" case in Versioned.php augmentSQL() contains a select "SiteTree"."ID"

When swapped using renameTable() - an ambiguous name for this function! the ID becomes one that is only related to the page id when the system is brand new, which is why this may have escaped notice. The ID in the SiteTree_versions table is not the page ID and should be removed from the query

There seems to be no way to remove a select field as in the reverse of selectField(), as a result the selectField() that selects RecordID as ID lower down is effectively ignored. There already is an ID, it appears earlier and it's wrong.

That's just problem number 1. The next is that returning a deleted object ID to the SiteTree results in null. More work to figure this one.

The git pull https://github.com/silverstripe/sapphire/pull/716 discusses this and does not seem to draw the same conclusions in particular the fact that the original swapped id remains. Could this perhaps be a php/mysql version issue?

Since my earlier posts, I have done much work on this and I believe the whole concept to be flawed and unneccessarily difficult. Trying to work out what is deleted is a mess and IMHO thus far wrong, plus it derives the wrong IDs.

Previous versions of Silverstripe used a temp table. Why? I propose the use of an actual SiteTree_deleted table. Simple and effective. We already have a SiteTree_live. I shall have a look at implementing this.

Hi,

Have you raised a ticket on open.silverstripe.org? Some other community members might be interested in helping, it sounds like a good feature.