Trouble embedding google slides

[nsuk]

Forum URL: (private)

Hi everyone, 

I seem to be having trouble with embedding google slides into a post on my forum, which I have experienced when embedding google previously.  The slides are set to private, I follow the instruction (File > Publish to the web > publish > copy link > go to the embed icon, select Google Drive > paste link > click embed).  All I seem to get when I post is a blank post. 

Any help greatly appreciated. 

[Craig]

Hi

Would you be able to post a link to the post you made. You can edit the link in your first post, should you wish to keep it private

[nsuk]

Hi Craig,

No problem - here is the link: nsuk.proboards.com/post/163847/thread

[nsuk]

Hello,

I am just wondering if there is an update to this, at all?

Thank you.

[Derek‽]

Sept 21, 2024 2:16:11 GMT -8 nsuk said:

Hello,

I am just wondering if there is an update to this, at all?

Thank you.

ProBoards staff don't work weekends, so you won't get an official response until Monday at the earliest.

However, I, a lowly member here, have gone ahead and figured out the issue. In short, ProBoards needs to update its BBCode parser to restore compatibility. More specifically, the parser is looking for a different URL format from the one Google provides.

ProBoards is expecting something formatted like so:
docs.google.com/presentation/d/e/#####-####_######-#####/pub

Google provides thus:
docs.google.com/presentation/d/#####-####_######-#####/pub

The difference is only e/, but those two characters make a big impact. Without them, the parser considers the URL invalid and won't even generate an iframe on the page. It gives up the ghost and sulks in the corner because "bad URL is bad."

The embed will be generated if e/ is present in the URL, but you'll only get a Google error message in place of the slideshow because it's pointing to an invalid resource. (Note: only Sheets still includes e/ in the embeds; Docs and Slides dropped it from the URL already.)

Also, when a link is pasted into the embed source field, there isn't a closing gdoc BBCode tag generated. This causes any content in the post that's below the embed (whether it works or fails) to be eaten by the parser and disappear.

[rhreiss]

Sept 21, 2024 14:42:43 GMT -8 Derek‽ said:

Sept 21, 2024 2:16:11 GMT -8 nsuk said:

Hello,

I am just wondering if there is an update to this, at all?

Thank you.

ProBoards staff don't work weekends, so you won't get an official response until Monday at the earliest.

However, I, a lowly member here, have gone ahead and figured out the issue. In short, ProBoards needs to update its BBCode parser to restore compatibility. More specifically, the parser is looking for a different URL format from the one Google provides.

ProBoards is expecting something formatted like so:
docs.google.com/presentation/d/e/#####-####_######-#####/pub

Google provides thus:
docs.google.com/presentation/d/#####-####_######-#####/pub

The difference is only e/, but those two characters make a big impact. Without them, the parser considers the URL invalid and won't even generate an iframe on the page. It gives up the ghost and sulks in the corner because "bad URL is bad."

The embed will be generated if e/ is present in the URL, but you'll only get a Google error message in place of the slideshow because it's pointing to an invalid resource. (Note: only Sheets still includes e/ in the embeds; Docs and Slides dropped it from the URL already.)

Also, when a link is pasted into the embed source field, there isn't a closing gdoc BBCode tag generated. This causes any content in the post that's below the embed (whether it works or fails) to be eaten by the parser and disappear.

I think that derek identified the issue, but when I checked yesterday google was returning the link that ProBoards is expecting (docs.google.com/presentation/d/e/#####-####_######-#####/pub).   And things are working

[Derek‽]

Oct 1, 2024 6:05:09 GMT -8 rhreiss said:

Sept 21, 2024 14:42:43 GMT -8 Derek‽ said:

ProBoards staff don't work weekends, so you won't get an official response until Monday at the earliest.

However, I, a lowly member here, have gone ahead and figured out the issue. In short, ProBoards needs to update its BBCode parser to restore compatibility. More specifically, the parser is looking for a different URL format from the one Google provides.

ProBoards is expecting something formatted like so:
docs.google.com/presentation/d/e/#####-####_######-#####/pub

Google provides thus:
docs.google.com/presentation/d/#####-####_######-#####/pub

The difference is only e/, but those two characters make a big impact. Without them, the parser considers the URL invalid and won't even generate an iframe on the page. It gives up the ghost and sulks in the corner because "bad URL is bad."

The embed will be generated if e/ is present in the URL, but you'll only get a Google error message in place of the slideshow because it's pointing to an invalid resource. (Note: only Sheets still includes e/ in the embeds; Docs and Slides dropped it from the URL already.)

Also, when a link is pasted into the embed source field, there isn't a closing gdoc BBCode tag generated. This causes any content in the post that's below the embed (whether it works or fails) to be eaten by the parser and disappear.

I think that derek identified the issue, but when I checked yesterday google was returning the link that ProBoards is expecting (docs.google.com/presentation/d/e/#####-####_######-#####/pub).   And things are working

Yep, testing shows that Google is once again publishing presentations with e/ in the URL path.

However, the format of the unique identifier has changed and you can't just plug e/ into the URL of previously incompatible documents. Anyone wanting to share those presentations will have to re-open them in Slides, re-publish them for web, and grab the new URL it provides. (It doesn't have to be un-published first, just snag the link it provides, which will automatically be updated.)

Of course, this doesn't absolve ProBoards of work necessary on its end. In addition to the closing tag issue, Google has shown that its schema for URL sharing is not set in stone. This unreliability on Google's part means that PB has to be more flexible in what it accepts if it wants to maintain compatibility.