You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a legacy project, upgrading from EE2 > EE7, including adding on-the-fly image manipulations and I discovered that new or existing images that contain parentheses characters in the filenames generate on-the-fly resized images correctly, but the URLs to those resized images are converting the special characters incorrectly so the images are broken. The specific instance I discovered has an image named like filename_(8).jpg where the resized URL output gets changed to /_resize/filename_%25288%2529_resize_#hash#.jpg and it doesn't work. The encoded values for ( and ) are %28 and %29 so I don't know where those '25's are coming from. Manually updating the URL to /_resize/filename_(8)_resize_#hash#.jpg or even /_resize/filename_%288%29_resize_#hash#.jpg in the URL does load the resized image correctly.
I've not tested to see if this is an issue with other url-safe special characters.
The text was updated successfully, but these errors were encountered:
EE 7.2.11
I'm working on a legacy project, upgrading from EE2 > EE7, including adding on-the-fly image manipulations and I discovered that new or existing images that contain parentheses characters in the filenames generate on-the-fly resized images correctly, but the URLs to those resized images are converting the special characters incorrectly so the images are broken. The specific instance I discovered has an image named like
filename_(8).jpg
where the resized URL output gets changed to/_resize/filename_%25288%2529_resize_#hash#.jpg
and it doesn't work. The encoded values for ( and ) are %28 and %29 so I don't know where those '25's are coming from. Manually updating the URL to/_resize/filename_(8)_resize_#hash#.jpg
or even/_resize/filename_%288%29_resize_#hash#.jpg
in the URL does load the resized image correctly.I've not tested to see if this is an issue with other url-safe special characters.
The text was updated successfully, but these errors were encountered: