Images error when uploading to media library

Hi @chasman123,

I can see how disruptive this has been, especially since the images appear to upload but then trigger front end breakage when they are used on products. You have already done solid troubleshooting by testing on staging, disabling plugins, switching to troubleshoot mode, and narrowing this down to a scenario where only WooCommerce is active. That really helps rule out common conflicts and points strongly toward an image processing issue at the server level.

The error message you are seeing usually means the server is struggling while generating image sizes, which relies on PHP memory, execution time, and the underlying image library like GD or ImageMagick. Even though the images are only 1200 × 1000 JPGs, WordPress and WooCommerce generate multiple sizes on upload, and if that process partially fails, it can leave corrupted metadata. That would explain why the image exists in the Media Library but causes layout issues and unexpected output when rendered on the frontend.

At this stage, a few checks are worth focusing on with your host, especially since plugin and theme conflicts have already been ruled out. Ask them to confirm that ImageMagick or GD is installed and functioning correctly, that PHP memory and max execution time are sufficiently high for image processing, and that there are no server level errors in the PHP error logs at the exact time of upload. These server side details are outside WooCommerce’s direct control, but they are critical for stable media handling.

It would also help to see your WooCommerce system status report, as it gives visibility into memory limits, image library availability, and environment details. You can copy that from WooCommerce, Status, then System Status, and share it here using a paste service like https://pastebin.com so it remains accessible.

You may also find this guide useful for background on how WordPress handles images and what typically causes upload and processing failures: https://wordpress.org/documentation/article/image-size/

Once we can review the system status details, we can better pinpoint whether this is a configuration limit, a missing image library, or something the host needs to adjust on their side.

Hi @chasman123,

Thank you for sharing the system status report, I understand how important it is to get clarity at this stage and I appreciate you taking the time to provide it. I have reviewed the report carefully and nothing stands out as a misconfiguration or conflict on the WooCommerce side that would directly explain the image processing behaviour you are seeing.

One thing I did notice is that the site is currently running WooCommerce version 10.3.7, while the most recent stable release is 10.4.3. While this alone may not be the root cause, staying up to date ensures you have the latest fixes and improvements, especially around performance and compatibility. You can review recent releases here https://developer.woocommerce.com/releases/

Since the report does not show any obvious WooCommerce level issues, I want to double check whether you have been able to follow up with your hosting provider as previously recommended. Specifically, confirming their findings around image processing libraries like ImageMagick or GD, PHP memory limits, execution time, and any related errors in the server logs during image uploads would be very helpful in narrowing this down further.

Let me know where things stand with your host and we can take the next step from there together.

Hi @chasman123,

I appreciate you sharing that update and it is great to see the next steps already in motion. Getting the live site aligned with the tested version and escalating things with Bluehost is a solid approach, and it should help surface any server level details that were not previously visible.

Please feel free to come back to this thread once you hear back from Bluehost’s support team, especially if they share anything around image processing libraries, PHP limits, or server logs. I will be happy to review their feedback with you and help decide the best next step from there.

Looking forward to hearing how it goes and we can continue from there together.

Hi @chasman123,

I can see how draining this has been, especially after testing across different machines, networks, image sizes, and even files that previously worked, and still running into the same behavior. Given everything you have already done, your assessment continues to make sense and this is strongly pointing away from file size and toward a deeper server level image processing issue.

To help us fully close the loop on the application side while you continue engaging Bluehost, I would like to ask for one final confirmation using a full theme and plugin conflict test. Even though you already tested in troubleshoot mode, this specific test helps rule out any unexpected interactions at runtime. On your staging site, please temporarily switch the theme to Storefront and deactivate all plugins except WooCommerce, then try uploading a new image to the Media Library and using it on a product. If the error still occurs under those conditions, it clearly confirms this is not being triggered by a theme or plugin layer: https://woocommerce.com/document/how-to-test-for-conflicts/.

At the same time, when replying to Bluehost, it will help to be very direct that the failure is happening during image processing after upload, not during the upload itself. Even small JPG files will trigger multiple image size generations, and if GD or ImageMagick is misconfigured, timing out, or failing silently, WordPress can end up saving broken image metadata. That aligns closely with what you are seeing where images appear in the Media Library but cause frontend output issues once used.

It is reasonable to ask them to confirm whether GD or ImageMagick is installed and functioning correctly, whether there are PHP errors logged at the exact time of upload, and whether any recent server side changes, limits, or security rules could be interfering with image processing.

Once you have the results of the Storefront plus WooCommerce only test, or any concrete feedback from Bluehost, feel free to share it here and I will gladly review it with you so we can move this toward a clear resolution.