Yes, there is a row with the right classname in Sitetree and Sitetree_Live.
Here is the code from NewsHolder.php

Try switching ShowInMenus on NewsHolder to 1 and see if the get_one() works?

This, for example, should definitely work, as it takes no consideration of whether the page should be visible in menus or not:

However, I don't recommend using the above for anything but debugging purposes. Mostly, because it does not augment any queries that modules or the Versioned extension may make.

Cheers,
Sean

There are two facets to this:

1. Someone has introduced a ParentID into the Page object. Not sure how (decorator?) but when you upgrade to 2.4.2 from 2.4.0 and do the dev/build you can see it being created (Page.ParentID & Page_live.ParentID).

2. As I have now learnt to my own joy developers are advised to ALWAYS qualify your database table references.

I even myself had previously assumed (yes, Ass, You, Me) that as SiteTree was the basis for all Pages (Page being an extension of SiteTree) there would be no need for another ParentID in child objects and have never bothered to fully qualify it as I have done for nearly all other fields where they may appear in another object and get picked up in the DataObject::get's huge database join.

E.g. while I would have gone

$theThingies = DataObject::get('Thingie','"Thingie"."ID" = 0');
$theThingies = DataObject::get('Thingie','ParentID = 0');
$thePages = DataObject::get('SiteTree','"ParentID" = 0');

Where the first will always be valid and has to be done as you could never be sure there wasn't another object with field name ID, but the next two I always considered okay (as covered in my assumptions above). So I have had to whip through all my code and change occurrences like the 2nd & 3rd to

$theThingies = DataObject::get('Thingie','"SiteTree"."ParentID" = 0');
$thePages = DataObject::get('SiteTree','"SiteTree"."ParentID" = 0');

So go through any of your own code and check you always qualify your dB search strings. And use the double quotes ("Page"."Afield") so that the data query engine will properly automagic that into Page or Page_live as appropriate.

And, yes, if you like to use double quotes to start strings and delimit inside with single quotes that also means going through all that code and reversing the usage. E.g. "ParentID = ".$this->ID now has to be '"SiteTree"."ParentID"'.$this->ID. So the string is now delimited by ' so you can use " to wrap the table and field names. Of course you can always be a step better than me and stick to always double quotes but escape embedded ones.

Silverstripe people - was there a reason for this new field? And where does it come from? I've done a quick scan of code but cannot locate it. Fair enough that we should code to avoid ambiguity but why was a ParentID field needed in page the first place? Unless there is an intent to step above or abandon SiteTree? Not following development news I have no idea so feel free to tell me where to get off (O:

Pter

While I'm sure there will be some issues with upgrades my problem turns out to be caused by my approach to the module I was making - I extended the Hierarchy object then used add_extension in my module's _config.php to add to, e.g., Page.

Previous versions up to and including 2.4.0 didn't mind but, and I have to presume this is correct behaviour that was not being followed by previous versions, SS generates a linking ParentID variable for the extended class (e.g. Page.ParentID, BlogEntry.ParentID). Does not happen for SiteTree which already has a ParentID from including Hierarchy. I now try to find a different way to extend the Hierarchy object's stageChildren() function (in Yet Another Hide Pages In The CMS Module).