Forum Replies Created

Viewing 15 replies - 1 through 15 (of 83 total)
  • Thanks for the quick reply. The only reason I noticed it was that I was checking stats and wanted to see the date of an episode versus the bump in stats.

    That is the reason why I said the authors would have to give you more advice. The problem is definitely in the SSL situation – Google Podcasts is basically framing the existing content, and secure sites will not display non-secure sites, for any framed content.

    So I don’t know the answer, but I do see the problem, sorry 🙁

    You have a mixed content warning on your site in Chrome, with the feed link that you provided. Google Podcasts is likely kicking it back because it’s not all SSL. I’m sure the plugin authors can give you more advice, but when we had the issue with Google Podcasts, we changed the link we were providing SSP from the absolute path to a relative path and it works every time now.

    We were one of the sites in the other thread with the problem, and we found the solution. As a refresher –

    iFrame (or other code using similar setup) from https site will not display a non-secure element, which is the reason that we found Google Podcasts refusing to play our audio from the absolute path that is default in the episode data.

    We host our podcast on a multisite where the SSL certificate is issued to the master site URL in the admin, although each site has its own SSL on the front end. This is why using the relative path for the episode – /wp-content/uploads/podcastepisode – cured the problem, since Google was able to pull the audio from the secure location RSS feed.

    On a side note, you really should switch to SSL for your website, including your audio feed, there are some other changes coming to Chrome over the next couple of iterations that will create a ton of mixed content warnings for your site and will cause you to have issues getting traffic from Google.

    I just got the same thing, only in English.

    I did the recovery mode login, deactivated Yoast, and then popped it out of recovery mode.

    Then I reactivated Yoast, refreshed and nothing bad happened.

    Not entirely sure what the block comment from WP is about, I’m using Classic Editor/Divi combo.

    If your guests have WordPress built websites, they should be able to use the Audio player that’s built into the widgets along with the url to the episode. They’ll need to remove everything after the ? in order to get it to play.
    We do this with a subset of our own episodes on a different site that we manage, and it works decently.



    We do NOT have this issue.

    I have a copy of 1.19.20 saved if anyone should happen to need it in case of a bad reaction.



    great idea



    We use Divi (theme) on our site with the podcast and have no issues because of it, just as a reference point.

    “Ultimately, if Google handled its HTTPS redirection better it would resolve the issue for everything.”

    HTTPS framing requires HTTPS inside the frame or it won’t work. It’s a bit above Google’s pay grade 😉

    If you’re self hosting, then you can get a free SSL cert from LetsEncrypt, and most of the reputable hosts will allow that. Some of the EIG crap hosts require you to purchase SSL certs through them, which is just another reason to get off their bandwidth and onto something decent.

    Hope that changing the format will work for you –

    @psykro @michaelsattler

    @backpationet You, my friend, are a genius, even though you may not have realized it. The issue here is not a problem with Google, it’s the use of absolute paths for calling assets.

    LSS, if you use the relative paths instead of the absolute paths in your episode URL, you should have no issues – at least as long as you’re using SSL on your site.

    For us, we preload the episodes using FTP and Add from Server, then select the episode from the Media Library when we create it for publishing. So its just a matter of removing the domain and leaving everything after the first /

    Apparently Google is treating the podcast episodes for the Podcast app in the same manner as if they were displaying content in an iFrame. However, https frames cannot serve non-HTTPS content, that’s against the rules and you get a blank display.

    The part that clued me in was the reference by backpationet about the HTTP vs HTTPS, and I had a quick look at how our URL was formatted in the individual episode posts. Once I saw what I thought was the issue, I changed to relative path and voila! The episodes are working just fine in the Podcast app.

    We initially had episodes, at least two, that were playing fine when Google Podcast app launched, so I don’t know if they changed something or if we changed something without realizing it. Oh well, it’s working now.

    • This reply was modified 1 year, 1 month ago by kimstuart. Reason: tag people

    @dancouver – can you check permissions on your files on DO droplet and let me know what they read? We are on Vultr which is same sort of thing, so I’m trying to figure out if this is a permissions problem perhaps (ooh, try saying that three times quickly lol)

    Ok, @psykro I’ve emailed you back with the details on the results and a couple of thoughts beyond what I’m adding in here for everyone else.

    It does stream from your hosting. The most perplexing part is that initially the Google Podcast app did stream from our hosting, but stopped doing so after about 3 episodes or so.

    My process for adding the new audio is to FTP the files in, use Add from Server to put into Media Library and then put into episode using SS. Permissions are 644 rw – r – – r – –

    Couple of additional thoughts –
    Any chance that the process or the permissions are the cause of the problem? Nothing changed from the beginning when it did work.

    As to the hosting – we use Vultr (same as DO, AWS, etc) cloud with our own installation of WHM and cPanel, and we have our own IP addresses, so this isn’t like we’re stuck on some crappy EIG shared account.

    @psykro — Can you do me a favor and resend the last email with the URL in it, I’ve just spent about an hour searching for it and I cannot figure out where it went.

    I’ll get it swapped out ASAP once I have it.

    I will do my best to get to this tomorrow, I have been totally covered up since you and I spoke in email the first time Jonathan — will report back –

Viewing 15 replies - 1 through 15 (of 83 total)