New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX only exclude SiteTree subclasses if there are any set. #60
FIX only exclude SiteTree subclasses if there are any set. #60
Conversation
I think we should make this PR for the SS3 compatible version and merge up. Have requested a review from @micmania1 for the logic |
We need to update the travis config - logged as #61 |
f88270b
to
a31bdc2
Compare
a31bdc2
to
dd99980
Compare
Okay, rebased off 1.3 branch instead. |
I think the check can just be added to the The reason being; it's a bit misleading when |
Thanks @micmania1
I considered this (after @robbieaverill suggested it too), but decided against. The single responsibility of shouldFilter() is "Checks if we're on a controller where we should filter". This additional check (::excludeSiteTreeClassNames()) mutates a DataList based on whether we shouldFilter() and if there any configured hidden subclasses (result of ::getExcludedSiteTreeClassNames()). Thus, implementing this on LumberJack::shouldFilter() would mean updating everywhere it's used (e.g. BlogFilter::stageChildren()), which doesn't necessarily care about hidden subclasses. Thoughts? |
I can see how it would affect blog. In that case could you just make the new method Could you also add further notes to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't do this in 1.3 any more, will need to go back to targetting master
LumberJack::liveChildren() and LumberJack::stageChildren() should check if count(LumberJack::getExcludedSiteTreeClassNames()) > 0 to avoid an
InvalidArgumentException
exception being thrown by DataList::exclude().