Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author AiO Podcast Studio

    (@aiopodcasting)

    @klaus12,

    Thanks again for the details — we received your email and have replied there, since it was easier to go through your setup that way.

    For anyone finding this thread later: the player is rendered through the_content on our single podcast and episode pages. What Klaus ran into is a compatibility issue with Paid Memberships Pro, where both plugins act on the post content at different points. We are adding explicit support for it in our next update, due next week.

    We will post back here once that release is out.

    Plugin Author AiO Podcast Studio

    (@aiopodcasting)

    @klaus12,

    Thanks for writing in, and for the suggestion.

    The player is already rendered inside the loop on our own single pages. On single podcast, episode, and participant pages the output is attached to WordPress’ the_content filter (priority 11) and it only runs when in_the_loop() and is_main_query() are both true and the queried object matches the current post. It also bails out early when post_password_required() returns true, so a password-protected podcast or episode shows the password form and no player. The same applies to our shortcodes and blocks: whatever you place inside the post content runs through the_content along with the rest of the content.

    Where a player genuinely can appear outside the loop is when it is not part of the post content at all — for example the Episodes widget with the player enabled placed in a sidebar or footer, or a shortcode/block inserted into a theme template part, header, or footer of a block theme. Those areas are rendered outside the loop by design in WordPress, so per-page protection does not cover them.

    There is also a third case worth checking: if a membership or content-protection plugin replaces the post content on the_content at the default priority 10, our filter runs afterwards at priority 11 and would replace that notice on our own single pages. If that is what you are seeing, it is something we can address on our side, and we would like to.

    So this really depends on how the player ends up on your protected page, and we do not want to guess. Could you share:

    1. The exact URL of the protected page where the player is still visible.

    2. How that page is protected — WordPress’ built-in password protection, or a membership/protection plugin (and which one)?

    3. How the player is placed on that page — is it one of our single podcast/episode/participant pages, or a shortcode, block, or widget you added yourself?

    With that we can reproduce it on our test site and tell you exactly what is happening, and fix it if the fault is ours.

    Plugin Author AiO Podcast Studio

    (@aiopodcasting)

    @klaus12,

    Apologies for the slow reply — we were away for our local festival holidays and are just back at our desks.

    And thank you for the kind words, much appreciated!

    Good question, and the answer is yes — this is coming in our next release, due next week.

    A bit of background on why the two are separate today: the categories assigned to a podcast are written into the RSS feed as <itunes:category>, and Apple Podcasts (plus Spotify, which follows the same spec) only accepts values from their own fixed list. Arbitrary WordPress categories in that field would make the feed invalid and the show could be rejected by the directories.

    But that only matters if you’re actually submitting to those directories, and plenty of people run a podcast purely on their own site. So the next version adds a setting — off by default — that enables the standard WordPress categories and tags on podcasts and episodes. With it turned on you’ll get the normal WordPress category and tag boxes on the podcast and episode edit screens, the terms will display on the front-end podcast and episode pages, and clicking one takes visitors to your regular WordPress category/tag archive, alongside your posts, rather than a separate podcast-only listing.

    The part that should answer your question directly: if you’re not submitting to Apple or Spotify, you can simply leave the podcast categories empty. They’re only read when the feed is generated. So in practice you’d be using the WordPress ones instead, which is what you’re after.

    I’ll post back on this thread as soon as the update is live so you know to grab it.

    Thanks again for taking the time to write in — this is exactly the kind of feedback that’s useful to us.

Viewing 3 replies - 1 through 3 (of 3 total)