🇨🇦Canada @druplr

Re-rolling #19 against 10.4.0.

Here is a patch to fix the issue.

druplr → created an issue.

druplr → created an issue.

Here is @mattbloomfield's patch #66 (which as @dasginganinja indicated, is #49 rerolled) with whitespaces corrected. This does not include the new functionality / schema changes in #61/63.

@chrisgross

1. Did you manage to disable base theme's ckeditor5-stylesheets? I just created an issue for that: Allow overriding/disabling base theme's ckeditor5-stylesheets value ✨ Allow overriding/disabling base theme's ckeditor5-stylesheets value Active which also includes a workaround.

2. You may already know this, just in case you don't: one way to prevent admin theme's CSS in CKEditor5 is to turn off the "Use the administration theme when editing or creating content" option in /admin/appearance. But this doesn't help for when the admin theme is preferred in the edit pages.

Hi alex.skrypnyk. It doesn't seem to be the case. Please see this issue I just created: Allow overriding/disabling base theme's ckeditor5-stylesheets value ✨ Allow overriding/disabling base theme's ckeditor5-stylesheets value Active . Have you seen this somewhere in the documentation? Thanks.

druplr → created an issue.

Thanks! Patch in #17 works well in entity view with Drupal 10.2.2 + field_group 3.4.0.

Here is a new patch to add this feature to entity edit form in addition to entity view.

Thanks everyone!!

Having the "Upscale and crop" and "Don't upscale but still crop" options is very useful. However, I am wondering what is the expected behavior of "Don't upscale and don't crop" (no_upscale_no_crop) option regarding cropping? From its label, it seems that it should not crop the image. Right? Or maybe I'm missing something?

But with focal_point 2.1.0 and focal_point-3048398-37.patch → and no_upscale_no_crop option selected, it still crops the image:

Please see the config below:

uuid: 1fe0eeae-1be1-42ab-8d47-c8b8160ad6c1
langcode: en
status: true
dependencies:
  module:
    - focal_point
name: test
label: test
effects:
  ba78a9d7-fcd3-4acd-a764-bc0e3b4a3fc1:
    uuid: ba78a9d7-fcd3-4acd-a764-bc0e3b4a3fc1
    id: focal_point_scale_and_crop
    weight: 1
    data:
      width: 20
      height: 100
      crop_type: focal_point
      upscale: no_upscale_no_crop

Also, the "don't crop" part seems contradictory with focal_point module's mission:

Focal Point allows you to specify the portion of an image that is most important. This information can be used when the image is cropped or cropped and scaled so that you don't, for example, end up with an image that cuts off the subject's head.

If we do not intend to crop, can't we just use core's image_scale instead? It has an option to upscale or not.

Now that I re-read your last sentence, I am thinking you probably mean to allow the user select either of the options above in the Translate config form. If so, I can't think of a case that the first option (replace and then translate) be used. The second option (translate and then replace) however, would work similar to the t() function I think, which is more familiar to the developers.

Thank you jurgenhaas for your prompt response!

I didn't mean to avoid token replacement altogether. I meant to make it optional.

The tokens can still be replaced in a subsequent action. In my example above, the Translate action is only responsible for the traslation; and it is the Display a message to the user action that replaces the token.

However, the second alternative approach you provided should work:

...Instead, we may have to provide an option to either replace and then translate, or to first translate and then replace.

• replace and then translate <- This is the current behavior as far as I understand.
• first translate and then replace <- This should satisfy most cases including mine I think.

druplr → created an issue.

Here is a patch to fix the issue for newly generated subthemes.