Allow tokens to be used in Text Editor/CKEditor 5 image upload directory path

The image upload functionality was introduced in #1932652: Add image uploading to WYSIWYGs through editor.module. We specifically didn't support tokens in the upload path to get to an MVP faster. The fact that this is the first explicit issue requesting this, shows that it's rarely necessary.

If you (or somebody else) wants to work on supporting this, including test coverage, then we'd totally welcome that. I'll provide reviews.

But it's probably better to instead do this as a contributed module. Something like editor_advanced_image, in analogy with https://www.drupal.org/project/editor_advanced_link.

Cool! :)

a token-path would be great

+1

Client asked for this kind of image hieararchy:

images
	content_type_1
			field_1
			field_2
			inline
	content_type_2
			field_1
			field_2
			inline

But I also see the date token very logical because the image field is already using it. Why shouldn't there be then the same functionality for inline images.

+1

Going on my 3rd year in the Drupal world and I'm always fascinated that this CMS doesn't really manage large amounts of content well. One folder is fine for small sites, but isn't the Drupal audience medium to large sites? I'm kinda shocked that more people haven't piped up about expanding the use of tokens on sites for situations like this.

I'm working on a D8 university site where departments upload a lot of documents. I've been using Paragraphs for a 'Downloads' section to keep it clean, but now I'm getting a lot of requests for inline links to document files. IMCE isn't the answer because that's what made our old D7 site a gigantic mess. I have an army of non-technical Editors that drew the short straw in their department, so I'm aiming for simple and fast. Adding date tokens would at least prevent an 'inline-files' folder full of thousands of files.

I don't have the resources for a DAM or the know-how to even connect it to Drupal if I did. My dream situation is a Media Browser that checks the page Taxonomy and only shows the editor the files/folders that belong to that department. Like biology/images, biology/files, biology/podcasts, etc.

This would be a great feature. Currently, I am using AWS S3 and am running into problems if we try to embed an image with the same filename. If tokens were allowed it would solve this problem and it would also make it easy to track files on S3 by user.

+1, I absolutely want this - clumping everything into one directory is a terrible idea and 'performance' is a (mostly) terrible excuse for doing it (IMHO, YMMV). If Drupal 9 (or 10, or 11, or whatever) comes along and changes everything the way D8 did and I suddenly want all my data out in an easy way then I don't want to have to fight to find it and/or get it.

I'm producing large quantities of information on thousands of bits of equipment from hundreds of manufacturers and distributors and I absolutely want all images, attached as an image field or inline, to be in the same subfolder - one specific to that piece of equipment... I've created a hierarchical folder structure for attached images, I just can't use it for the inline ones (nor can I easily Colorbox them without, perhaps, stepping outside the security advisory umbrella - but thats another issue).

I'm happy to try and help with this if its going to be a difficult job - testing, documentation, possibly coding... let me know.

Cheers

Steve

+1 An absolutely necessary feature

Patches in #14/#15 seem to do the trick: tokens configured in the 'Upload directory' for the WYSIWYG image field are replaced in the image destination. Still needed AFAICT:

- Let's add 'This field supports tokens.' to the 'Upload directory' field description.
- Tests

I have created a contrib module base on the patch:
https://www.drupal.org/project/inline_image_token

Hi all, any updates on this making it to core eventually?

I work with some Drupal sites that handle hundreds of image uploads a day. It's a complete mess to have all the images go in one folder. In one month we'd have thousands, and in a year we'd have tens of thousands of images in that folder. It would be great to no longer have to rely on a custom module that may or may not continue working in the future.

This is still needed!

