There are two cases where the "Restrict images to this site" doesn't work properly:
1) If you copy/paste an image directly into CKEditor, it brilliantly converts it into base64 and the code is saved to the database, like so: <img alt="" src="data:image/png;base64, lots and lots of characters />
2) If your image is explicitly referenced using the full URL (I have got lots like this on my site as a result of using IMCE), like so: <img alt="" src="http://mysite.com/my-image-file.jpg" />
In both these cases, although the image is actually on my site it only gets displayed if I switch off the "Restrict images to this site" filter

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joel_guesclin created an issue. See original summary.

Wim Leers’s picture

Title: Copy/pasted image, or explicit http reference, disallowed by filter » Copy/pasting images into CKeditorCopy/pasted image, or explicit http reference, disallowed by filter
Version: 8.2.1 » 8.2.x-dev
Status: Active » Postponed (maintainer needs more info)
Related issues: +#2257291: Handle alternate domains in filter_html_image_secure

Those are two distinct problems. Please create separate issues for them next time :)


  1. I cannot reproduce this. Please post steps to reproduce, including the HTML to copy/paste from. If the copy/pasted HTML references image URLs, the HTML that CKEditor generates upon pasting will also reference those same image URLs.
  2. This is a bug in filter.module, not in ckeditor.module. Specifically in \Drupal\filter\Plugin\Filter\FilterHtmlImageSecure. There are several problems with that filter. I think #2257291: Handle alternate domains in filter_html_image_secure is closely related.
Wim Leers’s picture

Title: Copy/pasting images into CKeditorCopy/pasted image, or explicit http reference, disallowed by filter » Copy/pasting images into CKEditor results in data URIs being embedded
joel_guesclin’s picture

I can reproduce this on a Mac, so here goes:
1) Make sure that "Restrict images to this site" is switched on for "Full HTML"
2) Choose an image on your workstation, and open it using the default image display app on the Mac (mine is in French so it's called "Aperçu", I think it's "Preview" in English?
3) In Preview, use the menu option Edit > Copy
4) Then create an Article (I'm in Drupal 8.2.1), and select text format Full HTML. In the Body textarea, right-click and choose option "Paste".
5) In my browser (Firefox 49) I then get a modal window saying that because of the browser security settings I can't copy directly into the window, so do to paste the image
6) The image appears in the textarea.
7) Save the article. The images are replaced by red warning "X"
8) Switch off "Restrict images to this site" for Full HTML and display the article. The images appear.
So there is no HTML to copy/paste, only an image

One thing I have noticed, is that this only works in Full HTML. If you try to do this using Basic HTML (I've not at all changed the input formats), then the "src="data:image/png;base64" gets changed to "src="image/png;base64" and the image doesn't show at all when displayed.

I'm not sure how important this is, because I'm not even sure whether or not it is a good idea to use base64 inline images like this. I imagine that they don't work with responsive images. I'm also testing this in the "Inline responsive images" module, for which I have raised another bug.

joel_guesclin’s picture

Status: Postponed (maintainer needs more info) » Active

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

avogler’s picture

Here's a patch for 1) that allows data URIs in the src attribute of img tags. Haven't tested it with Copy/Paste but works for my use case of inserting FMath formulas.

avogler’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 8: 2824087-8.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

avogler’s picture

Status: Needs work » Active

As this patch breaks some tests I reconsidered the aproach. I guess it is easier to add the "data:" scheme to the list of allowed protocols in a services.yml. Hope this helps if someone stumbles over the same problem.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

seanB’s picture

Just ran into the first problem as well. There are CKEditor issues for it and it seems to be a browser issue:
https://dev.ckeditor.com/ticket/8208
https://dev.ckeditor.com/ticket/8021

Also found this, you can fix this with a custom plugin:
https://stackoverflow.com/questions/6582559/ckeditor-preventing-users-fr...

askibinski’s picture

Here is a small module which implements a ckeditor plugin like the one Sean mentions:
https://www.drupal.org/project/ckeditor_blockimagepaste

It prevents pasting/dropping an image if you enable the plugin for the filters desired.

Wim Leers’s picture

@askibinski Would it make sense to move this into Drupal core instead?

seanB’s picture

For now the module still has some issues in IE11 and Edge. Also not sure if we can have proper tests for the copy/paste and drag & drop? Let's at least create a initial patch for review and something to iterate on when there is a need for it.

askibinski’s picture

I'm going to give it a shot writing a nightwatch test for this during the dev days here in Lisboa.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

askibinski’s picture

Turns out it's perfectly possible to write a Nightwatch test for this:
https://www.drupal.org/project/ckeditor_blockimagepaste/issues/3027063

So that's something. I think this can live in contrib just fine for anyone having this problem. There haven't been any comments in over half a year in this issue so it's probably an edge case scenario which doesn't affect many people. Otherwise, next step could be a patch based on the work in contrib.

maxilein’s picture

I don't think it is an edge case. It is important for the interoperability with other technologies.
I think it is even a blocker to adopt drupal for rich content creating sites at all.

devkinetic’s picture

I am running the contrib module that blocks this.

IMO by default allowing a user circumvent the media entity system, while simultaneously filling the DB with base64 is an issue. I see the edge case wanting to embed base64 into wysiwyg.

If pasting an image instead added a new media entity, and then placed it in wysiwyg, that would be a different story. That sounds more like a contib than core piece though. Just my thoughts...

Wim Leers’s picture

If pasting an image instead added a new media entity, and then placed it in wysiwyg, that would be a different story.

I think that'd be an excellent feature request that is now more feasible than ever before :) (With Media embedding in the upcoming Drupal 8.8 and REST/JSON:API file uploads since April 2018.)

devkinetic’s picture

@Wim It should activate the add image dialog, so field data can be filled out, and there is the use case of a user pasting content with multiple images. I agree we are closer than ever, and these use cases will help to round out the UX we've been waiting so patiently for.

maxilein’s picture

Please consider the following use case:
You want to keep something that consists of multiple chapters with multiple images.
Popping up the image dialouge for each is not practical!
There need to be options for automating these conversions of multiple images.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Project: Drupal core » CKEditor 4 - WYSIWYG HTML editor
Version: 9.4.x-dev » 1.0.x-dev
Component: ckeditor.module » Code

CKEditor has been removed from core, CKEditor 4 is removed from Drupal Core in 10.0.0