Skip to content
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

plugin-nested-docs: Parent slug update does not cascade to published child documents when child has pending changes #10066

Open
Collexi-Dev opened this issue Dec 19, 2024 · 0 comments
Assignees

Comments

@Collexi-Dev
Copy link

Collexi-Dev commented Dec 19, 2024

Describe the Bug

Description:

In the Nested Docs Plugin, the resaveChildren hook is intended to cascade changes to child documents when a parent document is updated. However, the expected flow, in my opinion, is incomplete:

  • When a parent document's slug is updated and published, the changes cascade only to the draft version of child documents, leaving the published child documents unchanged.
  • This behavior can result in broken links or outdated breadcrumbs in published child documents until the draft is manually published.

Additionally, the draft parameter passed to the resave function within the resaveChildren hook is unused due to this recent commit 50e7c24b, leading to duplicate calls and redundant logic.

Expected Behavior:

When a parent document's slug is updated:

  • The published child document should be updated to reflect the new parent slug and maintain live content consistency.
  • If a child draft exists, it should also be updated while preserving the draft's unpublished state.

If this is not the expected behavior, the resaveChildren hook and associated logic should be updated to clearly reflect this design decision, removing unused parameters and redundant code.

Current Behavior:

  • The resaveChildren calls the resave function with both draft: true and draft: false (if the doc is published) but the parameter is no longer used, causing the draft child documents to be updated while leaving the published child documents unchanged.

Proposed Solution:

Update the resave function logic to handle both draft and published child documents explicitly:

  • Update the published child document when the parent is published.
  • Update the draft child document (if it exists) without affecting its draft state.

Link to the code that reproduces this issue

This repo is just the Payload template, no mentionable changes except adding the pages collection to the nested docs config.

https://github.com/Collexi-Dev/test-payload-3-stable

Reproduction Steps

  1. Create a parent and child document,
  2. Publish the parent and child documents. ,
  3. Make changes to the child document and save it as a draft,
  4. Update the slug of the parent document and publish it,
  5. Observe that:
    • The draft of the child document is updated to reflect the parent’s new slug.
    • The published child document retains the old slug, resulting in broken links or outdated breadcrumbs.

Which area(s) are affected? (Select all that apply)

plugin: nested-docs

Environment Info

Binaries:
  Node: 20.13.1
  npm: 10.5.2
  Yarn: 1.22.22
  pnpm: 9.12.2
Relevant Packages:
  payload: 3.9.0
  next: 15.0.0
  @payloadcms/db-mongodb: 3.9.0
  @payloadcms/email-nodemailer: 3.9.0
  @payloadcms/graphql: 3.9.0
  @payloadcms/live-preview: 3.9.0
  @payloadcms/live-preview-react: 3.9.0
  @payloadcms/next/utilities: 3.9.0
  @payloadcms/payload-cloud: 3.9.0
  @payloadcms/plugin-form-builder: 3.9.0
  @payloadcms/plugin-nested-docs: 3.9.0
  @payloadcms/plugin-redirects: 3.9.0
  @payloadcms/plugin-search: 3.9.0
  @payloadcms/plugin-seo: 3.9.0
  @payloadcms/richtext-lexical: 3.9.0
  @payloadcms/translations: 3.9.0
  @payloadcms/ui/shared: 3.9.0
  react: 19.0.0-rc-65a56d0e-20241020
  react-dom: 19.0.0-rc-65a56d0e-20241020
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:52:41 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6031
  Available memory (MB): 36864
  Available CPU cores: 14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants