Editor WYSIWYG does not render images on the frontend that are inserted from magento gallery

[MaximSR]

Summary

WYSIWYG editor images inserted from the native Magento gallery are not rendered correctly on the frontend when Cloudinary is enabled. The image URLs generated by the Cloudinary Magento 2 extension are incorrect (include unexpected path segments / transformations) and return 404, while the base Cloudinary URLs for the same assets work.

This affects at least:

• Product page “Secondary description” (content tab)
• Amasty Promo Banners (banner type: HTML)

---

Affected environment

• Cloudinary base: https://res.cloudinary.com/bigetest
• Extension: cloudinary/cloudinary_magento2 (latest version from releases: https://github.com/cloudinary/cloudinary_magento2/releases)

---

Steps to reproduce

Use case 1 – Product Secondary Description (CMS content field)

1. In Magento Admin, open a product
2. Under the Content tab, in Description, insert an image using the Magento gallery (not via the Cloudinary picker).
3. Save the product.
4. Open the product on the frontend

Actual result

• Image is broken on the frontend.

• The src attribute uses a Cloudinary URL that does not exist, e.g.:

  https://res.cloudinary.com/bigetest/image/upload/c_lpad,d_bigelectric_logo.jpg,dpr_2.0,f_auto,q_auto/v1/media/.renditions/wysiwyg/57-2448x3264_1.jpg?_i=AB
  

Expected result

• Image should be rendered from a valid Cloudinary URL, e.g.:

  https://res.cloudinary.com/bigetest/image/upload/v1/media/wysiwyg/57-2448x3264_1.jpg?_i=AB
  

---

Use case 2 – Amasty Promo Banner (HTML)

1. In Magento Admin, open a banner
2. Set Banner type to HTML.
3. In the banner content WYSIWYG, insert an image from the Magento gallery (again, not from the Cloudinary browser).
4. Save.
5. Open a product page where the banner is displayed.

Actual result

• Image is broken on the frontend.

• Example incorrect URL generated via Cloudinary:

  https://res.cloudinary.com/bigetest/image/upload/c_lpad,d_bigelectric_logo.jpg,dpr_2.0,f_auto,q_auto/v1/media/.renditions/wysiwyg/cat2_191.jpg?_i=AB
  

Expected result

• Image should be loaded correctly from Cloudinary:

  https://res.cloudinary.com/bigetest/image/upload/v1/media/wysiwyg/cat2_191.jpg?_i=AB
  

---

Additional findings

1. The same image exists and is synchronized in cloudinary_synchronisation:

   SELECT * FROM `cloudinary_synchronisation` WHERE image_path LIKE '%cat2_191.jpg%';
   +-------------------------------+----------------------------+
   | cloudinary_synchronisation_id | image_path                 |
   +-------------------------------+----------------------------+
   |                         12070 | media/wysiwyg/cat2_191.jpg |
   +-------------------------------+----------------------------+

   So the source path should be media/wysiwyg/cat2_191.jpg, not media/.renditions/wysiwyg/cat2_191.jpg.

2. The incorrect URLs that the extension outputs for WYSIWYG content have:

   • An added /.renditions/ segment inside the path.
   • Standard transformation string: c_lpad,d_bigelectric_logo.jpg,dpr_2.0,f_auto,q_auto.
   • Result: Cloudinary returns 404 for these paths, while the non-.renditions version works.

---

Hypothesis

It looks like when images are inserted from the Magento gallery into certain WYSIWYG fields, the extension is building the Cloudinary URL from a path that includes /.renditions/ (likely a Magento internal variation path) instead of the base media path stored in cloudinary_synchronisation.image_path (media/wysiwyg/...).

As a result, the Cloudinary public ID generated for those WYSIWYG images doesn’t match any asset, causing broken images on the frontend.

---

Expected behavior

• For images inserted into any WYSIWYG editor (including 3rd party modules like Amasty Promo Banners), the Cloudinary Magento 2 extension should:
  • Resolve the correct base media path (e.g. media/wysiwyg/cat2_191.jpg);
  • Generate a valid Cloudinary URL without the /.renditions/ artifact;
  • Apply configured transformations safely on top of a valid public ID.

---

Request

• Please confirm whether this is a known limitation or bug with handling WYSIWYG content paths and /.renditions/ images.
• Provide guidance or a fix so that:
  • WYSIWYG images inserted from the Magento gallery are mapped to the correct Cloudinary public IDs.
  • The generated URLs match existing Cloudinary assets (e.g. media/wysiwyg/...) instead of media/.renditions/....

If needed, we can provide additional logs, HTML snippets, or screenshots from the staging environment.

[atdcloud]

Hi @MaximSR, thank you for bringing this issue with us. Is it possible for you to send us a screen recording?

[studioraz-git]

Hi @atdcloud here is a screencast for product description case https://www.loom.com/share/4d4c8dd54f84466d90b467ac9fa40a27

[Vdeub-cloudinary]

Hi @studioraz-git , thanks for the recording. We'll forward it to our team and let you know if we need anything else.

[bruckercloud]

Hi Maxim,
Thanks for sharing this — much appreciated.

This is Amit from Cloudinary, PM for our Magento extension. Would you mind emailing me so we can coordinate some time with our development team to dig into this together?

You can reach me at: amit.brucker@cloudinary.com

Thanks again!

[dannyv-cloudinary]

Hi @MaximSR

We'd love to get in touch with you so we can debug this further. Can you please reach out to my colleague via the email above?