#540 - Audio Generation Cleanup / Optimization / Display

[joshuaabenazer]

Description of the Change

Closes #540

How to test the Change

We need to test the entire audio generation / regeneration process along with it's ability to hide/display the audio on the FE using the new display controls.
There are two new filters that allows us to manipulate the initial state of audio generation and the subsequent state of audio generation once it has already been generated. We need to manipulate the filters and review the process to see if it works as expected.

Changelog Entry

Added - Option to hide/unhide audio controls on the FE if the audio exists.
Changed - The audio generation process.

Credits

Props @joshuaabenazer

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[dkotter]

Left one minor comment but things look really good here!

One thing I noticed while testing, and maybe this is expected, but if I create a new piece of content, the Enable audio generation toggle is turned on (which is expected). If I toggle that off and then save the item (either save as draft or publish), the toggle immediately goes back to being on. It does seem to respect the off value though and no audio is generated, but I guess I'd expect the toggle to stay off if I manually toggled it off. It seems to only stay off after audio has been generated.

[joshuaabenazer]

Left one minor comment but things look really good here!

One thing I noticed while testing, and maybe this is expected, but if I create a new piece of content, the Enable audio generation toggle is turned on (which is expected). If I toggle that off and then save the item (either save as draft or publish), the toggle immediately goes back to being on. It does seem to respect the off value though and no audio is generated, but I guess I'd expect the toggle to stay off if I manually toggled it off. It seems to only stay off after audio has been generated.

@dkotter I see what you are saying there. Currently the state of the toggle switches back and forth depending on what the initial and subsequent states are set to relative to if an audio is generated ( subsequent ) or not ( initial ). Again can be changed via the filters too. Wondering if we should keep the initial state to default to false instead maybe?

I would hope that the audio generation takes place only on a publish since a draft post is still incomplete. But it could also make things complicated since we are not storing this data about audio generation, and it is just used as an indication for audio generation on the fly.

We should be able to control the generation for drafts in the rest handler - and similarly for the classic editor but then am not sure if that would be intuitive or not. The wording for the toggle does say publish or update and probably we can then improve the description there to be more clear? We should probably get some more opinions on what users expect during these different usecases and then take a call.

[dkotter]

@joshuaabenazer

Currently the state of the toggle switches back and forth depending on what the initial and subsequent states are set to relative to if an audio is generated ( subsequent ) or not ( initial ). Again can be changed via the filters too. Wondering if we should keep the initial state to default to false instead maybe?

I'm not so much worried about how we handle drafts but does feel like we may get complaints from users that want to toggle off audio generation on a specific piece of content but at the moment, they'll have to remember to turn that toggle off anytime the content is saved.

But maybe that's something we address in a followup PR? Unless you want to handle that here before I merge this in?

[joshuaabenazer]

@dkotter I like the idea of a followup PR once we have some insights from users about this. I think if there is no other feedback for this particular PR then we can get this merged in. Thanks!