Just a simple reroll for 9.5. I also updated the description of 'Upload directory' (according to #17).
Still needs work for adding tests.

Closed #3351476: CKEditor 5 doesnt support directory tokens for inline images as a duplicate of this.

This patch is correctly updating editor_image_upload_settings_form() and EditorImageDialog. But EditorImageDialog is going away: #3231341: Deprecate EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 10.1 for removal in Drupal 11. Still, CKEditor 5's \Drupal\ckeditor5\Plugin\CKEditor5Plugin\Image::buildConfigurationForm() continues to call editor_image_upload_settings_form().

Which brings up an interesting question … perhaps this should actually be converted into a CKEditor 5 issue? due to #3231341, the bulk of the changes would actually have to happen in the CKEditor 5 module, not the Text Editor module?

Also related: #3231354: [PP-2] [META] Discuss: merge the Editor config entity into the FilterFormat config entity, at which point it quite possibly makes sense to drop \Drupal\editor\EditorInterface::getImageUploadSettings() altogether? The very reason that configuration was stored on the general Text Editor config entity was to maximize the ability to switch between different text editors back in #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration, over 10 years ago 😳, by putting configuration that could be shared between text editors in the general Text Editor config entity rather than the text-editor-plugin-specific settings.

But in that decade, no notable alternative text editor has sprung up in the contributed module space. So why keep this API surface complexity? Why not drop it exactly at the time when we are modifying EditorInterface anyway (i.e. merging it with FilterFormatInterface).

Tagging Needs framework manager review for that.

For Ckeditor5 in drupal 10, 1 line code change could fixed it:

change

$destination = $image_upload['scheme'] . '://' . $image_upload['directory'];

to

$destination = $image_upload['scheme'] . '://' . \Drupal::token()->replace($image_upload['directory']);

in "upload" function of file "core\modules\ckeditor5\src\Controller\CKEditor5ImageController.php"

@Wim Leers so should we block this on #3231354: [PP-2] [META] Discuss: merge the Editor config entity into the FilterFormat config entity? My gut feel is that we should do the smallest change possible here and only change ckeditor5. And if #3231354: [PP-2] [META] Discuss: merge the Editor config entity into the FilterFormat config entity goes ahead it'll take care of the other stuff in #30.

FWIW we can use \Drupal::token()->replacePlain() here.

#34 makes it sound like this should be postponed. Or moved to ckeditor5.

Let me put this temporary patch for CKEditor5 here.
Just for note - at least the old ckeditor seems to be loaded without any context, so it's hardly possible to use any tokens except global ones there.

all these patches work only with the date? I'm trying [node:nid] and it doesn't work (#38) :(

Hi Anche, there is an example of workaround for a similar case. https://drupal-coder.ru/blog/privatnye-kartinki-ckeditor-drupal-dinamich...
The post is in Russian but everything is clear from the code.

Alezu, thanx a lot! It helped me.

here's a reroll of the temporary fix in #38 that should work with 10.3.0

Patch #42 worked with Drupal 10.3.6 too!
(not sure if this issue can be marked for 10.3.x or 10.4.x though)

I tested inline-files/[date:custom:Y]-[date:custom:m] as suggested in issue body.

Maybe we want separate follow up issues for:

1. improving the UX, for example by adding a link to Browse available tokens
2. making any other contrib module use tokens out of the box (not sure it's possible or they are expected to put some code anyway to enable token replacement in the fields they define)
3. making other tokens (non-globally available ones) work, for example related to the parent entity having the CKE text field (for example [node:nid] doesn't work, as expected?).

..so that we can include this quick fix soon?

Regarding 2 for example, the editor_file contrib module (that works like core editor's inline images but for files, creating links) wasn't substituting tokens out-of-the-box with this patch, but it started working fine with this patch.

Moving back to needs work since the "needs test" tag is on the issue and I haven't seen any test coverage in MR#3891 so far.

Patch #42 works in Drupal 10.3.10.

Personally, I think this is is quite a crucial feature to have because without it, sites' sites/default/files/inline-images folders will be in danger of becoming dangerously bloated, I know mine is!

Attaching a proper DI reroll of MR#3897 that's compatible with 11.1.7.

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Also mentioned on the version section of the list of issue fields documentation.

Patch for Drupal 10.6.