Issues with Azure storage

  • Resolved skip405

    (@skip405)


    8 years, 2 months ago

    Hello. Thank you very much for this plugin, it almost worked well for me ??

    The issue I had was that together with Windows Azure Storage for WordPress plugin, the cropped images returned a 404. The full image resolved fine, although it had a strange path to itself. E.g. https://%AZUREID%.blob.core.windows.net/blog//var/www/html/wp-content/uploads/2016/12/%FILENAME%.jpg

    Notice a double slash and a local path in the middle. So whenever there was a %FILENAME%-200×200.jpg (or any other crop) it didn’t resolve the path and returned a 404.

    Not sure if it’s an issue with EWWW Image Optimizer though, maybe it’s an issue with Windows Azure Storage for WordPress or my own setup. If you have a manual or FAQ on how to set it up with Azure, I’ll me more than happy.

    Thanks.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    The Azure integration is pretty much automatic, but perhaps they changed something and the code in EWWW is misbehaving. I’ll take a look either today or next week sometime.

    Plugin Author nosilver4u

    (@nosilver4u)

    I think that particular problem is an issue with the Azure plugin itself.

    I did discover a bug in the bulk scanner when local files have been removed, which potentially affects both Azure & S3 containers. I was able to get that resolved, but then after a bulk optimize, I saw the same thing as you, and what seems to have happened is that the Azure plugin is failing to store the correct path back in the metadata the first time.

    Normally, the ‘file’ value in the attachment metadata is a relative path to the uploads folder, but Azure is storing the full path. When it re-processes the image after EWWW optimizes the image, it is expecting a relative path. Because it accidentally stored the full-path the first time around, it mucks up the image url the second time around.

    I confirmed my findings in the Azure plugin code also. At the beginning of the update_attachment_metadata filter, the plugin stores the relative filename as the value of ‘file’ in the metadata, but then just a few lines later, it overwrites the ‘file’ item in the metadata with the full path. This will naturally result in the exact behavior we saw, because the Azure plugin will again assume that the value of ‘file’ in the metadata is relative, but it isn’t anymore, because the plugin itself overwrote it with the full path the first time around.

    Thread Starter skip405

    (@skip405)

    Thanks a lot for the investigation. I was about to file an issue for them, when I saw you had already done that. That’s what I call true Support ?? You rock!

    Plugin Author nosilver4u

    (@nosilver4u)

    The quirks with EWWW IO were resolved with 3.2.2 yesterday, and they released a new version of the Azure plugin today (4.0.1) which fixes their bug with the mangled paths. Happy Optimizing!

    Thread Starter skip405

    (@skip405)

    Thanks a lot! I’ll give it another go soon ??

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Issues with Azure storage’ is closed to new replies.