[gabrielcld2]

Fixes two issues with the Cloudinary Gallery block preview in the block editor.

The issues

The preview stays blank in the iframed editor. With the editor canvas rendered in an iframe (always the case as of WordPress 7.1), images picked for a Cloudinary Gallery block are saved and the published page shows the gallery, but the block in the editor stays on the empty Upload / Media Library placeholder, with no console error.

• The Product Gallery library (cld-gallery) was only enqueued in the outer admin document.
• The block's container is rendered inside the editor-canvas iframe, so the widget looked the selector up in the wrong document and silently drew nothing.
• Passing the container element itself doesn't work either: the widget validates its config with checks bound to its own frame and rejects objects created in another one.

The preview ignores the block's Custom Settings. Custom Settings applied on the published page but never in the editor preview.

• customSettings is stored as JSON text, and the editor spread that string into the config, adding one numbered key per character.
• The widget rejected that config, and the fallback rendered without the custom settings.
• The front end decodes the JSON before merging it, so only the page got them.

The solution

• Gallery::block_editor_styles() already runs on enqueue_block_assets, which WordPress uses to collect the editor canvas assets. It now also enqueues the gallery library there, using the existing maybe_enqueue_scripts() check and cloudinary_enqueue_gallery_script filter.
• The block's Edit takes a ref on the container and renders with the galleryWidget of the window that holds it. When that is another frame, the config is rebuilt with that frame's JSON.parse so it passes the widget's validation. The container stays a CSS selector, resolved in the widget's own document. If the library is still loading in the canvas, rendering waits for the frame's load event.
• The preview now always uses the connected account's cloud name and custom domain settings from CLD_GALLERY_CONFIG, as the front end does in prepare_block_render(). Before, they were only set on new blocks: a block with no or a stale cloudName (e.g. created outside the editor) previewed broken images, and existing blocks ignored the custom domain. This only affects what is rendered; the saved block is unchanged.
• In a non-iframed editor the container's window is the main window, so the behaviour is unchanged.
• A new parseCustomSettings() util decodes Custom Settings (invalid JSON, or JSON that isn't an object, is ignored). They are merged one level deep over the config, matching wp_parse_args() on the front end: a transformation in Custom Settings replaces the block's own crop and background, as on the page.

Behaviour changes

• The editor preview now applies Custom Settings, so mistakes in saved Custom Settings that were silently dropped in the editor now show there, as they already did on the published page.
• The preview of existing blocks now loads images through the site's custom domain when one is set, and always from the connected cloud.
• Other editor iframes now render the gallery too: the Tablet/Mobile device preview, the site editor, and inserter/pattern previews. They were blank before.
• On WordPress 6.3 to 7.0, the post editor isn't iframed for this block (block API v2), so the preview takes the same path as before.

QA notes

1. On WordPress 7.1, connect the plugin and create a post with a Cloudinary Gallery block.
2. Click Media Library, pick two or more images and Update gallery.
   • The gallery preview renders in the block.
3. In the block's Custom Settings, enter {"transformation":{"effect":"grayscale"}}.
   • The preview turns black and white (image URLs contain e_grayscale).
4. Save and view the post.
   • The published gallery matches the editor preview.

A new e2e test in cloudinary-gallery-delivery.spec.js opens a gallery post in the editor and checks the preview renders inside the editor canvas, with every image carrying the Custom Settings transformation. Its block markup has no cloudName, so it also covers the delivery settings fallback. It fails on develop on each of the two issues.