@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.
