A lot of posts on my forum are mixes. If the mix is posted at the top of the thread, and the user hits play, and then scrolls down the page to join the discussion and read the responses, eventually the player is unloaded, and this causes the mix to stop playing. Not ideal.
Is there a way to either specify how many posts before posts are unloaded, or remove this feature entirely?
Edit2: if this is not possible with stock discourse, I am open to hiring someone to program a discourse plugin that adds this feature. I have hired programmers from this forum in the past and always pay a fair rate, and pay deposit in advance, and final payment immediately upon completion.
Interesting use case. You definitely donāt want to stop Discourse from offloading any posts, as this is core functionality intended to prevent browser crashes and computers catching on and such.
But maybe itād be possible to prevent a single post from being offloaded, while ditching the rest like normal.
Another possible way to solve this might be to prevent only the music player from being unloaded, conserving that stream somehow.
Honestly, i feel like this is a bit extreme. The way that system unloads posts is immediately when the go out of view. A browser can definitely handle having a bit of post history. I understand the need for cloaking with a really long thread, of 100s of posts, but I donāt see the need to begin cloaking after only 1 post has scrolled out of view.
As a plugin naturally, I find fbās implementation pretty annoying too since itās on all the time. But the only thing worse than having sound cut out when you scroll away from the player is having sound playing in your browser and not knowing where itās coming from.
Well iām not advocating for auto playing hidden audio, this is audio the user interaction requested to start playing. Iām only trying to avoid a sudden stop of this audio on scroll.
I agree with @codinghorror though, that floating video thing just seems like a bit much. Itās something i would expect to see on a really spammy news website. I would prefer if the post just stayed where it was, and simply did not cloak on scroll.
Is this something that could be accomplished with discourseās plugin functionality? or would this involve some hacks to discourse core to accomplish it?
We are fine with core Discourse to have the smarts not to cloak posts with oneboxes that have currently playing sound.
Technically, there is no simple way to ask the DOM: āhi DOM is anything playing in element #tā so this means we need to be a specific change to various oneboxes to add this info so we could decide if to unload or not.
If you can get someone to build it cleanly we would be more than happy to consider the PRs required.
Yeah, now that i think about it, i donāt think you could ever know if a soundcloud player is playing, those are usually iframes, and therefore part of the shadow dom, and completely out of scope. But I think perhaps a suitable work around would be exposing an admin interface that had a bunch of settings like:
never cloak posts with youtube oneboxes
never cloak posts with soundcloud oneboxes
ā¦ etc
unless you are suggesting an alternative that is more elegant than this?
@gdpelican is this something i could hire you to build? I was quite happy with your work last time.
If wiring all the APIs is too hard I would be fine with a site setting of ādonāt cloak posts with potentially playing mediaā, since the count is so low it probably makes no diff. Then all onebox needs to do is surface the fact that a onebox is āplayableā by adding something like a playable class to the element.
Very good point, i overlooked the fact that discourse uses the HTML5 widget and not the iframe player for soundcloud. This is definitely the more correct solution, and i think with these types of things it is best to take the most accurate approach. My main focus here is with the soundcloud onebox, but perhaps it will lay the groundwork to have other one boxes added along the way in the future.
I appreciate the offer, but that forum does not make anywhere near that kind of money in a year, so it is simply not realistic for me to make that kind of decision, unfortunately.
Thats the problem with ruby. php devs are a dime a dozen. iām sure thereās plenty on my forum. But ruby? ruby devs are like a rare gem. Infact iām personally a developer full time, i work mostly with python and javascript. Iāve dabbled a bit with ruby, but iām no where near good enough to consider submitted a PR. If i did i think it would be best described as a steaming pile of monkey and immediately rejected.
What if i sign up for 1 month. but donāt really use it, so you donāt actually have to actually set up the site, just make this patch. @codinghorror
and such.
and immediately rejected.