-
-
Notifications
You must be signed in to change notification settings - Fork 171
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
Include drafts in finding pages key recursively #6354
base: develop-minor
Are you sure you want to change the base?
Conversation
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.
Hm... There would suddenly no longer be a difference between HasChildren::find()
and HasChildren::findPageOrDraft()
anymore, right? I feel like there could be use cases where one would want to explicitly only find published pages. So this would be a breaking change and also one that wouldn't be intended I think.
Maybe we need to introduce a separate recursive finding mode that uses childrenAndDrafts()
. That could then be specifically used by HasChildren::findPageOrDraft()
, also allowing us to get rid of the separate search in both collections.
One way could be to have a new marker prop for Pages
that keeps track of whether the collection is children
, drafts
or childrenAndDrafts
. The same collection type would then be used in the findByKeyRecursive()
method.
94ea2a4
to
8960b69
Compare
@lukasbestle Revisiting this, I am wondering if we need to just adapt Because in general, I think this PR would be the more correct behavior: Drafts and pages can only have unique IDs. So when trying to access a page with a key-path, it's currently weird that we completely ignore a page (draft) that actually matches the specified path. And this is just because of its page status. This creates a greater separation between pages and drafts than there should be. Drafts shouldn't be automatically included when returning collections, e.g. to avoid putting them in templates while they're still drafts. But when we explicitly look them up with a key, it's weird that we ignore them so much and say "oh, well, you didn't explicitly ask for drafts" (as if drafts aren't pages, too). 😅 I'm totally happy to move this to v5 as breaking change. But I think it would be good to change this. |
This PR …
Let's think hard if this could cause any regressions or is a breaking change (not just fixing a bug).
Fixes
$site->findPageOrDraft() does not work for nested drafts #6339
Ready?
For review team