v6.0.9 change not compatible with WordPress Reader

  • Resolved Alexander S. Kunz

    (@antermoia)


    4 years, 10 months ago

    Dear Jordy,

    while I like the change in the most recent version that moves the files to the date-based folder according to the capture date, this appears to be incompatible with WordPress Reader.

    For a photo that I uploaded yesterday and that Photo-Engine moved into the /2008/10/ uploads folder, WordPress Reader still tries to access that photo from the /2021/07/ location (many entries in my 404 log).

    I’ve reverted to v6.0.8 because of this, but would generally prefer to have NEW uploads in the current folder, and only the attachment date set to the capture date (not just because of WordPress Reader), like it used to be.

    It would be great if this was separately configurable and not tied to the “Use Photo Taken Date” option.

    Thanks
    Alex.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter Alexander S. Kunz

    (@antermoia)

    4 years, 10 months ago

    Update: it appears that both WordPress Reader and the Jetpack “Photon” module (image CDN) first attempt to use the GUID to access media. Since the GUID is the path+filename of the media file for attachments, this obviously fails when the media item is moved and the GUID isn’t updated to reflect the new location.

    (the same happens when using Media File Renamer without updating the GUID)

    Plugin Author Jordy Meow

    (@tigroumeow)

    4 years, 10 months ago

    Hi @antermoia,

    Only happens with JetPack Photon? And are you sure they are using the GUID? It sounds odd… officially, the GUID is only a unique identifier. Since WP usually set the filename has the identifier (as it’s unique), some old plugins used the GUID in the past, but not anymore (I don’t think). That’s why I would be surprised JetPack does this too.

    media item is moved

    Actually, the media is never moved by WP/LR Sync 🙂 So you mean when it’s created too?

    Thread Starter Alexander S. Kunz

    (@antermoia)

    4 years, 10 months ago

    Hello Jordy,

    both WordPress.com Reader (RSS reader) and Photon try to use the GUID first to access the media, that’s just how it is. I don’t use Photon on my site, but it’s used for some features like the Jetpack “Related Posts” nevertheless (to resize the photos to thumbnails, on the fly).

    The GUID that WordPress creates appears to be always based on the CURRENT upload date but in the last update (v6.0.9) you changed the existing feature that, if the DATE of the photo is set to the capture date, it’ll now ALSO end up in the date-based folder in the media library (if that’s not a move operation then I made the wrong assumption).

    As a result, neither WP.com Reader nor Photon find the file at the location specified in the GUID. They do find the file by falling back from using the GUID, but it creates plenty of 404 errors.

    For example, upload from today with a photo shot five years ago, the GUID is url.tld/wp-content/uploads/2021/07/somefile.jpg

    But, with the new combined option, WP/LR Sync puts the file into url.tld/wp-content/uploads/2016/07/somefile.jpg

    If I upload a photo from 2016 today, then logic dictates that it ends up in the 2021/07/ folder, and nowhere else (this is useful for a number of reasons to me: US copyright registrations, copyright disputes, image optimization).

    Therefore, it would be nice if the option to adjust the media date to the capture date and the storage folder used were SEPARATE options and not tied together.

    I hope it’s clearer now.

    Thanks.

    Plugin Author Jordy Meow

    (@tigroumeow)

    4 years, 9 months ago

    Just to keep the information here; this has been fixed with a new option in Upload & Sync 🙂

    Thread Starter Alexander S. Kunz

    (@antermoia)

    4 years, 8 months ago

    Thank you very much for implementing this new option Jordy, that’s great! 👍🏻

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘v6.0.9 change not compatible with WordPress Reader’ is closed to new replies.