Localized text is not saving with lexical rich text editor and Postgres (payload and @payloadcms/* beta 10, next 14.2.0 stable)

[BohdanK-W32]

Text is not being saved when localized set to true.

/* payload.config.ts */

db: postgresAdapter({
    pool: {
      connectionString: process.env.DATABASE_URI,
    },
  }),
  editor: lexicalEditor({
    features: ({ defaultFeatures }) => [
      ...defaultFeatures,
      LinkFeature({ enabledCollections: [Collection.PAGES, Collection.POSTS] }),
      BlocksFeature({ blocks: [HRBlock] }),
      HTMLConverterFeature(),
    ],
  }),

/* Pages collection fields */

  fields: [
    title(),
    lastPublishedBy(),
    publishedAt(),
    {
      type: 'tabs',
      tabs: [
        {
          label: {
            en: 'Hero',
            uk: 'Головний блок',
          },
          fields: [hero()],
        },
        {
          label: {
            en: 'Content',
            uk: 'Контент',
          },
          fields: [...richTextAndHTML({ name: 'content', label: false, localized: true })],
        },
      ],
    },
    slug(),
  ],

/* rich text field functions */

import { RichTextField, TextField } from 'payload/types';
import { lexicalHTML } from '@payloadcms/richtext-lexical';

import deepMerge from '@cms/utils/deepMerge';

export const richText = ({ name, ...overrides }: Omit<RichTextField, 'type'>): RichTextField =>
  deepMerge(
    {
      name,
      type: 'richText',
      label: { en: 'Text', uk: 'Текст' },
    },
    overrides,
  );

export const richTextHTML = (name: string): TextField => lexicalHTML(name, { name: `${name}_html` });

export const richTextAndHTML = (data: Omit<RichTextField, 'type'>): [RichTextField, TextField] => [
  richText(data),
  richTextHTML(data.name),
];

Here you can see that richText without localization (hero.richText) and it's html field has data. But no data in localized (content field).

Update/create is successful, however (obviously) after page reload there is no data (as you can see above in the db tables)

[BohdanK-W32]

P.S.: Sorry for different ids on the screenshot from admin/API and db. Just dropped and seeded db to make sure it's not my local issue

Not sure if the issue present with mongo

[BohdanK-W32]

Reproduction vid (test with group, as you can see, it's not an issue with tabs structure):

Screencast from 2024-04-13 13-03-01.webm

[paulpopus]

Assigning to @AlessioGr but let me know if this is purely a postgres issue instead

[AlessioGr]

Good chance this is a lexical issue, yep! Lexical currently does not handle localization nicely, will work on that tomorrow

[BohdanK-W32]

Good chance this is a lexical issue, yep! Lexical currently does not handle localization nicely, will work on that tomorrow

Thanks!

[BohdanK-W32]

Hi, @AlessioGr! Any progress/ETA on the issue?

[AlessioGr]

Hey @BohdanK-W32

So Lexical does have issues with localized SUB-Fields. E.g. if you have a lexical blocks feature with localized fields, those are currently treated as if they are unlocalizd.

However, If the entire lexical editor is localized, that should work as expected! And I was not able to recreate your issue on either postgres or mongodb with a lexical field within a group within a tabs field.

Could you share a minimal reproduction repository with beta.14 of payload?

[BohdanK-W32]

Well, really interesting, I'll try to reproduce it today. Maybe it's fixed with beta.14

[BohdanK-W32]

@AlessioGr, sent you invite to the project repo with beta 14 setup. Here is the URL: https://github.com/zapal-tech/oycha-website

It has a .devcontainer setup with the PostgreSQL, MinIO (S3) server, Payload 3.0.0-beta.14, Next 14.2, so I think it will be good enough to reproduce it. Also, I'll push a valid .env file for local dev purposes to the repository

The easiest way to reproduce is to use the Pages collection (so page with slug test = localhost:3000/test and localhost:3000/en/test, Ukrainian locale is set as default FYI)

P.S.: Admin panel save a seed script feature. Just click the link/button "Seed your database" on the dashboard (/admin)

[giltine]

Hey @BohdanK-W32

So Lexical does have issues with localized SUB-Fields. E.g. if you have a lexical blocks feature with localized fields, those are currently treated as if they are unlocalizd.

However, If the entire lexical editor is localized, that should work as expected! And I was not able to recreate your issue on either postgres or mongodb with a lexical field within a group within a tabs field.

Could you share a minimal reproduction repository with beta.14 of payload?

Hey, Are there plans to change the localization behavior of localized sub-fields? Like if there is a block nested within a localized lexical editor, the text in editor and localized fields within the nested block would disappear on locale change and anything unlocalized would stay including the actual blocks. Would be amazing if this is possible.

[AlessioGr]

@AlessioGr, sent you invite to the project repo with beta 14 setup. Here is the URL: https://github.com/zapal-tech/oycha-website

It has a .devcontainer setup with the PostgreSQL, MinIO (S3) server, Payload 3.0.0-beta.14, Next 14.2, so I think it will be good enough to reproduce it. Also, I'll push a valid .env file for local dev purposes to the repository

The easiest way to reproduce is to use the Pages collection (so page with slug test = localhost:3000/test and localhost:3000/en/test, Ukrainian locale is set as default FYI)

P.S.: Admin panel save a seed script feature. Just click the link/button "Seed your database" on the dashboard (/admin)

@BohdanK-W32 the issue was that your richText editor did not have localized set to true: https://github.com/zapal-tech/oycha-website/blob/df5b71aba3d96bca82106fa59e6f47e38ace3623/src/cms/fields/hero.ts#L57

If you add localized: true here, it will work

[AlessioGr]

As for the issue showcased in your video, it also works as expected for me:

https://github.com/payloadcms/payload-3.0-demo/assets/70709113/bc2e0776-8751-4bda-9810-d7b33836cdff

[AlessioGr]

Hey, Are there plans to change the localization behavior of localized sub-fields? Like if there is a block nested within a localized lexical editor, the text in editor and localized fields within the nested block would disappear on locale change and anything unlocalized would stay including the actual blocks. Would be amazing if this is possible.

Hey @giltine if there is a localized block in a localized richtext editor, the block should always disappear when you switch locales, as the entire parent is localized.

If you have a localized block within an unlocalized richText editor though, I agree that should be localizable. I'm working on that right now, alongside full hooks support for lexical blocks

[BohdanK-W32]

@AlessioGr, ok, let's give it another try.

Here is the reproduction vid: Screencast from 2024-04-30 13-58-13.webm

Commit on main branch: 067ec8dee71ffb93545ccec00118eea429a5e070, it was used on the reproduction video.

hero (group) - localized: true hero.richText (lexical) - localized: undefined content (lexical) - localized: true

Payload version: beta 20

We removed lexicalHTML usage to reduce the scope of bug possibility. However, the bug itself is still existing, so it's not the problem with _html field.

Also, we checked content field state with the collection hooks, beforeChange shows the correct data, but the afterChange hook returns a document with content: null

Here are the hooks tested with:

P.S.: the last you tested was without localized because we commented it, so you checked the up-to-date commit, not the commit on the video.

[BohdanK-W32]

Also, after switching localized to false and back to true on the content field, API is not returning content field at all (this is not depends on the locale itself, seems it could be an issue with the db adapter).

And yeah, on the beta 20 we started receiving this message on the document change

[AlessioGr]

Fixed in #6489. Fields no longer get omitted from the API response. Proper localization support will be worked on soon

[github-actions[bot]]

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.