sometimes, because of invisible characters in your content, quill fails to load it

there are a couple of issues mentioning this on github

we have already filled most of the site with content. And after a while, some blocks started to fail. Every problem block will hurt

@User found unused html tags. It worked without them. I think that they inserted content from a third-party resource

@User , it's important to sanitize pasted code to Quill fields, as Microsoft Word or any other editor can generate non-printable chars that will break Quill, as ifox said.

exactly, it usually comes from pasting from somewhere else. This is something we don't have much control over unfortunately. We need to look into that fix @antonioribeiro found a few months ago in another repo that uses quill. tbh I'm a bit on the fence about investing more on quill customization as it does not seem maintained anymore. https://github.com/quilljs/quill/issues/3359

twill also supports Tiptap, which is well maintained

@User have you considered using ckeditor?

or tinymce?

definitely something I've been thinking of, yes, and I know some twill users do use them using a custom field.

Is it possible to translate the the field names themselves depending on what language the user has in his profile?

Hi everyone! I'm in the process to change my deployment pipeline to build a docker image shipping our CMS. It was all working fine, but now I've moved from apache2 to nginx + fpm (bear with me, it is actually a Twill related question!). All seems to be working fine everywhere, except for admin pages that include files from

partials\form

. It looks to me as the names are not properly resolved for some reason. On my local, the partial it's actually trying to load is

twill::partials.form._checkbox (\vendor\area17\twill\views\partials\form\_checkbox.blade.php)

. It must be some kind of messed up environment variable, but if anyone had an idea on where to investigate, it would be greatly appreciated! Thanks!

I came across this error the other day, and for me it was a missing bracket on an input field definition that caused it. Is the same view definitely working locally? even if you clear the view cache?

Ah interesting, I will double check. But yes, it is working locally. It's also not working for forms build by Twill as in the attached screenshot. Though I could try to clear the view cache during the build process, thanks for the hint

yes, you have access to all Laravel features, so you can use localization on the field labels. you will need to use the

twillTrans

helper though if you'd like to automatically use your CMS user selected language

Hi there! strangely it doesn't seem to look for

_checkbox

but just

_

That's what got me confused too.. I'm trying to caching the views during the startup process, see if it fixes it (we were doing it before too)

Right, that didn't solve it...

Great thanks!

You're awesome

Hi @User , I'm curious to know if you have published Twill views at any point? (ie.

php artisan vendor:publish

)

An extension is only as great as its community of maintainers

Hi! I've never done it as part of the container build process.

Yeah it works great! But is it possible to translate the twill-navigation.php

That didn't work either by the way... I'm really out of ideas.

@User Yeah, I must admit I'm also out of ideas... I did a quick test here and could not replicate the issue. I don't see a reason for

_

instead of

_checkbox

at a glance in the code...

Not sure if it's at all related to the containerization... can you share a bit more on the differences with your local environment, if any?

Also, if possible — can you share your

form.blade.php

, just as a sanity check?

it is possible, by dynamically setting up the configuration from code, in a Laravel service provider. That way you can call trans helpers.

Do you have any recommendations for any blade formatters that work decently with directives like the ones with @formField?