I don't see a problem with a media without a "parent" inside the library, sometimes this can be good. The issue begins when you have hundreds or more media and the user, for any reason, forgot to tag them when uploading. After a while, this can become a mess. 🙂

What about having a virtual folder structure mimicking the site structure by traversing the records relationships: - Case Studies (records parent table) - - Case title XYZ (35) (record title and how many media it has) Just an idea, I imagine that this can be difficult to implement.

It's a cool idea. I don't think it would be very complicated to implement. Not quite sure how modules could self-hook into this with the current architecture, but it's a good thing to keep in mind when we work on implementing more auto-discovery in Twill. There's a UI element to this which would require some design. 🙂

Is this your area code?

oops, sorry! I thought I was typing on search

No worries

Happy to help on the UI if needed. 🙂 But I'll need to understand Twill better of course.

Hi, any idea how to prevent repeater items from expanding (UI)? Right now when I load page in CMS, they are expanded by default.

hi @kalle they start collapsing on load automatically once you have more than 3.

Oh, so that's the case. But for less then 3 there is no provided configuration? Since content of items is a little bit 'ugly' for a normal manager and not needed.

Note: right now I have 5 of them, still expanded on a new load.

not at the moment, but that can definitely be added. you could try the collapsed fields util component for your use case: https://github.com/area17/twill/blob/2.x/views/partials/form/utils/_collapsed_fields.blade.php

hmm interesting. Is this a repeater outside of the block editor?

Outside.

ok, that behavior might only apply to blocks themselves and repeaters inside blocks, we'll check

I've got a problem with a WYSIWYG field not saving, even though the response from the server indicates success. It's a lot of content (13000+ words) and uses mediumText in the DB. Any ideas?

Is this a new field or an existing one with content already in the DB?

An existing one

Does it save with some records (e.g. shorter text), or none at all?

On my local/staging copies it does, yes. Can't test on production for obvious reasons 😉

Hehe. It's unlikely that you're hitting the limit of MEDIUMTEXT with 13k words... do you have inline images in the field as well?

Actually, I just tried copying in the content from prod to local and it doesn't save. Too long?

No- just text with some markup

Yes I would have thought there would be plenty of space for it

If you don't mind messing with your local DB, you could try altering the column to LONGTEXT.

I actually just went in and did a hot DB edit on prduction to get my change in 😱 Thanks, I'll try that when the pressure's off!

Personally I'd be surprised if that were the problem, but for now not to worry. Thanks again 👍

@sebastianlenton no error in console? It could be that the field is broken due to failing Quill mutations (known issue)

On page load I get "TypeError: undefined has no properties" (and then a load of stack trace type stuff) if that might be relevant?

As mentioned, on submit the server responds as though the save has been successful but nothing changes in the DB.