Thanks to Willr answer is...

"Well you shouldn't extend Hierarchy from hidepages. Pages will already have Hierarchy applied to them (well SiteTrees) so you're applying Hierarchy to both the SiteTree and the Page which is giving you the multiple IDs"

...which sort of poots the whole thing unless there is another way to override stageChildren in the Hierarchy class via some sort of soft extension. Which also means v0.27 should be fine up to 2.4.0 (but v0.28 will also do the job). Odd that it didn't fail until 2.4.2.

Pter - did you try applying the extension to SiteTree rather than page. Then duplicate columns won't be added as the extension is already loaded.

Well this is a popular topic all over the forums in different shapes and forms (O: Maybe it needs to be gathered in one place somehow as there are some neat looking methods and approaches out there. Anyway...

Yes Willr I did try applying to SiteTree with this outcome

1. Using add_extension(SiteTree,'HidePages') in the HidePages _config.php certainly did not spawn extra ParentIDs or crash anything BUT it did not use the alternate stagedChildren() function (verified by echoing an HTML comment and viewing page source).

2. Hacking (yay) the SiteTree.php to add 'HidePages' to the list in $extensions does work but is not desired as it is a core hack and not a polite overlay.

Unless there is another way to override this function I will continue on with investigating the rumors of an augmentedStageChildren function that may be worth a look.

However if you want to use the existing v0.27 module then this will work with 2.4.2 (and modified to have 'Peers' tab for child's list of parent's other children) following the instructions in INSTALLING.

Thanks to Willr for his time - I'm sure he has plenty of better things to do.

[[ V0.30 IN LATER POST. I'M LEAVING 0.27 HERE IN CASE SOMEONE WANTS THE BROKEN VERSION FOR ALTERNATE APPROACH OR MAKING IT WORK ]]

Adding $extensions = array('HidePages') to the $extraStatics array in the HidePages_Decorator that is applied to SiteTree did not activate it either (using activate as, at this point, nothing Bad is happening) so still going with the hack above.

Schweet... getting there and much leaner (code, not me)

Righty ho! Thanks to TotalNet's (http://www.silverstripe.org/blog-module-forum/show/290971?start=0#post292281) use of something I will not pretend to completely understand (augmentStageChildren) but which is called once it is ready to go it is easy enough to prune children out. Yeah they've already done it but I liked my child tabs and other options, not to mention I have also added the feature NOT to prune those with hidepages set so you can use it to tidy a tree. For example you can have a major page with hidepages set and few under it with hidepages also set and they will show. Any gaps (hide -> no hide -> hide) won't show the 3rd level as, well, the 2nd won't show up.

Not sure if this is a better approach... ideally you'd want to reduce server load and prune children at load time so there isn't even really a dB hit but this works fine enough on the supplied list of stageChildren (which I presume will involve server load) and integrates via a pure DataObjectDecorator (so now only the one class).

I'm not abandoning the original messy code as if I can make a better way I will but this works.

[[ FILE REMOVED - LATER VERSION WITH FIX BELOW ]]

Pter

*sigh* Okay, that doesn't help - also hides the pages from the web site menu so I'll have to add a check on if in CMS or not.

Anyone know the proper way to check if you are in the CMS or displaying a web page?

At present the fix is simple - check to see if the classname of the current page returned by Director exists. It works to prove the point but is based on an undocumented feature. However if I can find out the correct test the switch is painless.

[[ FILE REMOVED LATER VERSION WITH SORT OF BETTER WHER AM I CHECK BELOW ]]