Problem with the new initializeHasTranslations function on Backpack for Laravel

[bedoz]

Hello everyone, I did a composer update on my project with Backpack for Laravel and this package, the result is that I can no longer save any translations, for some reason the initializeHasTranslations function that casts all the translations to an array at the init of the Model is conflicting with the BackpackForLaravel library. At the moment I have overwritten the function by extending that class and disabling the merge of the casts, but it would be necessary to understand with them what is not working. I will try to report the same ticket on the package hoping to have support in one of the two packages.

For any further information, please feel free to contact me.

Thank you very much
Alex

[thaqebon]

Hi @bedoz,
Please update to version 6.10.2. It should fix the casting issue.

[bedoz]

Hi @thaqebon,
thank you for your quick reply, unfortunately the problem is still present, the installed version was already 6.10.2.
The problem seems to be linked to the fact that when casting to array the translation expects an array as input during saving but only the string in the language currently used arrives, this inside backpack.
I have already opened a ticket also in the backpack package asking for support also in their package.

ticket on backpack package is here: Laravel-Backpack/CRUD#5767

Thank you so much.
Alex

[mrinaldidfs]

Hi @thaqebon
I have the same problem as @bedoz and I solved it by downgrading to version 6.9.3.
Even in my case the problem arises when saving the form developed with "backpack for laravel".

[bedoz]

Guys, @tabacitu replied to me in other issue ticket. And they are working on it. Please also refer to Laravel-Backpack/CRUD#5767 (comment)

[pxpm]

Hey @bedoz and @mrinaldidfs thanks for reporting in. 🙏

I was trying to come with a solution that wasn't a Breaking Change, because the behavior of this package (spatie/laravel-translatable), changed when initializeTranslatableTrait() was introduced.

Previously the casts would only be available for developers when we called getCasts(), after this change the casts are "forced" into the model, and broke our functionality that was not expecting to have the translatable columns automatically casted on the model.

This has other issues, for example if you have in your model cast like 'translatableColumn' => 'json', it will now be automatically converted to translatableColumn => array, so it removed the possibility for you (developer) to cast the column to whatever you want.

For me I would consider it a breaking change, but I accept that there are different opinions than mine.

I've spent already too much time on this, so I've just merged a "workaround" in our package (Backpack).

Please feel free to close this issue 👍

[thaqebon]

@bedoz, forget about casting during initialization; there's nothing wrong with it. It’s essentially the same as manually adding casting attributes to the $casts array in the model class.

Could you please describe your issue in detail? Specifically, what actions you're taking, what results you're getting, and what you expect to happen?

[pxpm]

@bedoz, forget about casting during initialization; there's nothing wrong with it. It’s essentially the same as manually adding casting attributes to the $casts array in the model class.

Exactly what I said. Previously there were no casts upon model initialization (unless you manually added them), and now there are. 👍 You can easily test that by doing a new TranslatableModel() in 6.9.3 vs 6.10.2. (There is nothing wrong having casts in the model per se, but if you didn't had the casts before, and now you have, that's a change ... do we agree on that?)

You can also test that if you set your cast in the model to attribute => json (or a custom cast for example), after your PR, it will now be attribute => array without possibility to change.

We had code in place that specifically checked for the presence of the cast, we didn't used the cast on purpose because our use case is not only a simple translatable column, but it's an aggregate of features that also has the translatable support.

I was just explaining @bedoz the root cause for the issue he reported here and in Backpack repository, so please if you don't have anything new to add, refrain from telling the guy that everything is good without the proper knowledge.

Cheers

[thaqebon]

@pxpm, please note that json and array casting have identical effects. If you want to change the casts for translatable attributes, you can override the getCasts() method. However, I recommend using mutators for better flexibility.