Problem/Motivation

Follow-up for #2666382: EditorFileReference filter: generate URLs for inline images, see #2666382-16: EditorFileReference filter: generate URLs for inline images.

For detailed background information, see the issue summary of #2666382: EditorFileReference filter: generate URLs for inline images. In that issue, we focused on the bare minimum necessary to solve the key problem: we implemented point 3 of the proposed solution:

  1. Store embedded image paths as public://whatever instead of /sites/[sitename]. Or even better, don't set a path, since it is completely irrelevant when we have the entity id in there already.

    If <img data-entity-type="file" data-entity-uuid="foo" src="#" alt="..." title="..." /> was all I saw in the database it would make me very happy and confident I could do pretty much anything to the site as long as the managed_files table is intact.
  2. Have the editor image plugin replace the private|public path with the actual path just before switching to WYSIWYG mode (and do the reverse when going to source mode).
  3. Have a filter perform the same replacement before content is rendered.

This issue is about considering to implement points 1 and 2. The main reason we'd want to do that is for semantical correctness. It doesn't bring any real-world benefit, except for one: when a site that lives in a subdirectory is migrated (or deployed) to no longer live in a subdirectory or vice versa, this would ensure that the preview in text editors like CKEditor would still work.

(The content that end users see, i.e. post-filtering, already is guaranteed to always work thanks to the changes in #2666382: EditorFileReference filter: generate URLs for inline images.)

Proposed resolution

Implement points 1 and 2. Note that it comes with some downsides: we could do points 1 and 2, but:

  1. then we have automatic-processing functionality in CKEditor that every other text editor will also need to implement
  2. then we need to make the drupalimage CKEditor plugin aware of which specific text format filters are used, and act only when appropriate
  3. then we need to write JS test coverage — I try to change Drupal core's custom CKEditor plugins as little as possible
  4. I do see that that is semantically more accurate, but I don't see it gaining us much in practice

Remaining tasks

Discuss.

User interface changes

None.

(Well, except that using the Source view in CKEditor would start showing file URLs like public://inline-images/llama.jpg instead of /sites/default/files/inline-images/llama.jpg.)

API changes

None.

Data model changes

None.

Comments

Wim Leers created an issue. See original summary.

effulgentsia’s picture

Or even better, don't set a path, since it is completely irrelevant when we have the entity id in there already.

See my comment in #2666382-30: EditorFileReference filter: generate URLs for inline images.4. The path might be relevant in the case of image style derivatives.

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.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.

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.

Wim Leers’s picture