Created a merge request for review.
kewesley → created an issue.
Reviewing change records, noticed the fix in #7 is now in 10.2.x , see https://www.drupal.org/node/3375751 →
This would be helpful. We have seen some issues reported recently that look like they can be traced back to the polyfill.io service. While the patch/MR works for us, a new release would make it easier to update.
The patch in #8 works for me.
We had a similar issue to #5 where a non-admin user could not download an export in the private files directory, which we fixed by implementing a separate hook in one of our custom modules. I wonder if the regex is overcomplicating things? We are using $file->getOwnerId() to determine who created the export.
use Drupal\Core\Access\AccessResult;
use Drupal\Core\Session\AccountInterface;
use Drupal\file\FileInterface;
function MYMODULE_file_access(FileInterface $file, $operation, AccountInterface $account) {
// Allow access to temporary private file exports.
if ($operation === 'download' && $file->isTemporary() && str_contains($file->getFileUri(), '://views_data_export/')) {
if ($file->getOwnerId() === $account->id()) {
return AccessResult::allowed();
}
}
return AccessResult::neutral();
}This patch worked for me. Thanks!
I have version 8.x-1.2 of the Image Resize Filter module installed on a Drupal 10.2.3 site with a CKEditor 5 text editor.
I'm not sure if there's a difference in how 10.1 and 10.2 handle this, but for me, the resizing appears to work correctly. Both the height and width attributes seem to match the resized image and they are in px not %, just as I would expect. This is a site that was only recently upgraded to D10 so it went straight to 10.2, and was previously running Image Resize Filter 8.x-1.1 with CKEditor 4, if that's relevant.
Can anyone else confirm this or is it just our setup? If it's just us, I can try to work out why so we can get it fixed for everyone.
We were also running into this issue. The current warning shows the same message regardless of whether the existing path is a system path or a path alias and, in my opinion, I don't think the message is sufficiently clear that the redirect will not take effect if the source path is an existing path alias. It does make sense that the alias gets priority, but is very easy to forget or overlook.
Often, the redirect is being added some time after the alias was originally created, sometimes not by the same person, and because the form still allows the redirect to be created, they assume it will work.
I attach the patch we are using to detect path aliases and show a stronger warning, in case anyone else would also find it useful. I believe it requires at least Drupal 8.9 due to using \Drupal::service('path_alias.repository'). Unfortunately, it seems there is no way to query for an alias without also specifying the langcode to check, so there might be a bit more overhead on sites with several languages installed. This patch will also block the redirect from being created if it detects a path alias is being used as the source.
If you do need to redirect from one node to another, you can use the system path as the redirect source, even without removing the alias (with or without the patch).