Thumbnail generation test false negative (FooGallery v1.9.8)

  • Resolved ellmann creative

    (@ellmanncreative)


    4 years, 8 months ago

    Your image generation thumbnail generation test code and/or resources are is somehow broken, which leads to a persistent alert generated by FooGallery. The contents of the alert are:

    Thumbnail Generation Alert!
    There is a problem generating thumbnails for your gallery. Please check that your hosting provider has the GD Image Library extension installed and enabled.
    If thumbnails cannot be generated, then full-sized, uncropped images will be used instead. This will result in slow page load times, and thumbnails that do not look correct.

    If I go into the settings and run the test manually, I get this:

    Thumbnail generation test failed!object(WP_Error)#4780 (2) { ["errors"]=> array(1) { ["file-not-found"]=> array(1) { [0]=> string(0) "" } } ["error_data"]=> array(0) { } } array(2) { ["ext"]=> string(3) "png" ["type"]=> string(9) "image/png" }

    Interestingly, this seems to be a per-site issue, because I have multiple sites on the same hosting (thus sharing the same PHP instance and config), and this issue doesn’t affect every site – just one of them.

    Loading default settings does not make the issue go away.

    ————————————
    Also, is FooGallery using GD directly, or is it using whatever WP uses? Because if it’s using GD, you should really fix that and port it over to either what WP uses (which will be Imagick most of the time), or to Imagick directly w/ GD as fallback. GD doesn’t respect ICC profiles, so if you put up stuff that isn’t sRGB (like you actually might if you’re a photographer, for instance), your images will end up with bad-looking thumbnails… Unless it’s just the message, in which case – fix the message, because it’s scary. ??

    • This topic was modified 4 years, 8 months ago by ellmann creative. Reason: It turns out that the code itself isn't broken - it's properly failing on a non-existent file; not sure why it chooses that file, or why it's not there, but the title is no longer reflecting the actual issue
Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter ellmann creative

    (@ellmanncreative)

    I actually went into /includes/WPThumb/wpthumb.php to see what file was causing the issue, and the file was /wp-content/uploads/2019/09/woocommerce-placeholder.png – which indeed does not exist at this time.

    It would seem that your plugin got fooled into trying to use that file, for whatever reason. Perhaps you should include a dummy file with the plugin, so that it never fails an unintentional dependency check like this? ??

    Also, that site is the only one I’m using WooCommerce on, so I can’t confirm whether this is a WooCommerce thing, or just a random bug that happened to hit me in particular. It does show an underlying issue in the test though, so I still think it should be fixed – in my opinion, any tests the plugin needs to run should be performed on known-good data.

    I can however see the need to test your plugin’s ability to interact with WP as it does its job, so I can’t really fail you for using an uploaded image… But if such a failure is, as it turns out, possible… then maybe the code could try two-three images randomly before it reports a failure, or… it could possibly fake-upload an image, go through the motions, and then remove the fake once it’s done?

    • This reply was modified 4 years, 8 months ago by ellmann creative. Reason: Added info about this being the only site with WooCommerce in use
    • This reply was modified 4 years, 8 months ago by ellmann creative.
    • This reply was modified 4 years, 8 months ago by ellmann creative. Reason: Included consideration for a possible fix
    Plugin Author bradvin

    (@bradvin)

    hi @ellmanncreative

    Thanks for your detailed investigation for this ticket. It really helps.

    A little bit of history…

    We used to have a test image within the plugin to test thumbnail generation. This did not work in all cases, as images in the uploads folder could have different permissions to images in the plugin folder. We decided to rather use an image in the uploads folder, so we do a search for the first attachment in the media library and use that.

    So it seems that the first attachment in your library is pointing to /wp-content/uploads/2019/09/woocommerce-placeholder.png which no longer exists.

    This is causing the thumbnail generation test to fail, even when it probably works for the gallery thumbs without an issue.

    We also created a setting in FooGallery -> Settings -> Advanced called “Override Thumb Test” which will use an image stored on our CDN as the test image.

    Please enable that setting and run the test again under the Images tab on the settings page.

    A note on WPThumb…

    It uses the built-in image library that is being used by WordPress. Whichever is available in the install it will use. WPThumb also uses Imagick if available and then falls back to GD, which is the same order as WP.

    I will be updating the error message displayed to be more informative in future. I will also update the test code to try the CDN automatically if the resize of the first attachment image fails.

    Thread Starter ellmann creative

    (@ellmanncreative)

    We also created a setting (…). Please enable that setting and run the test again (…).

    Yeah, that works and reports success; that’s a final confirmation of source and scope of the issue.

    —————————————-
    As for testing w/ a local file… Well, there’s more to thumbnailing than just having the GD library, or Imagick, or write access. It’s a multi-step process, and it would make sense for the message to more accurately represent the stage that failed.

    No, the biggest issue I really have with this situation is that handling “file-not-found” is completely and entirely your job as the programmer. ?? Bring to my attention things like broken PHP configurations, broken permissions and the like… but don’t cry to me about missing files that you yourself chose. ;] Find better files instead. ;P

    I mean, I can’t theoretically fault you for not expecting a file-not-found there… but you know what they say… “A good programmer is someone who always looks both ways before crossing a one-way street.” ??

    Though, in all honesty and joking aside, this does expose a possibly bigger issue I may have w/ WooCommerce (why would the file be missing if WP is supposedly tracking it?).

    Thread Starter ellmann creative

    (@ellmanncreative)

    I see this ticket is still open.

    Was this issue resolved?

    Plugin Author bradvin

    (@bradvin)

    hi @ellmanncreative

    I made some changes to the way it does the testing in the latest version 1.9.11.
    I also updated the message and link to docs explaining more info about how it works and how to potentially resolve

    Thread Starter ellmann creative

    (@ellmanncreative)

    Thanks for the update. ?? If it wasn’t already, I’m marking this as ‘resolved’.

    I was also thinking you could probably use cURL (or any other remote access method that lets you perform a HEAD request) to see if the file exists and is accessible. It probably comes w/ its own set of possible issues (follow location? caching? would a redirect cause a 30x or a 200?), but it remains as an option should this issue resurface in the future.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Thumbnail generation test false negative (FooGallery v1.9.8)’ is closed to new replies.