You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a page with three "lumberjacked" allowed children (pages we want to manage through lumberjack) and one non-lumberjacked allowed child (one that we want to see in the sitetree).
All works great, except when we create a new one of the lumberjack children and select the first item then it creates the non-lumberjacked one instead as this is the default child (see SiteTree). Not that we have set it as the default child, as such, but SiteTree::DefaultChild simply selects the first allowed child if there is no DefaultChild.
We fixed this by setting the default child for the parent page to be the first item on the list of lumberjacked children.
Note that it seems to work fine until you do the actual creation. it is only at that moment that you end up creating the wrong child (the non-lumberjacked allowed child - not the first lumberjacked child).
How to reproduce
(see description)
Possible Solution
We should take the first Default Child that is lumberjacked. Not just the default child.
Additional Context
No response
Validations
Check that there isn't already an issue that reports the same bug
Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)
The text was updated successfully, but these errors were encountered:
Module version(s) affected
3.1.2
Description
We have a page with three "lumberjacked" allowed children (pages we want to manage through lumberjack) and one non-lumberjacked allowed child (one that we want to see in the sitetree).
All works great, except when we create a new one of the lumberjack children and select the first item then it creates the non-lumberjacked one instead as this is the default child (see SiteTree). Not that we have set it as the default child, as such, but SiteTree::DefaultChild simply selects the first allowed child if there is no DefaultChild.
We fixed this by setting the default child for the parent page to be the first item on the list of lumberjacked children.
Note that it seems to work fine until you do the actual creation. it is only at that moment that you end up creating the wrong child (the non-lumberjacked allowed child - not the first lumberjacked child).
How to reproduce
(see description)
Possible Solution
We should take the first Default Child that is lumberjacked. Not just the default child.
Additional Context
No response
Validations
silverstripe/installer
(with any code examples you've provided)The text was updated successfully, but these errors were encountered: