if you want to dynamically add a slug field to go with the browser field selection, you'll need JavaScript, yes. But again, i would really advise against trying to do this from the Twill UI. You can do it programmatically when Twill is saving instead, using afterSave in your module's repository class.

Ok, understood.

I have a Question: Is it possible, to use blocks outside of the block editor? I want a Page to have e specific block, once. Without the possibilty to add or remove it. Something like this:

@formFieldset(['id' => 'notes', 'title' => 'Notes']) @include('admin.blocks.stickyNotes') @endformFieldset

hi @Philipp Grimm not the way you describe but that would be a very cool feature, which I can see easily implemented in Twill now that we support multiple block editors. For now, you could extract your block fields in a partial that is both included from the block and from your page form, but you'll still have to save the fields in db columns on the pages table, or use a JSON field with the fieldsGroup feature. Does that make sense?

@User Makes sense, but I´m afraid, that block content wouldn´t work as expected in this case and there are also overlapping field names, so I would have to make name in the partial prefixable or overwriteable.

i see, yes, being able to just use an individual block would be nicer. We'll look into it!

Thank you, I´ll keep an eye on it 🙂

Something I've had in mind for some time is a

fixed

mode for the block editor, something like:

@formField('block_editor', [
    'fixed' => ['title', 'text', 'image', 'text', 'banner'],
])

This would initialize the block editor with a fixed selection of blocks that can't be changed or reordered. Of course, the fields would be editable 🙂

thats exactly what I need 😄

Hello everyone. Someone did the functionality (ui) of exporting data to csv from the crud module

My module is responsible for accepting applications from forms on the site. The client would like to output data to csv from a certain number.

Hello, first time using Twill and it's awesome CMS. What I cant find in the docs, is child list. Is it possible for block item to have children? For ex. Categories -> [TV, ....] -> [Samsung, LG, ASUS...]

Hi @kalle, glad to have you! In the context of blocks, that would be repeaters. You can add as many repeater field as you'd like in each block. Now, for your exemple use case, I'm not sure blocks make the most sense. You might be looking for nesting at the module level, see https://github.com/area17/twill/blob/2.x/docs/.sections/crud-modules.md#nested-modules.

Hi @Ivan Markov, usually that is something that is added as a custom action on the index page, next the the Add new button, routing to a controller that would download a generated file. I don't know that there's a ready made implementation for this out there yet, but would love to make that happen! We've been successfully using some Laravel packages that can export Eloquent models to CSV in the past.

Hey, I have looked in both of the repeaters and nesting modules. I think that repeaters are cool for me, since I only need dynamic child names so if Im able to achive this, that will be awesome. 😄 Thank you.

How can i store a Media with a custom upload form ?

Hmm what is qqfile and qqfilename ? 😄

hey @Rayderxx those are what fineuploader uses as payload

qqfile is the actual file and qqfilename, well, its filename

ok thx @User

Hi folks. I'm evaluating Twill for the next version of existing projects, one of them has thousands of pages. Some are based on ProcessWire and others on Statamic. One being multi language. After tweaking around Twill, my main question regards the Media Library: why does Twill not support folders on an S3 bucket, is it a limitation of the underlying library or a team decision? I know that we can use tags, but for thousands of images, this can be cumbersome for users. Is there a workaround? I have a bucket that has hundreds of folders and subfolders and I don't think it is a good idea to flat the structure. Thank you!

Hi @User, folders in the Media Library is probably in the top 3 most frequently asked features. It is definitely planned for 3.x, but the actual implementation is not yet defined. One possible approach would be to rework how tags are presented in the UI and allow for nested tags. I believe this would remain compatible with the current implementation and could be functionally equivalent to folders from the user perspective.

I'm curious to hear your thoughts on this! It sounds like you would prefer the Media Library folders to correspond to actual folders on the storage destination.

Hi @User! Indeed, my initial thought is for the media folders to correspond to the actual storage destination. To migrate existing projects to Twill I think this is a must have. I have a client whose website has been online since 2009, so its S3 bucket has a long "history" 🙂 For new projects, a nested tag solution like you mentioned could be the solution, yes, as visually they will be similar to folders.

Another idea, if I may, is to have the media being tagged with its parent ID, for instance, so one can go to a large media library and see only the media for that specific page/recipe/whatever in an easy way.

This is a very interesting topic as well! Currently, a media gets associated to a record via the

mediables

table, when it's picked from a

medias

form field. Also, a media can live in the Media Library, not attached to anything specific. I'm curious, how can this be improved for your specific use case?

Oh, I'm re-reading and I see that you would like some visual feedback in the Media Library. This would be great indeed and there's this PR that is a step in this direction: https://github.com/area17/twill/pull/1019

This PR looks excellent as it can be super helpful, especially for sensitive media use cases; for instance, a news site reporter/admin that receives an order to change a public figure photo on the entire website. She will be able to quickly go to the original parent and replace/remove the media from there.