Relative scheme images no longer display in the editor

[peterwilsoncc]

Description

In WordPress 6.3 and the current version of the Gutenberg plugin, 16.6.0, images with relative schemes are not displayed correctly in the block editor. On the front end they render as expected.

In the editor, the images are shown as a broken image and -- browser dependent -- the alt text shown in it's place.

Step-by-step reproduction instructions

1. Install WordPress 6.3 locally
2. In the wp-config file, define a relative content URL constant: define( 'WP_CONTENT_URL', '//example.local/wp-content' );
3. Create a post in the block editor
4. Insert an image block
5. Upload an image to the image block/library
6. The image fails to load
7. Preview the post in a new tab: the image does display
8. Switch to the code editor
9. Modify the image URL to include the scheme
10. Exit the code editor
11. The image now displays

Screenshots, screen recording, code snippet

WordPress 6.3 (with and without the latest version of Gutenberg active)

WordPress 6.2 (without Gutenberg active)

Environment info

• WordPress 6.3
• Browsers: Reproduced in Firefox, Safari and Chrome (all latest versions)
• OS: macOS
• Virtual machine: https://github.com/chassis/chassis on VirtualBox
• Home URL: example.local
• Site (WP) URL: example.local/wp (ie WordPress is running in its own sub-directory)

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[tambourine-man]

Same here, basically makes using relative path in WP_CONTENT_URL impossible.

[Pat-Relentless]

Also have this issue if you define a gutenberg template for a post type that uses an image:

"template": [
[
	"core/cover",
	{
		"url": "/wp-content/uploads/2023/11/image.jpg",
		"id": 38,
		"dimRatio": 30,
		"overlayColor": "forest-green",
		"layout": {
			"type": "constrained"
		}
	},

I suspect this has something to do with the editor being rendered in an iframe where the src starts with "blob". Likely a security issue, but would love to be able to use relative image urls in a block template...

[cweiske]

My use case is to use relative URLs in block.json example attributes, so that the block preview happens with matching images instead of generic ones I had to find on the internet.

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 3,
    [...],
    "example": {
        "viewportWidth": 800,
        "innerBlocks": [
            {
                "name": "mytheme/block",
                "attributes": {
                    "className": "width-50",
                    "imageurl": "/wp-content/themes/mytheme/assets/images/tesla.jpg"
                }

[nicolasleroy]

I'm using image URLs like this "/_images/wp-uploads/2024/06/.....webp".
Up until now, they were loaded fine in the editor ; since the recent upgrade to Wordpress 6.6.2, they are not displayed in the editor anymore, but are still correctly displayed in the frontend.

Any workaround possible?

[nicolasleroy]

Here is an ugly workaround that works for my use case:

FUNCTIONS.PHP:

function enqueue_custom_editor_script() {
		if (is_admin()) {
			wp_enqueue_script(
				'custom-editor-script',
				get_template_directory_uri() . '/js/custom-editor.js', // Adjust the path as necessary
				array(),
				null,
				true // Load in the footer
			);
		}
	}
	add_action('admin_enqueue_scripts', 'enqueue_custom_editor_script');

CUSTOM-EDITOR.JS:

document.addEventListener('DOMContentLoaded', function() {
    const observer = new MutationObserver(function(mutations) {
        mutations.forEach(function(mutation) {
            mutation.addedNodes.forEach(function(node) {
                if (node.nodeType === 1) { // Ensure it's an element node
                    // Check if the node itself is the iframe
                    if (node.tagName === 'IFRAME' && node.name === 'editor-canvas') {
                        handleIframeLoad(node);
                        observer.disconnect(); // Stop observing once the iframe is found
                    } else {
                        // Check if the iframe is a descendant of the added node
                        const iframe = node.querySelector('iframe[name="editor-canvas"]');
                        if (iframe) {
                            handleIframeLoad(iframe);
                            observer.disconnect(); // Stop observing once the iframe is found
                        }
                    }
                }
            });
        });
    });

    observer.observe(document.body, {
        childList: true,
        subtree: true
    });

    // Initial check in case the iframe is already in the DOM
    const initialIframe = document.querySelector('iframe[name="editor-canvas"]');
    if (initialIframe) {
        handleIframeLoad(initialIframe);
        observer.disconnect(); // Stop observing since the iframe is already found
    }

    function handleIframeLoad(iframe) {
        iframe.addEventListener('load', function() {
            console.log('Iframe fully loaded:', iframe);
            var iframeDocument = iframe.contentDocument || iframe.contentWindow.document;
                        
            // Select all <img> elements within the iframe
            var images = iframeDocument.querySelectorAll('img[src^="/_images/wp-uploads"]');
                        
            // Loop through each image and update the URL
            images.forEach(function(img) {
                var originalUrl = img.getAttribute('src');
                var newUrl = window.location.origin + originalUrl;
                img.setAttribute('src', newUrl);
            });
        });
    }
});

[Soean]

I created a pull request in #66751 that fixes this issue.

[technopagan]

From the PR discussion, I'm gathering this will be addressed in WordPress release version 6.8? I cannot find any reference to PRs 66751 nor 68024 in https://core.trac.wordpress.org/report/6

I'm impacted by this bug and would like to assess whether it's worth waiting for the proper fix or if I should implemented the aforementioned workaround.

[Soean]

It's now included in the Gutenberg Plugin and will be released in WordPress 6.8 (April 15, 2025)