GD2 not working in WYSIWYG

[barbazul]

I am getting hundreds of daily emails from different websites I manage with the error "
Unsupported image format."

The error is triggered every time a CMS page or block is edited in the admin

The root of the problem is the Gd2 adapter calling getimagesize() on an "http://" wrapper in an environment where allow_url_fopen is false (as it is for most shared hostings).

getimagesize() logs an error and returns false, then _fileType does not get set which leads to an exception in line 150 of Varien/Image/Adapter/Gd2.php

A possible solution mentioned in the forums is to download the image using cURL. But I don't think accessing the image via http:// makes sense for most cases, since the images are usually located in the media/wysiwyg/ directory within the server.

I tried changing Mage_Adminhtml_Cms_WysiwygController to remove the URL part and it seems to work fine, but I'd have to make more tests.

        $url = Mage::getModel('core/email_template_filter')->filter($directive);
        $url = str_replace(Mage::getBaseUrl('media'), '', $url);
        $url = Mage::getBaseDir('media') . DS . $url;

[barbazul]

After almost 2 weeks I can confirm the errors stopped and the WYSIWYG is working as expected (it wasn't before this fix)

I can go ahead and convert this into a pull request but it feels way too hacky for me.

Maybe I could add a check for allow_url_fopen ?

Is there any valid case that I am not considering where the image won't be available in the local filesystem and therefore it would make sense work around allow_url_fopen using cURL?

[verklov]

@barbazul , since we usually consider images as those stored on the server, are you talking about images stored somewhere on external resources? We are trying to understand the case that would require handling images in the way you suggest. Could you please provide a real life example?

[barbazul]

@verklov The code is handling images as external resources even when that is not the case. That is my point, it usually isn't the case. The most logical way to handle local files is to open them using the filesystem and not an external URL, that's why I am replacing the BaseUrl for the BaseDir.

[verklov]

@barbazul , the team will investigate on this issue. We will update you once the analysis is complete.

[greggh]

I had to apply this fix to get the wysiwyg working. It is now working as expected.

[verklov]

@barbazul, the team reported that this issue refers to Magento 1.x rather than Magento 2. If this is true, please report this issue to the Magento 1.x bug tracker (http://www.magentocommerce.com/bug-tracking). Make sure you are logged in to magentocommerce.com prior to following the URL in brackets.
Please close this issue as not relevant to M2. Thank you!

[verklov]

We are closing this issue as not relevant for Magento 2. Please report the issue you have found to the Magento 1 bug tracker.
Thank you!

[magento-engcom-team]

Hi @barbazul. Thank you for your report.
The issue has been fixed in #28072 by @Usik2203 in 2.4-develop branch
Related commit(s):

• 034af404deaa448c6ae660166912b0c40dfc7b12
• 7e6e0239c9895982b4bb1577412b0018beef1361
• 81737c084b0b80b48cf5b3359e3b145c64aa54f1
• 120a105b5adb6fbc4d35a0067d72aa1975acccc5
• 035c1577d0e5dee7c102375cd2bdba0f1542c85f
• 8ed5018fda262de3fb337fc886daaede98122f96
• cea930b4d7549bcf476e621ad11ffbfa4847e0e6
• dabbd3c07dbc5ee4c09b785f3f315b4fd3c29fa1
• f6ce31d43aa8316ff59821c508d7b54c734bcee9
• a2f28d83e8ceab42e60505af371d3e5905ee1d65
• 233b695c4f55b1a4c14009ecc13ced4658d5b868
• d127c98a404e3d5e393e14157cd71b41b0df8ae7
• d9748d2d6eecb98b6eca36b5aa9b7602b6bf237f
• d994276cbab26239732d64b8c313a38eac13f01c
• 938e43bfae3774afde30523951aa9edd27778ec3
• d339ae8ec16a96edcaf6927376a3a0c179826a76

The fix will be available with the upcoming 2.4.1 release.