Hi! First of all thanks for the PR :)
Just a doubt, does this work by adding it with a base64 encoding or by hotlinking (putting an external URL)?

Related to #2118 and #1266

It uses quillEditor's standard plugin. It embeds the image with a base64 encoding, so it is easier to use as it is not needed to have access to an FTP server to upload images.

I see the good point with base64 (not configuring anything on the server), but for several reasons I don't like the base64 solution:

• Performance (is heavier than putting the image)
• Caching (it's more difficult to cache, ie doesn't work with a CDN)

More information:

• https://stackoverflow.com/questions/11736159/advantages-and-disadvantages-of-using-base64-encoded-images
• https://www.davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

Please give feedback @decidim/developers

I agree with @andreslucena, but the main advantage is that it is completely transparent to the user. As an example, in most of our instances we cannot ask the user to upload the picture to a webserver, as they don't even have a webserver available to host them. Of course, it would be a better solution to give the user the chance to choose between a linked and an attached image... Maybe we could add it to the editor gem...

I personally think there should only be one and only one way to add photos, not two alternatives.

But I agree that this is better than nothing until we will have a solution that uploads the images to a file store through Decidim. Most of the infrastructure is in place already, but it would need integration with the editor which I guess is a bigger job.

Active Storage would by the way provide a way to upload images "on the fly" to the server without any extra coding. It has been suggested here: #1971

I'm waiting for Rails 6 release, which will include ActionText:

https://github.com/rails/actiontext

We'd need to change the editor from Quill.js to Trix, and move our Attachments to ActiveStorage, but it would solve our needs.

Here's a video of @dhh showcasing ActionText:

https://www.youtube.com/watch?v=HJZ9TnKrt7Q&feature=youtu.be

@mrcasals ActionText will be great but I guess it's still a long way ahead before a stable version of Rails 6 is released. Much before that people need to add images on Decidim's content pages, we've had these requests from many Decidim users and instructed them a way to bypass the problem.

I'd say adding images is pretty standard basic need for any system that manages content.

How we've bypassed it for now, as many of the admin users we've encountered had really need this feature badly:

• Create a "hidden" (unpublished) process
• Add the images as attachments to that process
• Copy the images' public URLs
• Use the "video" button to add the images to the page as an iframe

But this is even worse (style and performance wise) than base64 images embedded onto the page.

So, until Rails 6 is released I think this proposed solution would be a good one to bypass this problem.

I thing the best solution is the one proposed by @mrcasals , but it has still a long path to go... My PR "solves" this problem immediately. I know it is not the best option, but would allow the users to add images in an easy and transparent way, and it is small enough to rollback the changes when Rails6 is stable enough.

I'm not sure about what to do, so I'll let @andreslucena decide here!

Hi @andreslucena and @mrcasals , we're ok with this PR as many of our installations have this need, and I guess Rails 6 is far away. Can you please decide to merge or close it so that we can take some decisions? :D

I was mentioned earlier in the thread, so just wanted to chime in that Rails 6 is already out in beta1. Final version is only a few months away.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. @carolromero & @xabier feel free to chime in.

I would still support adding this button until the Rails 6 update which I would still believe is months away. According to the original schedule, the second release candidate should be already out and it's still in beta. My optimistic guess for a stable release is Q3-Q4/2019.

@ahukkanen I totally agree. But this PR is closed, how can it be reopened?

@operez-ddgi It has to be reopened by the maintainers.

Ping @oriolgual @mrcasals

@oriolgual thoughts on this?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. @carolromero & @xabier feel free to chime in.