Unable to edit or create items for collections with translations

[HitomiTenshi]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

Since v9.5.2 (also in v9.6.0) you cannot edit or create new items for collections that have translations. I tested the issue with WYSIWYG fields, it might also affect other fields.

What happens is that directus preemptively makes a change for translations when entering the item page / creating a new item. This causes the save button the be active immediately upon entering an existing item. The pre-filled change for translations does not have the language ID in the object which causes the PATCH API to return status code 400 (bad request).

chrome_2022-03-07_12-25-43.mp4

When trying to create a new item, the WYSIWYG field says that it is required (it is, but I wrote something in it, so it should save).

chrome_2022-03-07_12-44-21.mp4

The issue happens because both the collection field and the translation field have the same name! That's pretty twisted... When I initially tested it I couldn't reproduce it until I named the WYSIWYG fields in both collections the same.

To Reproduce

1. Create a new collection
2. Add a WYSIWYG field and call it "text", make sure it's NOT NULL
3. Add a translations field
4. In the new translations collection, add a WYSIWYG field and call it "text", make sure it's NULL

Now try to create an item. Prepare to cry 😢

When there are existing items you will get the PATCH issue I showed in the first video.

The reasoning behind the main collection field being NOT NULL and the translations field allowing NULL is that the translated fields are optional. We have multiple translatable fields that do not have to be filled out and everything used to work in v9.5.1. We have downgraded to that version now.

Errors Shown

PATCH API shows status code 400.

During creation of new items the WYSIWYG fields complain about being required even though they have a value.

What version of Directus are you using?

9.6.0

What version of Node.js are you using?

16.14.0

What database are you using?

MariaDB 10.3.34

What browser are you using?

Chrome Latest

What operating system are you using?

Windows 10

How are you deploying Directus?

Ubuntu Server 20.04, npm installation with a systemd service running it

[iksent]

I have a similar problem. Can't understand, should I open a new issue or not.

1. I have Articles model and Translations for them.
2. Translations have Wysiwyg field.

• If I go to Article editing and try to edit Wysiwyg inside translations: it ignores changes and I can't save the Article.

2022-03-10.14.37.06.mov

• But if I go to Article Translations and try to edit Wysiwyg there, then it works:

2022-03-10.14.37.51.mov

I've tried both 9.5.2 and 9.6.0 :(

[rijkvanzanten]

I have a similar problem. Can't understand, should I open a new issue or not.

1. I have Articles model and Translations for them.
2. Translations have Wysiwyg field.

• If I go to Article editing and try to edit Wysiwyg inside translations: it ignores changes and I can't save the Article.

2022-03-10.14.37.06.mov

• But if I go to Article Translations and try to edit Wysiwyg there, then it works:

2022-03-10.14.37.51.mov

I've tried both 9.5.2 and 9.6.0 :(

Very odd! I'm wondering if that's a bug in the translations interface (which would make it related to this), or a bug in the wysiwyg 🤔

[onordgren]

I have a similar problem. Can't understand, should I open a new issue or not.

1. I have Articles model and Translations for them.
2. Translations have Wysiwyg field.

• If I go to Article editing and try to edit Wysiwyg inside translations: it ignores changes and I can't save the Article.

2022-03-10.14.37.06.mov

• But if I go to Article Translations and try to edit Wysiwyg there, then it works:

2022-03-10.14.37.51.mov
I've tried both 9.5.2 and 9.6.0 :(

Very odd! I'm wondering if that's a bug in the translations interface (which would make it related to this), or a bug in the wysiwyg 🤔

I also have this issue and I tried replacing the wysiwyg with a markdown editor on the main objects and then it works fine.

[onordgren]

@rijkvanzanten I did some more testing on this one and got the following "results":

Baseline: collection faq with the wysiwyg field called answer

I add a translations interface to faq with a child wysiwyg field called answer

• When I try to create a new faq the answer wysiwyg will not set the value of the field rendering the field invalid if it's required or empty if not
• If I set the value with set raw value it works
• If I change the name of the field to something else it will work, i.e. not colliding with the field on the translations relation
• If I use a markdown field instead of wysiwyg it works

So to me it feels like something is happening client side in the wysiwyg when it tries to set the actual value of the field. Maybe there's a conflict with the field with the same name on the translations relation?

[onordgren]

@rijkvanzanten I did some more testing on this one and got the following "results":

Baseline: collection faq with the wysiwyg field called answer

I add a translations interface to faq with a child wysiwyg field called answer

• When I try to create a new faq the answer wysiwyg will not set the value of the field rendering the field invalid if it's required or empty if not
• If I set the value with set raw value it works
• If I change the name of the field to something else it will work, i.e. not colliding with the field on the translations relation
• If I use a markdown field instead of wysiwyg it works

So to me it feels like something is happening client side in the wysiwyg when it tries to set the actual value of the field. Maybe there's a conflict with the field with the same name on the translations relation?

Maybe related to b3f7bd9

[maltejur]

Maybe related to b3f7bd9

Reverting that commit does indeed seem to fix the issue https://github.com/maltejur/directus/tree/revert_b3f7bd9
Edit: I am dumb, even without that commit reverted everything works just fine for me.

I think this whole issue was fixed in #12216. If I revert that merge commit the issue occurs again.

[onordgren]

This has been resolved for me with 9.7.0!

[HitomiTenshi]

I can confirm what @onordgren and @maltejur have already said. The issue has been fixed in 9.7.0. It seems by PR #12216 with the last change "Fix incorrect DOM selection of WYSIWYG interface for fields having the same name".