yes

can you share the rest of the error? in which table is it looking for that column?

hmm ok. Do you see that column in the database?

ok, nevermind.. i forgot add this columns to model in translatedAtt

Hello, I've upgraded my Twill site from 1.2.2 to 2.4 and seem to have a problem. On one of my module edit screens, if I save the existing modules blocks it fails with the following error in the browser console:

message: "Undefined index: endpointType", exception: "ErrorException", file: "/Users/sebastianlenton/Sites/order/vendor/area17/twill/src/Models/Behaviors/HasRelated.php"

(can provide more if it helps). But if I delete them all and add some new ones with the same content, it saves successfully- any ideas? am I missing something obvious here? 🙂

Hey @User , is this something you can repeat? You get the error every time you try to update any existing record from that module?

Yes.

And you also get the error when creating new records?

I might not have said the right thing actually- I'm talking about a load of blocks on an edit screen.

If I start from what was there before I upgraded, and add new ones, it errors.

If I delete some and add a new one it errors also. But if I delete all of them and add a new one it succeeds

I see, thanks for clarifying. Out of curiosity, what type of fields are in your blocks?

hey @sebastianlenton nice to see you here!

Thanks, wasn't sure where else to turn! 😅

Sebastian is a Twill OG

You were one of the first users outside of A17 like 3-4 years ago now

All sorts of fields but they do all have browsers in actually

yeah it's a browser thing

@ifox you probably know which site I'm working on... 🙂

Cool, that was my next question 😄

in twill 1 browsers were saved in the blocks content json

you might need to write a small data migration on blocks that include a browser field. i can look into this closer later today.

That would be brilliant, thanks!

@ifox @pboivin looks like I've managed to fix it! I didn't spot the

related

table before- I had a look and wrote a crummy little script to MacGyver the data in. 😂 All saving now- thanks very much for your help, both!

Awesome! I'm curious to know about your script, I have a passion for crummy little ones 🙂

Too embarrased to tell you! 😅 Wasn't sure how to do it using a migration or whatever so grabbed the data using the DB facade- executed it in Tinker...

Oh yeah, love it! I can't count the times I've used Tinker to quickly seed/transfer data over...

Hi, I wanna share something about twill handling repeaters. When I read the function in Repositories\Behaviors\updateRepeater(), it automatically defined the foreign key as {relation_column_name}_id and the function coming from getForeignKey(). So due to I've my own standard about databases foreign key name, When I tried to save using updateRepeater, it shows Error on Submission. Then my solution is to set a custom updateRepeater's function in each my repositories to use custom foreign key name instead using predefined getForeignKey(). Maybe do you have any better idea? Or maybe twill would like to consider this method as new update? So we can set our custom foreign key name on function parameter?

interesting, thanks for sharing. First you can create yourself a trait or parent class to avoid putting your custom update repeater in every repository. What about directly updating getForeignKey on your models?

afaik the datepicker in Twill doesn't mention a blocked dates option