Did you move any of your navigation config to

AppServiceProvider

?

https://github.com/area17/twill/issues/757 I am running into this issue. Just creating a model from code. Any quick tips to fix this?

Was wondering, can it be that next update of Twill features Italian as official language on the settings?

Ok so this is resolvable by either marking it active or inactive ($model->active = true/false)

Hi!, I encountered a funny bug, I don't know if it's just me. Every time I save a modal with a date_picker field, it goes back 3 hours. For example, I save it as 11:00, it saves it as 08:00. Has anyone encountered this error?

sounds like timezones 😄

Yes, it seemed to me as well, but the timezone seems to be correct.

I think we are having the same problem. Is there a solution?

I don't think so without changing your app timezone to the one your users are on, which is obviously not great. We gotta fix this on Twill.

Currently my laravel app's timezone is Europe/Istanbul.

oh interesting, you did change it already

the recommendation is to always keep UTC in database

Yes, I changed it long ago because there were other operations related to date and time.

i see

Twill should be able to deal with both cases, we'll look into it

Okay, I guess I have no choice but to separate the date and time for now?

right

I don't understand why, but it was fixed when I deleted the datetime from the model cast 😄

@User, I'm still experimenting with this on my end (re. https://github.com/area17/twill/issues/745) but so far, one workaround to support non-UTC datetime is to override the

serializeDate()

method on the model :

protected function serializeDate(DateTimeInterface $date)
    {
       return $date->format('Y-m-d H:i:s');
    }

This will serialize the values without timezone information.

This is interesting. Without a cast, I believe the value from the DB (without timezone) makes it as a string to the frontend, never converted to a Carbon instance.

That's what I thought and checked it, but it works. Weird...

Yeah, I think the issue of datetimes being shifted a few hours on every save is caused by the datepicker component. As far as I can tell, it never returns values with timezone information, so when the app is configured to store datetimes in non-UTC, what happens is something like: - get the date from the DB - convert to UTC in Carbon instance internally - pass UTC-formatted string to the frontend - initialize the datepicker converting to browser's timezone - on save, get the value in browser's timezone, which is saved as is in the DB Anyway, very rough idea, I need to dig deeper. Let me know if you find anything that confirms or invalidates this 🙂

Of course, thank you for your help.

Inside config->twill.php I write twillTrans() to translate titles but I get Call to undefined function twillTrans.

'label' => twillTrans('block.select')

@User, yes the helpers are not yet available when the config files are handled. It's best to use

twillTrans()

in your

AppServiceProvider

Isn't there any other way because I would have to populate AppServiceProvider with any translation possible for the blocks. I have many of them.

I don't think I see a very clean way of doing this at the moment...

It's a bit hacky, but this might work :

php
    public function boot()
    {
        $blocks = collect(config('twill.block_editor.blocks'))
            ->map(function ($block) {
                $block['title'] = twillTrans($block['title']);
                return $block;
            })->all();

        config()->set('twill.block_editor.blocks', $blocks);
    }

If you write your blocks configuration like this :

php
return [
    'block_editor' => [
        'blocks' => [
            'banner' => [
                'title' => 'blocks.banner',
                'icon' => 'text',
                'component' => 'a17-block-banner',
            ],
        ],
    ],
    
    // ...
];

And add your translations to

resources/lang/x/blocks.php