Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

SS3 "All Pages, Including Deleted" Very Broken

Go to End

7 Posts   5218 Views


Community Member, 135 Posts

25 October 2012 at 4:09pm

Edited: 25/10/2012 11:25pm

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.


Community Member, 135 Posts

26 October 2012 at 10:59am

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


Moderator, 4 Posts

26 October 2012 at 11:16am

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


Community Member, 135 Posts

30 October 2012 at 4:17pm

Edited: 30/10/2012 4:19pm

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


Community Member, 135 Posts

1 November 2012 at 10:51am

Edited: 01/11/2012 10:59am

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


Community Member, 135 Posts

8 November 2012 at 9:09am

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.


Administrator, 25 Posts

13 November 2012 at 12:36pm


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