[drupalImage] Setting to still allow linking to an image by URL even when uploads are enabled

Note that this actually already works, but it's just disabled for editors that image uploads enabled:

    $form['attributes']['src'] = array(
      '#title' => $this->t('URL'),
      '#type' => 'textfield',
      '#default_value' => isset($image_element['src']) ? $image_element['src'] : '',
      '#maxlength' => 2048,
      '#required' => TRUE,
    );

    // If the editor has image uploads enabled, show a managed_file form item,
    // otherwise show a (file URL) text form item.
    if ($image_upload['status']) {
      $form['attributes']['src']['#access'] = FALSE;
      $form['attributes']['src']['#required'] = FALSE;
    }
    else {
      $form['fid']['#access'] = FALSE;
      $form['fid']['#required'] = FALSE;
    }

So enabling this is mostly a question of usability.

Long-term, it may be best to fold this into an issue where multiple ways of selecting images are possible: e.g. Upload, URL, Media Browser, etc.

+1!

#2644640: Pasted images cannot be edited in EditorImageDialog reported this as a bug when pasting images into CKEditor. Which is indeed a straight bug.

My biggest concern: how do we prevent people from just always pasting images, which we do not host, and which could therefore go offline at any time, or even be changed (imagine an innocent math chart being changed for adult content).

optional prompt to come up asking to create the file entry within Drupal if the editor detects an external image being pasted in or manually inserted. It would then upload the file in the background and allow it to be editable with the UI like uploaded images are.

I was thinking the same thing. Or, actually, it could be a setting. By default, any image that is linked is automatically downloaded by Drupal and turned into a Drupal-hosted file. You'd have to change this autodownload setting from its default of on to off to allow hotlinking of images on external sites.

That is closely related to #2560457: Support drag-and-drop image uploads in CKEditor. There, we also need some auto-uploading logic.

Therefore, I propose:

1. To keep this issue scoped to external images should be editable and when inserting an image, allow the user to choose to enter an external source
2. Let #2560457: Support drag-and-drop image uploads in CKEditor take care of both auto-uploading A) dragged-and-dropped images, B) pasted external images.

This was brought up again in #2702657: The image button of ckeditor can't handle external images.

I will try to start something.

Thanks! :)

This is definitely not finished and needs more work but that's where I got until now. People at DrupalDevDaysMilan adviced me to push sooner than later :-)

How it works
If "image upload" is active on the editor config, a radio button is added to select the source type : url or file.
The radio button toggle the display of both field in javascript (see screenshots).
The url field usage is unchanged, it does not download the linked file.

Known issues
- image update: editing an image to use a url instead of a file does not remove the image file and the file field value stay unchanged
- file field:clicking the remove button on the file field reload the form and breaks js and layout
- validation: a check is missing to verify that at least a url or a file are provided

Questions
I also had a few wonders about the implementation :
- should the switch between file and url be on client side or should I use ajax and reload the form from the server ? I find the first one more user friendly ?
- is the javascript at the right place or should it be in it's own file ?
- I had to add extra form elements to surround the file field because the prefix and suffix apparently don't work with managed_files #1865172: Form API : managed_file does not support #prefix and #suffix and I needed classes to hide the input and the associated label

Some tests should probably be added.

Same patch as #12, just added and updated a few comments.

Great first step!

- should the switch between file and url be on client side or should I use ajax and reload the form from the server ? I find the first one more user friendly ?

Client-side for sure. This should use the #states API.

- is the javascript at the right place or should it be in it's own file ?

It's in the right place :)

Now using the proper D8 media tag.

It looks like this may be blocked on #2771837: drupalimage CKEditor plugin should not require data-entity-uuid and data-entity-type when image upload is disabled.

The code is now using #state API.

Managed_file field really have their own way of working. Just like prefix and suffix, state api doesn't seems to work directly on them, even if this issue was closed some time ago #1118016: conditional visibility of a managed_file using #states attribute does not work. I needed an extra container field.

Known issues
- image update: editing an image to use a url instead of a file does not remove the image file and the file field value stay unchanged
- file field:clicking the remove button on the file field reload the form and breaks js and layout
There is an extra margin when the form reloads but this is also present in the current 8.2.x branch
- validation: a check is missing to verify that at least a url or a file are provided

This is blocked by #2771837: drupalimage CKEditor plugin should not require data-entity-uuid and data-entity-type when image upload is disabled.

Applying the most recent patch from #2771837: drupalimage CKEditor plugin should not require data-entity-uuid and data-entity-type when image upload is disabled with #19 seems to do the trick. Combined with the IMCE module the image dialog is now exactly what I needed.

@lucaslg Awesome work. You literally made my day better. Thank you.

@lucaslg :

Known issues
- image update: editing an image to use a url instead of a file does not remove the image file and the file field value stay unchanged

A solution would be to mark the radio butons as disabled for existing images ?

Thanks again !

Good idea Gifad.

It restricts a bit the fonctionnality because you can't change a file to url and vice versa but I can't make my mind if this is a problem or not.

This new patch disables the radio buttons when editing an existing file and fix the last "Known issue".
It also contains adjustments to make it compatible with the last changes from Drupal 8.3.x and 8.4.x.

