Twill

`'bind_exception_handler' => false, ` does not fix it.

thanks for the details, 2.5.1 will be coming up shortly to fix this

awesome. ty looking forward to the multiple edtior_blocks. 🥳

<@!170475091711361024> I can reproduce, this is affecting users extending Twill's exception handler. Are you calling anything from it in your extended handler?

<@!479379745856028705> https://pastebin.com/jvjn6j7W

just had a call with <@!775689710198325268>, we're on it <@!170475091711361024>

Hi. please tell me how in 'area-17/twill-image' i can display images (in sources) with different Device pixel ratio

<@!195245843161415680> Twill Image is using width descriptors, which is a better approach to let the browser pick the best resolution

> Instead of supplying fixed image sizes and densities, the size of each supplied image can be specified by adding a width descriptor along with the size of the image element, allowing the browser to automatically calculate the effective pixel density and choose the best image to download.

so the idea is that you should provide the largest width you'd like to support in your preset. So if you were to use a 1500px image at 2x, use a 3000px width in your preset instead, and the browser will pick that one if on a 2x screen if the image intrinsic size is at 1500px.

that way a 3x device will also be able to pick from your list of width, instead of forcing a width at each DPR

I'm still seeing some issues in 2.5 with the BelongsTo browser and restoring revisions - i'm no longer getting an error, but old relationships are not being restored in my case

<@!413829252836884480> I did some quick tests locally and I am unable to reproduce this issue. I revisited your instructions in the original issue: https://github.com/area17/twill/issues/1082#issue-965111153

Is there anything that has changed in your setup?

Hi <@!553620329453584414> - not as far as i'm aware - i'm seeing this with some more complex models, so i will  follow my own instructions and see if its present on the stripped back case

Ok great! I'll keep testing on my end too

Thanks! Will let you know what i find shortly

Ah - I'm sorry - i was mistaken. I'm actually seeing the issue with a browser powered by a BelongsToMany relationship!

That's great! Ok, so I'll keep testing with BelongsToMany

BTW, support for inverse browsers (e.g. from Owner to Item) was introduced in 2.5 as well, curious to know if you have tested it! 🙂

That's so cool - really loved the idea of being able to edit these relationships from either side. TBH it was something i always wished for in Craft which i have been using previously

I just realized — I think this is effectively the same issue as what was reported yesterday with HasRelated browsers :
https://github.com/area17/twill/issues/1117

which is implemented via ManyToMany

Hey, still here, making progress 🙂
So, I _think_ you could refactor your belongsToMany browser to be declared via the `$browsers` prop, and this would fix your revisions issue. ie:
```
class OwnerRepository extends ModuleRepository
{
    ...

    /**
     * Your belongsToMany can be added here:
     */
    protected $browsers = ['things'];

    /**
     * Instead of all this:
     */
    # public function afterSave($object, $fields)
    # {
    #     $this->updateBrowser($object, $fields, 'things');
    #     parent::afterSave($object, $fields);
    # }
    #
    # public function getFormFields($object)
    # {
    #     $fields = parent::getFormFields($object);
    #     $fields['browsers']['things'] = $this->getFormFieldsForBrowser($object, 'things');
    #     return $fields;
    # }
}
```

Hi again - I've tried this and it works perfectly! Everything updating correctly, and the revision restoration works great too 🙂

That's great <@!413829252836884480> ! Thanks a lot for the feedback.

Hey <@413829252836884480>, I'll look into this!

might be stuff in my implementation, potentially!

<@!170475091711361024> https://github.com/area17/twill/releases/tag/2.5.1

i will give it a try and report back to you

<@!479379745856028705> looking good. composer update did pass with no errors this time. you guys are awesome.

https://github.com/area17/twill/pull/918 does break all of our block_editors. as `window['{{ config('twill.js_namespace') }}'].STORE.form.availableBlocks` is undefined when the `views/partials/form/_block_editor.blade.php:18` tries to push blocks into it  ` window['{{ config('twill.js_namespace') }}'].STORE.form.availableBlocks['{{ $name }}'] = {!! json_encode(array_values($allowedBlocks)) !!}`

<@170475091711361024> do you have a custom _block_editor view in your project?

ok. anything custom I need to be aware of to reproduce this? did you make sure to update your Twill frontend assets?

Did you override Twill's form layout? https://github.com/area17/twill/blob/93e665ef169c6333bff91c5aa7fa64b894baa8d5/views/layouts/form.blade.php#L127

if i change line 127->128 
from: 
```availableBlocks: {},
blocks: {},```
to: 
```
availableBlocks: [],
blocks: [],
``` 
Everything works just fine.

i got it working by deleting everything other than the index.php in my public folder.