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:
- 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 themanaged_files
table is intact.- 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).- 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:
- then we have automatic-processing functionality in CKEditor that every other text editor will also need to implement
- then we need to make the
drupalimage
CKEditor plugin aware of which specific text format filters are used, and act only when appropriate- then we need to write JS test coverage — I try to change Drupal core's custom CKEditor plugins as little as possible
- 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
Comment #2
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSee 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.
Comment #16
Wim LeersWe're not going to do this, because: #3231341: Deprecate EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 10.1 for removal in Drupal 11.