@damondt The only place I can see it being set somewhere else is here
if ($apply_image_styles) {
$view_mode = $this->getViewModeByWidth($width, $ckeditor5_plugin_config);
if ($view_mode) {
$node->setAttribute('data-view-mode', $view_mode);
}
}
But that code only runs when your not in the editor because $apply_image_styles is only set to true outside of the editor
// Apply image styles only if the corresponding setting in the text format
// configuration is enabled and if the filter is NOT processing during the
// loading of the text inside the ckeditor.
$apply_image_styles = !empty($ckeditor5_plugin_config['apply_image_styles']) && !$processing_in_editor;
Make sure you have the filtering order is set correctly for the text format your using. The Resize media images filter needs to run before the Embed media filter.
@marcoscano Thanks for catching that, this is not an issue caused by the module, but introduced by a patch from https://git.drupalcode.org/project/entity_usage/-/merge_requests/35
Sorry for the trouble. You can close this.
@koosvdkolk and @lhridley Was also running into the resizing issue after save. Created a new ticket and a possible fix at
https://www.drupal.org/project/ckeditor_media_resize/issues/3484766
🐛
Re-sizing breaks after initial save or preview
Active
Created a new issue for this and added a possible fix in an MR.
https://www.drupal.org/project/ckeditor_media_resize/issues/3484766
🐛
Re-sizing breaks after initial save or preview
Active
@lhridley and others can test it
Added a possible fix as an MR. If others could please test. Thanks
Same error as above. It seems the MR/patch does NOT work.
I'm also running into this on beta2 same as above. May need to have this re-opened
Adding a patch
hablat → created an issue.
Added a patch to solve this. I have not seen a good way to detect the invalidation type within the event listener, there may be a better way of addressing this; But this works for us for now.
Thanks, I've modified the MR to set a max-age for the redirect.
I did test for this on the browser, and was not able to get the redirect loop to happen. In the Scenario where you visit Hash A, where it was previously redirected it gave a 200 response instead of a 301. If you visit Hash B it gets redirected to Hash A, but also returns a 200 instead of the 301. I may be missing something, but if you can induce this locally with just browser cache please let me know the testing steps.
I do believe that if the issue/scenario is induced by having another caching layer, like a CDN, then it should be dealt there.
But if we do have to make Drupal dictate the TTL, what we can do is instead of dictating the TTL on the asset file. We can instead set a cache TTL for the redirect.
Right, I wasn't implying they were the same. Just saying their cache TTLs can both be set on the CDN as long as Drupal doesn't set the precedent for the cache headers.
We're not too keen on having Drupal dictate the cache headers/ttl. It's what got us in trouble the first time around. I think in that scenario it should be dealt on the CDN level. Configure CDN to have lower ttls on asset paths/redirects, expire cache after deployment, etc.
The main issue for us is that if you gave any asset filename, that drupal was not expecting, it would respond with a 200 Cache-Control: private, no-store, essentially taking away the caching control from the upper layers of cache. This is an easily exploitable way to keep hitting origin.
Created an MR and hid the patch. Also changed to apply to the main 11.x branch
Looks like there are some test scripts that still expect an private no-store for aggregated assets. May need to have them adjusted as well.
I did look around and there were some issue potentially related, but did not find anything dealing with this. The closest is the related issue #3427916 which seems to be tackling this through .htaccess change.
I'll work on getting MR with the test script adjustments as well
Added a patch that redirects the old asset url to the new expected url. Should then lead to serving a valid file from the asset directory. Not sure if this is the right approach, but working for us so far.
We are also running into this, and it seems for us the cache control is set to no-store when you request an aggregated file that Drupal does not expect. For example if this is one of the JS requests that drupal generates on page load
/sites/my.site.com/files/js/js_k7uMCXgc43aWXEacSj8oD_I5kXAJJ7IABhs2MRXtPEg.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk
If you change the file name to something random, but keep everything else. Drupal will respond with a 200 and a no-store cache control. example
/sites/my.site.com/files/js/js_RANDOMFILENAME.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk
This is an issue for us because we have a use case where other sites reference our assets and may not have the update js/css aggregated links right away. And this causes a lot of uncached requests hitting all the way to origin. Specifically if those sites have bots crawling them
We had to account for when the views area was added to the "No results behavior" section of the view. Adjusted the patch for this
I've added a patch that resolve the issue for us
Is there a way to get a patch/fix for this on 10.2.x?
We're running into this issue ourselves.
Narrowed it down to the following line in core/misc/states.js changing from
const $states = $(context).find('[data-drupal-states]');
to
const elements = once('states', '[data-drupal-states]', context);
due to the the fix in
https://www.drupal.org/project/drupal/issues/3347144
🐛
Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations)
Needs work
We have a temporary fix at the moment with a custom patch that changes
const elements = once('states', '[data-drupal-states]', context);
back to
const elements = $(context).find('[data-drupal-states]');
We're using this until someone comes up with a better patch.