Problem/Motivation

Image files are tracked using data-entity-uuid and data-entity-type attributes, and those are only assigned when the file entity is saved, which only happens after uploading the image. However if we include an image using the URL text input, the file is not saved neither received values for uuid and type, so it is not tracked, even if that image is in the file system.

Also, not having data-entity-uuid and data-entity-type attributes makes the image unable to be edited using the drupalimage plugin button.

Proposed resolution

Save images added by URL from the file system as entities, assigning uuid and type in order to be tracked and to be able to be edited.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

juanolalla created an issue. See original summary.

juanolalla’s picture

Status: Active » Needs review
FileSize
2.39 KB

Adding the patch.

Status: Needs review » Needs work

The last submitted patch, 2: allow_tracking_images-2828048-2.patch, failed testing.

The last submitted patch, 2: allow_tracking_images-2828048-2.patch, failed testing.

joelpittet’s picture

Status: Needs work » Needs review

Testbot failure, resetting status due to https://www.drupal.org/node/2828045

m4olivei’s picture

Looking good @juanolalla. Couple nit picks:

  1. +++ b/core/modules/editor/src/Form/EditorImageDialog.php
    @@ -213,6 +214,40 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
    +      $path = $form_state->getValue(array('attributes', src));
    

    src should be surrounded in single quotes.

  2. +++ b/core/modules/editor/src/Form/EditorImageDialog.php
    @@ -213,6 +214,40 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
    +            if ($file instanceof File) {
    

    file_save_data returns either a FileInterface instance or FALSE on error. Change this so the assignment is in the if statement and get rid of the instanceof check

  3. +++ b/core/modules/editor/src/Form/EditorImageDialog.php
    @@ -213,6 +214,40 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
    +              $form_state->setValue(array('attributes', 'data-entity-type'), 'file');
    

    Should probably use $file->getEntityTypeId() instead to be more correct.

juanolalla’s picture

m4olivei’s picture

Looking good to me. I've just merged the site we're working on. Not sure if this needs tests or not to reach the bar for core contrib. Also, haven't tested on 8.3.x. Otherwise RTBC for me.

Wim Leers’s picture

Component: editor.module » file.module

The raw src attribute is designed for just pasting image URLs from anywhere. What you want, is the ability to reuse images. +100000 for that. But this is not the right way to achieve that. The proper way to achieve that would be to have a UI to allow images to be selected, and then once you have a file selected, EditorImageDialog would indeed set those attributes.

And that's really something '#type' => 'managed_file' (i.e. \Drupal\file\Element\ManagedFile) should support, then it'll work automatically in EditorImageDialog :)

juanolalla’s picture

The raw src attribute is designed for just pasting image URLs from anywhere...
...The proper way to achieve that would be to have a UI to allow images to be selected, and then once you have a file selected, EditorImageDialog would indeed set those attributes.

So we have a simple raw src form for pasting URLs, and we might need that images introduced by relative URLs would be managed as file entities. Why we would need a UI for selection to accomplish that?

Please, look at this this way, there could be other contrib modules that provide a UI for selection on top of the single URL raw src form, as you're suggesting. That is what IMCE does, through adding a "Open File Browser" link on that URL field. IMCE allows you to manage your files directory and select one image, but in the end what we have is a raw src returned, because that is what this form was designed to do. Those files won't be registered as entities unless we implement that in EditorImageDialog, as I'm proposing in my patch.

And that's really something '#type' => 'managed_file' (i.e. \Drupal\file\Element\ManagedFile) should support, then it'll work automatically in EditorImageDialog :)

That could be nice, although what I've done for consistency is the same that was already done for uploaded images, see lines 208-217 in EditorImageDialog:

  if (!empty($fid)) {
      $file = $this->fileStorage->load($fid);
      $file_url = file_create_url($file->getFileUri());
      // Transform absolute image URLs to relative image URLs: prevent problems
      // on multisite set-ups and prevent mixed content errors.
      $file_url = file_url_transform_relative($file_url);
      $form_state->setValue(array('attributes', 'src'), $file_url);
      $form_state->setValue(array('attributes', 'data-entity-uuid'), $file->uuid());
      $form_state->setValue(array('attributes', 'data-entity-type'), 'file');
    }

I think changing both uploaded images and relative URL images to use somehow a field type 'manage_file" would be out of the scope of this issue

juanolalla’s picture

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.

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

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.

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

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Nuuou’s picture

We've been using patch #7 for pretty much our entire duration of Drupal 8.
Since it's kind of grandfathered in to our setup, we decided to keep it around.

Had to make some modifications for D9 compatibility, as some methods were removed or deprecated.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
2.03 KB

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

pooja saraah’s picture

Fixed failed commands on #21
Attached patch against Drupal 10.1.x

nod_’s picture

Status: Needs work » Needs review
needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
1.59 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.