search

payloadcms / payload

Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a headless CMS or for building powerful applications.
https://payloadcms.com
MIT License
25.72k stars 1.64k forks source link

Live preview does not correctly find relations when using blocks inside the lexical rte. #5285

Open stefvw93 opened 8 months ago

stefvw93 commented 8 months ago

Link to reproduction

No response

Describe the Bug

The following line in the rich text traverser detects relations based on the relationTo and value fields inside any given iterated object in a rich text tree: https://github.com/payloadcms/payload/blob/c038acb3a4da6cda85d034aeb8b042d172ee868f/packages/live-preview/src/traverseRichText.ts#L59

However, when using the blocks feature in the lexical rte, relationships are not defined by those fields, and instead simply hold an id string reference field.

Because of this, the rich text traverser is never able to resolve relation fields inside blocks.

To Reproduce

  1. Enable lexical editor field on some collection.
  2. Use the Blocks feature
  3. Create a block with a type: 'relation' field, with a relationTo some other collection.
  4. Populate the field in the admin UI
  5. Implement the live preview feature, set depth > 0
  6. Check the data returned from the callback function
  7. The relation field in the respective block will always just havr a <fieldname>: <id> entry, regardless of the depth parameter.

Payload Version

2.11.2

Adapters and Plugins

@payloadcms/live-preview@0.2.0

100tomtomas100 commented 6 months ago

Hey

Any news on the solution for this problem ?

abaco commented 3 months ago

I've found a workaround for this. Just set relationTo to an array, even if you only need to reference a single collection, like relationTo: ['images'] instead of relationTo: 'images'.

In this way the resulting field values will have the form of { relationTo: <collection-slug>, value: <resolved-document> }, which is resolved correctly by traverseRichText.