Google Blogger image URL format needs updating

[explosiveaction]

Hi team,

I've noticed that images uploaded to Google Blogger via OpenLiveWriter now show as broken links / 403 forbidden.

The fix for me has to do a find-replace on the HTML source for:
https://drive.google.com/uc?id=

And replace with:
https://lh3.googleusercontent.com/u/0/d/

StackOverflow comments suggest a different URL however be wary as some require the end user to be authenticated with Google for them to load. The above one does not.

Refer to the photos in this post (not the cover at the top, the in film screenshoots) to see the new URL working:
https://www.explosiveaction.com/2024/01/the-cutter-2005.html

Can this be updated in the application?

Cheers
Simon

[msummerfield]

This is effectively a duplicate of #958. The same suggestions, and others, are in that discussion, but it has become lengthy and so they are hard to find. I hope this comment acts as a useful summary of some of the key points of that discussion.

The problem has arisen because Google has changed the way Drive handles cross-site requests for documents. Google's position is that this is intended behaviour, that Drive is not intended or advertised as a web hosting platform, and that they are therefore not going to 'fix' it. (See https://issuetracker.google.com/issues/319531488)

I believe that the suggested replacement URL here is not the best option. Generally, the '/u/num' elements refer to a logged-in Google user. (If you are logged into multiple accounts at once, they can be distinguished by different values of the num component.) It is true that '/u/0' does work, so it may be that Google treats user '0' as special, but I am not sure that there is any guarantee that this might not change in the future. Dropping this part, i.e. using https://lh3.googleusercontent.com/d/[id] works, and should be independent of whether the end user has, or is logged into, any Google account. Having said that, comments from developers on the IssueTracker discussion suggest that Google does not consider accessing Drive content via googleusercontent.com URLs to be an officially supported use of its services, so this could also stop working at some point in the future. But for now, at least, it is a solution.

In the discussion on #958 some users have suggested using JavaScript to update existing links on the fly. This is an effective solution if updating all your existing links is impractical in the short term. I have done this on my blog using the following script, which I think is a little cleaner and more flexible than the implementation in the other discussion:

<script>
//<![CDATA[

function extractId(url) {
    // Regex to match Google drive URLs and extract a group consisting of the ID
    var rx = /drive.*google\.com\/.*id=([0-9][a-zA-Z0-9_-]{32,43})/g;
    var idMatch = rx.exec(url);
    // Return the ID if there is a match, otherwise return an empty string
    if (idMatch) {
        return idMatch[1];
    }
    return '';
}

function rewriteGdImg(e) {
    // Get all the img elements
    var imgs = document.getElementsByTagName('img');
    // Loop through the img elements and replace the links accordingly
    for (var i = 0; i < imgs.length; i++) {
        var gdId = extractId(imgs[i].src);
        if (gdId) {
            imgs[i].src = 'https://lh3.googleusercontent.com/d/' + gdId;
        }
    }
}

// Call the function immediately during page load
// EDIT 2024-03-01 replaced 'window.onload = rewriteGdImg;' with the following. This causes
// the image references to be replaced immediately after the DOM content is loaded, which is
// *before* the browser attempts to load the broken images. This almost completely eliminates
// the period during which broken image icons are visible. Adding an event listener is also better
// practice than using the 'onload' property.
document.addEventListener('DOMContentLoaded', rewriteGdImg)

//]]>
</script>

I have inserted this into my blog template, immediately before the </head> tag (which requires the use of the //<![CDATA[
and //]]> lines, to prevent the server from trying to interpret the code as template instructions). But this same code can alternatively be added via an HTML/JavaScript widget, as described in the other discussion.

Cheers,
Mark

[explosiveaction]

Thanks for this, Mark. I hadn't seen the other post, but you are right it is the same issue.

Interesting to note about the /0/ prefix, I will make the change and see if it still works for me. I am manually updating my blog posts (only about 20 - the ones made prior to OpenLiveWriter were NOT affected).

Given Google marked this as Won't Fix, is there a way to update OpenLiveWriter to publish images to the approved Blogger image hosting rather than upload to Drive?

Cheers
S.

[msummerfield]

IIRC, OLW was previously updated to use Drive for image storage because Google changed something that broke publishing of images however it was being done at the time (I think this was via Google Photos, because I can see many of my earlier blog images, prior to 2019, in my photo album). I don't know what the change was, or why the OLW devs settled on using Drive for image storage instead. The Blogger API does not support direct publishing of images; they need to be stored somewhere first, and are then referenced by the corresponding URL in the post.

Google itself, i.e. in the Blogger web interface, uses the googleusercontent CDN to store uploaded images, but I am not sure that there is any way for 3rd party apps (at least outside the Google Cloud Platform) to access this CDN directly. As currently implemented, images stored in Drive or Google Photos are stored here 'in the background'. But that is a Google implementation detail, which is probably why their developers cannot guarantee that this will always be the case. Having said that, Google makes such extensive use of the googleusercontent CDN that it is hard to imagine that they are likely to change this.

[explosiveaction]

Thanks Mark, I figured it was something like that.

Many years ago circa 2015 I used to use a Mac and had a similar blog-writing application (no idea what it was called now). The resultant uploaded images were this format: https://1.bp.blogspot.com/-o5ghgmIuDp0/VXbRLMbOdbI/AAAAAAAAIMM/szEpqlS2n_s/s320/armed-response-01.jpg

A long time ago so perhaps whatever they did then is no longer workable.

S.

[nelsonkodama]

@msummerfield, I am a common user, not a developer, but I remember seeing a way to upload images to Blogger by using a draft post. It is because images are stored in "blogger.com/mediamanager/" permanently (and image links are generated in the HTML code) just by pasting or importing an image into the Blogger editor. By the way, "blogger.com/mediamanager/" has unlimited space.

If I am remembering this right, I think the OLW developers could make OLW generate a temporary "base" draft post in which images are "posted" and each generated image link is "captured" by the OLW.

[terenceluk]

@msummerfield thank you so much for the javascript fix!

[msummerfield]

@terenceluk you are welcome!

I have identified a small improvement. Replace window.onload(rewriteGdImg) with document.addEventListener('DOMContentLoaded', rewriteGdImg). This causes the references to be updated before the browser tries to load the broken images, avoiding (most of) the delay before the correct images are loaded. I have updated the code in my previous comment accordingly.

[terenceluk]

@msummerfield wonderful. Thank you for continuing to provide us with your improved recommendations. I've just tested it and can confirm it is working for me as well.

Now if only I spent time looking into this before upgrading to the 2TB plan thinking my 98% Google Drive utilization was the cultprit :)