Known issues
- image update: editing an image to use a url instead of a file does not remove the image file and the file field value stay unchanged
- file field:clicking the remove button on the file field reload the form and breaks js and layout
- validation: a check is missing to verify that at least a url or a file are provided
There isan extra margin when the form reloads but this is also present in the current 8.2.x branch

I fixed the automated tests :
- changed the file form name because it is now in a container field : fid-container_fid
- changed the verification of the url field in the dialog (it is now always shown even if file upload is active)
- added a check to verify that the new radio buttons are displayed correctly (only if file upload is active)

Finally, a few coding standard corrections.

Rerolled with 8.5.x-dev compatiblity.

Tests should pass now.

Rerolled the patch for Drupal 8.6.0-rc1. Can't create an interdiff since pp_1_allow_entering-2510394-39.patch no longer applies because core/modules/editor/src/Tests/EditorUploadImageScaleTest.php has been moved to core/modules/editor/tests/src/Functional/EditorUploadImageScaleTest.php.

Hello Esod, Please rerolled the patch for drupal 8.6.3

Reroll for Drupal 8.8.x.

Reroll the patch for the released Drupal 8.8.x.

Whoops. Here's the reroll for the released version of Drupal 8.8.x without the syntax error.

And one more time. Reroll for Drupal 8.8.x

Surprisingly, #48 still applies and work on 9.1.9. :)
Thank you!

Added reroll of patch #48 on Drupal 9.3.x.

Tried to fix custom commands failures.

Thanks a lot! Great patch for migrated sites!

You still need to apply this patch https://www.drupal.org/project/drupal/issues/2771837 if you want to be able to edit your remote image afterward.
As is, the insert works great but once you save your content and go to the edit page again, the legend (if you had one) disappears and the image can't be edited anymore.

At this point, this feels more like a feature request than a bug

EditorImageDialog is no more since #3306584: [11.x] Remove EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 11.

But we could make this work for CKEditor 5. See #3222756-15: Allow using images from external source.

In #22 I postponed this on #2771837: drupalimage CKEditor plugin should not require data-entity-uuid and data-entity-type when image upload is disabled. But that same bug fortunately does not exist for CKEditor 5 — we didn't port that bug 😄

Agreed that this is a feature request, not a bug. And it's not major given that >10 years of CKEditor in Drupal has only resulted in 25 followers for this issue.

But … is this truly worth doing? "Hotlinking" external images is problematic: the URLs may stop working, and/or the image at that URL might change.

Quoting the original reasons by @quicksketch:

- The user only has the URL to a managed file (e.g. right-clicked on an image and used "Copy image URL")
- The image is a theme-level or manually uploaded asset outside of Drupal.
- The image is hosted on another site (for better or worse).

Long-term, it may be best to fold this into an issue where multiple ways of selecting images are possible: e.g. Upload, URL, Media Browser, etc.

1. Media + Media Library in core combined with the CKEditor 5 integration have solved that since then
2. Linking to theme-level assets seems very edge-casey. External assets ("Digital Asset Management" systems or "DAMs") are common but … they are nowadays typically integrated with Drupal's Media Library 🥳
3. This is the only reason to do this. But then there's security reasons to not do that: it's always safer to download and upload it to this site itself.

So I'm going to be bold and close this issue. It didn't materialize for nearly a decade. There's been little demand from the community. And since then, we've gained Media Library in core, and a neatly integrated CKEditor 5 media embedding experience. I think the considerations that went into this in 2015 would be very different today, so the relevance of this issue has diminished.

If anybody disagrees: feel free to reopen! 😊

re-opened.
see https://www.drupal.org/project/drupal/issues/3439275#comment-15558438

forcing every single image to be uploaded in media library ? really ?

Was this still possible in Drupal 11?

In Drupal 10 the editorImageDialog and other Drupal managed forms were deprecated and are completely removed in D11.
See https://www.drupal.org/project/drupal/issues/3231341

I was wondering if anyone has accomplished a combined Upload and URL interface in a patch.

EDIT: I was able to get this working though, editing the ckeditor5.ckeditor5.yml and CKeditor5plugin/Image.php to add URL to integrations. I think both were required.

diff --git a/core/modules/ckeditor5/ckeditor5.ckeditor5.yml b/core/modules/ckeditor5/ckeditor5.ckeditor5.yml
--- a/core/modules/ckeditor5/ckeditor5.ckeditor5.yml
+++ b/core/modules/ckeditor5/ckeditor5.ckeditor5.yml	(date 1771447225731)
@@ -633,7 +633,6 @@
     label: Image URL
     elements: false
     conditions:
-      imageUploadStatus: false
       plugins: [ckeditor5_image]

 ckeditor5_imageResize:

diff --git a/core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/Image.php b/core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/Image.php
--- a/core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/Image.php
+++ b/core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/Image.php	(date 1771449175090)
@@ -39,6 +39,7 @@
         ],
       ];
       $config['image']['insert']['integrations'][] = 'upload';
+      $config['image']['insert']['integrations'][] = 'url';
     }
     else {
       $config['image']['insert']['integrations'][] = 'url';

Which makes me wonder why the decision was made to only allow one of these? why not allow both?