Absolute path in _wp_attached_file for scaled images

I’ll have to try reproducing this when time permits, but for now, if you delete the file and upload it to the final destination folder, without moving, does it properly store the relative path?

Thanks for your response. Yes, uploading a file without moving it stores the proper, relative, path. After the move it is an absolute path.

I also found a problem with the Block Direct Access feature. If you go to Media Library Folders/Settings, Block Direct Access tab and check only the “Auto Protect New Uploads” box, leaving the “Activate Block Direct Access” box unchecked it will say “Block Direct Access is off” but new uploads are moved to the protected-content folders and blocked anyway. Should I open a separate topic for that problem?

I’m glad to hear that you got the file to upload correctly. Thank you for reporting the issue about block direct access. I’ll add it to my to do list.

We have released version 8.1.6 that addressed the issue with moving files when block direct access is off and auto protect is on. So far, I have not been able to reproduce the issue with the scaled file as I don’t access to Windows Server.

I have just tested MLF 8.1.6 on my Windows site and on another site running Linux.

On the Windows site the path corruption remains.

On the Linux site the path corruption does not occur, but I observed other problems with moving a large/scaled image from one folder to another. Specifically:

1. There are two sets of intermediate size files in the destination folder. One set has just the original file name and the other set has a “-scaled” appendage.
2. The attachment metadata “sizes” array contains the file names with the “-scaled” appendage. This is not the WordPress convention.
3. The “image_meta” array after the move does not have any of the values the array contained before the move. This includes the “original_image” element that held the original file name.
4. Deleting the image from the Media Library deletes all of the “-scaled” files but does not delete the original image file or any of the intermediate size files without the “-scaled” appendage.

I have screen shots of these problems if you need to see them.

Thank you for the information. I don’t believe that I will have a fix for this right away. There are possible work arounds to use for now, such as disabling the scaling of images in Media Library Folders Settings or uploading images with a width and height of less than 2560 pixels.