Oh, I think it works without the cast...

Then you would need to add a

json_decode()

in your field helper method.

Yep, but it's unfortunate you have to not use the standard Laravel cast mechanism for JSON columns... You either have to tweak the Front or Back use. I'll see if I can find some fix or alternative way

About the cast, we could add a check in

getFormFieldsHandleFieldsGroups()

function of the

HandleFieldsGroups

Trait:

public function getFormFieldsHandleFieldsGroups($object, $fields)
    {
        foreach ($this->fieldsGroup as $group => $groupFields) {
            if ($object->$group) {
                //// BEFORE
                $decoded_fields = json_decode($object->$group, true) ?? [];


                //// AFTER
                $casts = $object->getCasts();
                if (array_key_exists($group, $casts) && $casts[$group] === 'array') {
                    $decoded_fields = $object->$group;
                } else {
                    $decoded_fields = json_decode($object->$group, true) ?? [];
                }

                // In case that some field read the value through $item->$name
                foreach ($decoded_fields as $field_name => $field_value) {
                    $object->setAttribute($field_name, $field_value);
                }
                $fields = array_merge($fields, $decoded_fields);
            }
        }

        return $fields;
    }

Interesting! Yeah, I believe your fix and a standard helper at the model level could be a good, simple solution.

Yet, the mix of

$translatedAttributes

and translated JSON fields on the base model doesn't feel ideal. I wonder what are the challenges of introducing support for JSON fields at the translation model level...

I'll try to dig in the next days for the translated JSON fields as I have a basic working function (but coded directly in my Repository and not very clean 🙂 ) and I have to have this work for a project (even if workarounds are possible to avoid the problem)

JSON fields with HandleFieldsGroups Trait

Hey Guys, I’m starting off with my first twill poject and started with the tutorial. I created a model and a couple of elements in that model. Now I wanted to update an element… and Twill tells me: Your submission could not be processed. Where can I find a log that would tell me more of what’s going wrong?

Hi @how_else in your browser console as well as Laravel logs under

storage/logs

Perfect Thank you.

Is there a good example project or tutorial for how to nest repeaters outside of blocks? I see some commits indicating it should be possible, but can't seem to figure out exactly how to get it working properly...

Hi @User, the short answer is that nested repeaters outside the block editor don't work (yet). A workaround using the

HandleJsonRepeaters

trait was found in this issue: https://github.com/area17/twill/issues/1060#issuecomment-888062137

Hello, I'm new to twill, and I was wondering how would I retrieve the images saved inside the DB alongside the corresponding product it belongs to? I can't seem to figure out how the connections are being made. In order to simplify things, let's say I have a products table, and I have some media attached to it, how do I get the exact image attached to a certain ID via a RAW query?

Hi @Alexander, I'm not sure why you'd need a raw query, but still happy to answer:

select * from mediables where mediable_id = <your-product-id>

would give you rows that have the media id from the medias table as well as all the attachement information, like cropping values.

This is still unclear, what happens when I have more stuff other than products? How does mediable_id know which table it should target? For example if I have products, collections, posts tables, all of them have their own primary key, those keys will definitely have duplicate values, how does mediable_id act when both products and collections id is 1? @User

I assume that is equivalent to the primary key of my products table

this is a polymorphic table, so there is a

mediable_type

column, i omitted that condition for simplicity but honestly you shouldn't write raw queries for this

The thing is, I took over a project from someone else, the 'higher-ups' would like a list of all URLs related to images for certain products, that's why I need a raw query

i see. You should still be able to write an eloquent query, but i get your point

I just realized that

mediable_type

will be a hassle to work with, a lot of images are inside the

blocks

type and I'll be having issues narrowing it down to specific types of tables.

everything is connected so you can get what you need in a few queries. do you really need to write a single raw query? Why don't you write an artisan command? That way you can loop over results and throw more queries to find what you need. Blocks are also polymorphic, so you can get all the blocks for a product and then all the images for all blocks of that product. You have all the relations in place to get what you need.

Well, at first I thought that it would be doable with a single query because I'd like to avoid changing the file structure on the production environment, now I'm convinced that it won't be quite possible.

file structure on the prod environment? Do you mean deploying? you can also grab a database dump and do that locally then.

it's also doable with a few nested SQL queries if you really go that route

Yeah, there's quite a few things hanging in the deployment pipeline and it needs to be sorted out before the next deploy, so I would have to create the artisan command directly on the current release.

I guess that having a database dump is the best option

hey again, I'm struggling with browser field. Saving works correctly (changes are written to DB) but when I open again the edited entity, the browser field does not get filled with any value

I have one-to-one relationship between Microsite and Element The relationship is defined as: Microsite (has element_id FK column):

php
public function element()
{
    return $this->belongsTo(Element::class);
}

Element:

php
public function microsite()
{
    return $this->hasOne(Microsite::class);
}

In MicrositeRepository there is:

php
public function afterSave($object, $fields)
{
    $this->updateBrowser($object, $fields, 'element');
    parent::afterSave($object, $fields);
}

public function getFormFields($object)
{
    $fields = parent::getFormFields($object);
    $fields['browsers']['elements'] = $this->getFormFieldsForBrowser($object, 'elements');
    return $fields;
}

And in Microsite form.blade.php I have this:

@formField('browser', [
    'moduleName' => 'elements',
    'name' => 'elements',
    'label' => 'Element'
])

Basically

$this->getFormFieldsForBrowser($object, 'elements');

returns null