10up / windows-azure-storage

Use the Microsoft Azure Storage service to host your website's media files.

Home Page:https://wordpress.org/plugins/windows-azure-storage/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Original image uploads too early for WordPress to generate intermediary sizes

Clorith opened this issue · comments

When uploading media, the original image is uploaded to Azure instantly, before WordPress' scripts have had a chance to create intermediary sizes. This means the media library thumbnail, and similar, now return a 404 error, as the original image needs to be available on the filesystem while image generation is processed.

By enabling the "Keep local files after uploading them to Azure Storage." option, I can see that all image sizes are generated locally, but still only the original image is added to Azure, indicating it's triggering too early, so that it doesn't know of any other sizes that need to be moved as well.

This happens both when uploading via the media library, or from within the post editor (using the classic editor interface).

Expected behavior
All media files should be uploaded once the intermediary size function has finished running (or re-trying if there's a failure)

Environment information

  • Device: Windows desktop
  • OS: Windows 10 (Version 10.0.19042 Build 19042)
  • Browser and version: Google Chrome (Version 90.0.4430.212 (Official Build) (64-bit))
  • WordPress version: 5.7.2
  • Plugin version: 4.3.2

Additional context
This is running on a WordPress multisite, the plugin is network activated, and all config is provided via constants at runtime.

@Clorith howdy sir, great to see you around here! Thanks for the descriptive issue, we're working on a couple other updates for the plugin in a 4.4.0 release and I've added this to that milestone and hope to have someone from the team dig into this in a bit. That said, if anyone else wants to work on a PR to help here we'll gladly get it reviewed as part of the 4.4.0 release... thanks!

Original guesswork was somewhat incorrect, as the symptoms had me confused without any deep-dive into the code, the end-cause turned out to be incorrect path generations, as resolved by #141 :)

@Clorith awesome, thanks for the deeper dive and PR... I'll work to get that through review and included in the next release!