Editing an ActionText field with Trix field separates captions from images.

1. Add an image
2. Click and change the caption
3. Save
4. Edit

In the trix edit view, the caption is rendered as regular text (a couple
line breaks and plain text). Saving the field causes that caption to become part of the body. Rendering the ActionText elsewhere also shows the text as part of the body - no longer attached to the image.

I think a helpful first step would be to ensure models using has_rich_text are added to the test suite and to the demo website. Currently the use of has_rich_text does not seem to be tested/demonstrated/documented anywhere. See issue.

I can also confirm that captions are broken as noted by @davekruse.

Should a separate issue be opened to fix the broken captions?

Yes, please open a new issue, but first, can you please test if a new app with Trix and AS works well and the captions aren't broken?

@adrianthedev your new demo app shows the issue:

• captions work with the Page resource which uses a plain-text column
• captions break with the Post resource which uses has_rich_text Action Text

I wrote on the previous PR that that will require us to digg in deeper for such an edge-case. Would you be able to sponsor that fix?

@adrianthedev could you please clarify what you mean by edge case? Maybe there is a misunderstanding. Using has_rich_text is to my knowledge the official way to use Action Text (and, by extension, Trix).

What I consider to be an edge (a.k.a unofficial) case is to use the Trix editor on top of a plain text DB column without using has_rich_text, as is currently done throughout the Avo documentation and demo code.

Currently I am trying to add Avo to a production system but in my free time, because it is just being evaluated; so in turn I am not able to sponsor a fix although I do try to support the project by documenting the issues found with reproduction steps.

I hope it's clearer this way. Although I can't sponsor I am happy to support the project in a more modest way and wish you much success.

Following you last comment I am talking about captions on attachments with has_rich_text.

What I mean by digging deeper is that we first need to see if they work on a regular Trix and Action Text setup.
It's not a given that the captions just work in a non-Avo setup. I found that out many times.
That takes time. We can't assign that time right now to this issue.

One thing that we'd love some help with and definitely could help faster is if we had that validation done by you (or someone else).
That means setting up a rails repo with action text and trix installed and try to see if the captions bug still manifests itself in that way.

Then, if we find out that it's an Avo bug, we can take action and try to fix it (ourselves, you, or together).

The reason why I'm saying it's an edgecase is that it works fine with a text DB column. Something is a bit off.

I sincerely appreciate you trying out Avo and insisting to add it to your infrastructure!
I really do!

Of course I'm not expecting you personally to sponsor this development. If that's the vibe I gave, I'm sorry.
I feel (and correct me if I'm wrong) that the company is getting a lot of value from using Avo.
It's not that out of place to sponsor something like that.

So, let's try to fix this together.
Would you be able to create that repo (or use https://github.com/avo-hq/trix-field-demo) to test out in a non-Avo environemtn if this is still happening?

Editing an ActionText field with Trix field separates captions from images.

1. Add an image
2. Click and change the caption
3. Save
4. Edit

In the trix edit view, the caption is rendered as regular text (a couple line breaks and plain text). Saving the field causes that caption to become part of the body. Rendering the ActionText elsewhere also shows the text as part of the body - no longer attached to the image.

This has been fixed with #2958

Hi everyone, I've been digging deeper into this issue and have done a lot of research in the Rails codebase. It seems Rails handles attachment uploads a bit differently. I’d like to contribute to resolving this issue.

Is there any particular reason why we shouldn't stick with Rails' direct upload solution for handling attachments? @adrianthedev , @Paul-Bob

I've initiated the solution mentioned above in this PR: #3609.

Hi @PedroAugustoRamalhoDuarte, thanks for looking into this.

Is there any particular reason why we shouldn't stick with Rails' direct upload solution for handling attachments?

One of the reasons that we handle the upload request on a custom controller is authorization.

It seems to me that all the issues mentioned in the original description have been resolved. What exactly are you trying to fix?

I just noticed that for creation we're not applying the authorization so using the solution from the PR shouldn't introduce any regression on creation. Is it possible to keep using the custom controller and redirect to the rails direct upload URL around here

@Paul-Bob Thanks for the fast response, i am having problem with the third one, i am attaching a pdf, but when i render this pdf the attachment is missing.