Move text-to-speech audio generation to Action Scheduler

[rahulsprajapati]

Description of the Change

Text-to-speech audio generation is no longer run synchronously during the REST “generate audio” request or when saving the post. It is offloaded to Action Scheduler so that:

• REST and save don’t block: The API and post save return immediately; synthesis runs in the background.
• Timeouts are avoided: Long or slow TTS requests no longer risk PHP/HTTP timeouts.
• Duplicate work is avoided: Before enqueueing, the code checks for an existing scheduled action for the same post via as_has_scheduled_action() and skips if one exists.
• Fallback when Action Scheduler is missing: If as_enqueue_async_action is not available, behavior falls back to the previous synchronous flow via a new generate_text_to_speech_audio( $post_id ) method.

How to test the Change

1. Edit a new post (or one without tts audio already generated)
2. Check the "Enable audio generation" toggle in ClassifAI panel
3. Save the post.
4. Confirm the ClassifAI panel/meta box shows “Audio generation is in progress.” and the request/save finishes without waiting for synthesis.
5. Wait for the scheduled action to run (or run the queue manually if your environment supports it).
   • You can go to "Tools" -> Action Scheduler page to look for this job.
   • Meanwhile Trigger save post again for the same post and confirm no duplicate job is created (e.g. check Action Scheduler list for that hook + post ID).
6. Reload the post and confirm the audio is present and the panel/meta box shows the normal controls and audio player.
7. Optionally run any existing ClassifAI tests and confirm they still pass.

Changelog Entry

Changed – Text-to-speech audio generation now runs asynchronously via Action Scheduler when available, with a synchronous fallback and duplicate-job prevention.

Credits

Props @rahulsprajapati, @dkotter

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

[dkotter]

Note I've pushed a couple commits to ensure Action Scheduler is properly loaded when the TTS Feature is turned on and to ensure we set the proper current user so permission checks pass.

But in my testing, I never saw the message that lets you know processing is happening. I see that's supposed to be happening: Audio generation is in progress, but that never showed for me.

In addition, would be great if things updated dynamically with no need for a page refresh. Right now you have to refresh a handful of times and eventually the processing is done and you see the audio player but would be great if we could continually listen for processing to be done and update the UI as needed

[dkotter]

But in my testing, I never saw the message that lets you know processing is happening. I see that's supposed to be happening: Audio generation is in progress, but that never showed for me.

Quick follow up. Tested a bit more and found out it was a bug in how we register meta, in particular if used on post types other than post (I was testing on a page). I've pushed a fix for this and I am seeing the processing message now. That said, you still have to refresh to see the final result and it would be great if it could auto update the UI once that is done.

Also could use the same fix for the error message. I've pushed a small fix for that now as it was previously only showing during the save event, so if an error happens now, it will never render. This renders now but again, only if you refresh the page.

[peterwilsoncc]

Just a couple of notes inline.

The main one is about including a cap check before scheduling the task given the new changes to the generate function.

When testing with the classic editor, I noticed that the status doesn't update once the audio is generated, it sticks with the in progress message.

It's the classic editor so happy if that's intentional.

[peterwilsoncc]

Before scheduling the job, I think it would be best to do a cap check: if ( ! current_user_can( 'edit_post', $post_id ) && ( ! defined( 'WP_CLI' ) || ! WP_CLI ) )

By the time this part of the function is reached, I think it's been checked but it wold be good to have it here as a little protection for our future selves if it gets moved.

[dkotter]

So we do already have a current_user_can check in this function a few lines above:

if ( ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) || ! current_user_can( 'edit_post', $post_id ) || 'revision' === get_post_type( $post_id ) ) {
	return;
}

Are you saying we should add an additional check here? Or move that check down to here?

[peterwilsoncc]

So we do already have a current_user_can check in this function a few lines above:

Sorry Darin, we really do. "In my defense, I have none."

[dkotter]

When testing with the classic editor, I noticed that the status doesn't update once the audio is generated, it sticks with the in progress message.

It's the classic editor so happy if that's intentional.

I didn't change how things work in the classic editor and I think that's fine for now. If we get reports that people are still using the classic editor here we can make this a nicer experience

[peterwilsoncc]

I didn't change how things work in the classic editor and I think that's fine for now. If we get reports that people are still using the classic editor here we can make this a nicer experience

Cool, it's been about eight years.

Thanks for following up, these changes look good to me.

[peterwilsoncc]

So we do already have a current_user_can check in this function a few lines above:

Sorry Darin, we really do. "In my defense, I have none."