Feature Request: Persistent Player (Continuous Playback)

I know this was asked about over 3 years ago (https://wordpress.org/support/topic/persistent-player/) while @podcastmotor mentioned it was more or less on the roadmap for this plugin. I suppose I’m wondering what the status of this feature is at this point and/or what the outlook for that being implemented either officially or through other means.

Any update/info?

Again, the ideal scenario would be to have it so the player is probably affixed to some part of the browser window (when enabled) that then keeps the playback status & controls for whatever’s playing that stays persistent as the visitor navigates to different pages on the site. Meanwhile, the inline players essentially get turned into “Play Now” buttons that then swap out what’s currently playing in the persistent player (per the inline player then not really making sense at that point [per the common convention for music/audio apps that have a persistent playback control.])

Offering the popout player for having it be in a new window is a decent option, but visitors commonly don’t like having to manage multiple windows for one site & then likely looks odd if the browser opened it in a new tab instead of a popup window (while then not having persistent playback unless utilizing this, currently).

I can see two approaches:

1. The near-continuous option (audio would stop during page navigation) that’d be more likely to work for a given site/theme & be simpler to implement would be to have it so the persistent player utilizes cookies (or similar) to store the current audio file URL, playback status, playback position, related metadata, potentially have a history of previous audio URLs played, etc. where it does the full page reload like usual, but it then resumes playback & everything once the new page has loaded.
2. The more aggressive (while totally seamless) approach would be to utilize history.js (https://github.com/browserstate/history.js/) or similar (possibly just using the native browser History API with no need for older browser support provided by history.js) where it’s effectively creating what https://wordpress.org/plugins/advanced-ajax-page-loader/, https://wordpress.org/plugins/ajaxify/, and others looked to provide where navigating pages of the site uses AJAX to swap out the main content area while leaving other areas untouched.

   I wonder if there’s a way to have it grab full page of content except for what’s in a particular element (as well as scripts, etc.) for a substantial page swap while retaining what’s needed. Otherwise, I’m guessing there’d need to be a site admin setting for establishing the selector(s) being swapped out when clicking a link (to then be updated via AJAX). Side note, I wonder if a comma-separated list of selectors could become a loop where the one AJAX call (on link click) is able to swap out those elements & their contents individually if they have multiple areas that might need to be updated & the resulting AJAX had matching selectors in its result.

   I think it’d be fair that forms (at least for now) wouldn’t need to be accommodated as it’s really just links when it comes to what’s more likely to interrupt playback (forms often having AJAX submission of their own to not get in the way.)

   Of course, the site/theme is likely going to need its JavaScript to be updated in various ways to accommodate this AJAX-based page navigation. Hopefully, it can be done in a way where as little code as possible would need to be changed to accommodate this behavior (within reason [look for new JS code & use getScript or similar to then call it as needed, see if stuff that’s called on window/document ready/load re-trigger on the new page, stuff that targets a specific selector also check for that selector on the new page, etc.]… but I’d hate for pretty much the majority of all WordPress plugins break as a result of this behavior change if there then isn’t a way to accommodate for / adapt their behavior without them needing to add their own support for this.)

Funnily enough, framesets would actually make this whole thing simpler, but they’ve been deemed obsolete by W3C due to accessibility & other issues.

I could then see the first two options actually work together where the near-continuous option can be helpful even with the fully seamless setup as someone might navigate away from the site & come back and be happy to see their playback status is just as they left it. Maybe starting with that would make sense while then making it more seamless can be done after that (or re-evaluated further.)

Is it not reasonable to facilitate as a plugin at this moment?

Of course, let me know if it turned out this feature really is more troublesome than it’s worth (I’d settle for the near-continuous option above if it’s just the totally seamless option that’s an issue). At that point, it should probably be noted that seamless playback really should be handled at the theme-level where the theme should utilize the History API / Frontity (https://frontity.org) / etc. to make page navigation seamless on its own

That said, it might make sense for Seriously Simple Podcasting to offer the seamless player styling, play now links that go to the one player, etc. while then just not needing to worry about the site’s navigation so those that add the seamless behavior of the page navigation themselves can use this.

What might be the best for now?

That kinda sounds like the near-continuous option #1 from above in terms of what should be offered where developing that one plan would make it near-continuous for everyone while supporting those wanting full seamless (that have/build a theme that handles the seamless aspect of things on its own) while then even possibly leading into self-contained seamless playback being added directly to the plugin later. Of course, keeping the popout player as an option.