Issue with translatable FileUpload field

[msrivela]

Package

filament/spatie-laravel-translatable-plugin

Package Version

v3.2.2

Laravel Version

v10.41.0

Livewire Version

No response

PHP Version

PHP 8.3.1

Problem description

Case 1: Creating new record issue

FileUpload field do not clear to upload translated image when switching locale

After filling both languages and saving, edit page will throw Filament\Forms\Components\BaseFileUpload::Filament\Forms\Components\{closure}(): Argument #1 ($file) must be of type string, array given (https://flareapp.io/share/OmV0Wvp7)

Case 2: Updating record issue

Editing a record with only one locale filled, then uploading image for second locale will throw No synthesizer found for key: "" (https://flareapp.io/share/NPLRBLo5)

Expected behavior

Case 1: Creating new record issue

While creating new record it's expected to clear FileUpload field when locale is changed After saving, it's expected to be able to edit the record

Case 2: Updating record issue

Image is expected to be uploaded when filling second locale

Steps to reproduce

Case 1: Creating new record issue

1. Click issues o menu
2. Click "New issue"
3. Fill "title" and "image"
4. Change language to spanish (image will not clear, will have to manually delete to upload new image)
5. Click "Create" button (error will throw after redirect to edit page)

Case 2: Updating record issue

1. Click issues o menu
2. Click "New issue"
3. Fill "title" and "image"
4. Click "Create" button
5. Change locale to spanish
6. Fill data (error will throw after image is uploaded)

Reproduction repository

https://github.com/msrivela/filament-issue-translatable

Relevant log output

No response

[github-actions[bot]]

Hey @msrivela! We're sorry to hear that you've hit this issue. 💛

However, it doesn't look like you've provided much information on how to replicate the issue. Please edit your original post with clear steps we need to take.

[github-actions[bot]]

Thank you for providing reproduction steps! Reopening the issue now.

[kamil-bartczak]

I have the same problem, any solution to this problem?

From my debugging, it appeared that in the database, the "main" language is stored correctly as an array [id => file_name], but it is this "extra" language that is stored as a string.

When debugging the package, I noticed that the "main" language from the "additional" language differs in that, before writing translations in the "additional" languages, the file writes in the form [id => Livewire\Features\SupportFileUploads\TemporaryUploadedFile], and the "main" language (which writes correctly) in the form [id => file_name].

[msrivela]

Unfortunately I don't have any workaround for the problem other than locking filament to version v3.0.75 when it worked. Please let me know if you figure something out.

[mybouhssina]

@kamil-bartczak @msrivela I think the problem is that the 'hydratestate' is not triggered in the handleRecordUpdate. go to Filament\Resources\Pages\ EditRecord \Concerns\Translatable method handleRecordUpdate and call $this->form->fill($this->data); before $this->form->validate(); Let me know if it solves your problem ! As a side note, If you guys are using this with Builders/Repeaters there is another problem with the ordering.

[msrivela]

@mybouhssina Sadly that solution did not work for me. I am in fact using inside a repeater in my project, but not in the reproduction repository.

[mybouhssina]

@msrivela I'm sorry to hear that, I think this issue might be related: https://github.com/filamentphp/filament/issues/11825

[bojmaliev]

I can confirm I have the same problem.

[Voltra]

See #11450

[mybouhssina]

@Voltra I've seen your solution but I think it doesn't take into consideration the dehydrate hook. Check my suggestion: https://github.com/filamentphp/filament/issues/11825

[Voltra]

That is quite possible since my test use case seemingly only use hydrated hooks. I'll check it out and adjust

[mrtawil]

+1

[Voltra]

The latest changes to the PR should get it to work

[Lucathiel]

Sticking to Filament 3.0.75 works, as mentioned by @msrivela

But for this to works in the latest version, i had to use both @mybouhssina and @Voltra workarounds. @Voltra solution fixing the lang switching on edit and @mybouhssina solution fixing the model saving issue.

[Voltra]

@Lucathiel The latest version of the PR should include the fix @mybouhssina proposed, was there anything else you added?

[mybouhssina]

as a side note, there is another problem I encountered while using Repeaters/Builders with this plugin. If my memory serves me well, it was whenever I switch language and save, the repeater/builder elements orders will change. From my understanding, it was due to saving the builder/repeaters in the old local data as objects with UUID keys and that JS doesn't guarantee the object properties order, so what I ended up doing is transforming these Objects to Arrays and the problem was solved, I can share the code if someone is interested.

[Voltra]

I did encounter a very similar problem with filament-navigation. That one was package specific, but maybe something similar is still in the core filament components. The fix is simply to use an array and to push items onto it (instead of adding a new key using a UUID).

The ordering not being preserved due to JSON objects being unordered key-value pairs, and going through many different layers of serialization and deserialization (e.g. app and DB have their own JSON engines).

That being said, it's not specific to this issue and possibly not to this (sub-)package.

[devmatheus]

Same problem here 👋

I've tried to apply the changes suggested on PR #11450 and worked well for updating. But for creating, when I try to change the language, the FileUpload component remains with the previous state: https://d.pr/v/kMz2bs

How did you solve this issue when creating?

[Voltra]

Oh... we hadn't, yet. It's the same fix, I'm adding it now.

[abdukhashimov]

Is there any workaround for current latest version?

[Voltra]

@abdukhashimov applying the patch derived from my PR should do the trick

[abdukhashimov]

I did the trick of creating a json file and tabs with field.lang I tried the patch, it raised me issues with disabled fields. Disabled field was not populated even though it was returned from DB.

[abdukhashimov]

I did the trick of creating a json file and tabs with field.lang I tried the patch, it raised me issues with disabled fields. Disabled field was not populated even though it was returned from DB.

The disabled field was quite basic: It was the combo of Title and slug

[mohammed9895]

I solved the problem with a walk around where I was using the latest version of filament which is 3.2.74, I solved it with downgrade filament version 3.1.8 and it work fine with me.

[atmonshi]

this also fixable with #11450 when using $this->form->getRawState() 👍

[danharrin]

I am posting this same message across all Spatie Translatable issues & PRs

Hey all! Wanted to update you on where we're at with the translatable plugin.

I really appreciate your patience while this issue has been active. While I created the plugin for the community, I've never actually had a project where I needed to use it, and that's the same for the rest of the Filament team. As such, it's the reason why the plugin hasn't had as much attention as the others, and is much more unstable: I just don't have the environment to test all the use cases, nor the motivation to make it truly great.

As such, I put out a post a month ago and asked who in the community uses the plugin and has knowledge of plugin development. Luckily, Lara Zeus and Mohamed Sabil stepped forward, who are both authors of popular Filament plugins and are trusted by the community.

We are strongly considering handing over maintenance of the plugin to those developers, for the good of the community. You can find their fork at https://github.com/lara-zeus/translatable.

Since the new developers have lots of experience with the plugin and active projects that use it, they should be able to help debug issues easier and make a much more stable experience for other users.

If their work goes well until v4 is released, we will likely retire the plugin at that point and recommend the fork as an official replacement. If it does not go as expected and the community is unhappy, then we will reconsider this decision. I am closing this for now, and if we decide to take maintenance back officially then we will probably reopen it.

The existing plugin will continue to receive security updates indefinitely. Please let me know if you have any further questions.

Many thanks, Dan

[atmonshi]

this an attempt to fix the issue if anyone willing to test this PR I would appreciate the feedback.