Thomas Dev

Hi @gabegabe,

Thanks for the detailed report. Your diagnosis was correct. An unscoped h3 rule in mementor-tts-admin.css was leaking into the Gutenberg editor through the post editor enqueue path.

The fix is already live in version 3.2.16

We removed the rule entirely as it was leftover from an older tooltip layout and is no longer used anywhere in the admin UI. While reviewing the same stylesheet, we also scoped a few additional selectors that could potentially affect the editor, including input[type="color"], input[type="range"], and [data-tooltip]. These styles now only load on the plugin’s own admin pages.

Thanks again for the report and for pointing us in the right direction.

Hi,

I dont see the Text to Speech TTSWP audio player on your page, and I think maybe you are in the wrong support forum. I looked in your source code and I think you are looking for help with the plugin “Screen Reader Accessibility“.

Am I right or missing something?

Hi Faizan,

Thanks for the email, that clarified the issue.

The message you saw, “Mementor TTS: Player script not loaded on this page…”, was introduced in 3.2.11. It confirms that the player script was never enqueued on this post. That explains why no <audio></audio>

Looking back at your original 3.2.10 report, the root cause appears to be the same, but surfaced differently. In 3.2.10, the script loaded but the player markup was not inserted because the audio could not be resolved. In 3.2.11, we added a check to skip loading assets on pages without audio. That check was too narrow and only looked at a single post meta field.

On setups where the audio exists in the speeches table or only as a file on disk, which can happen on free-plan sites, Media Offload setups, or older installs, the check incorrectly concluded that no audio was present, even when the MP3 file existed.

Version 3.2.12 has now been released to fix this. The check has been expanded to also include the speeches table and the audio folder on disk, which are the same sources the player uses when resolving audio. This should restore the player on affected posts.

Please do the following:

Update to 3.2.12
Clear all caches once, including LiteSpeed and any server-level caching
Reload one of the affected posts and verify that the player appears

Will mark this as resolved now, and if you still have questions, we can continue in the email ticket you just opened.

Hi Faizan,

Thanks for the detailed report. I will address both points below. About the 3.2.10 update

Version 3.2.10 only updated the Fusion Builder content extractor. This runs when you click “Generate Audio” inside the post editor.

The update did not change frontend player rendering, the Voices admin page, or the Player Settings page.

This means the update likely exposed an existing issue, rather than introducing a new one. Both symptoms are valid, and I will help you track them down.

Issue 1: Player not showing on the frontend
The console message Player Settings: Not found is expected. It is a debug message, not an error.

It simply means no player exists on the page for JavaScript to attach to. The player is therefore missing before JS runs, at the PHP level.

I checked the page you shared. The HTML contains no <audio> element and no mementor-tts-* markup. This usually means no audio file is attached to the post.

Please confirm the following:

• Go to wp-admin → Posts and locate the post “CCRC Refers IPP Sentence…”
• Check the TTS Audio column
• Does it show an active audio file, or is it empty?

Next steps:

• If empty, generate audio from the post editor and check the frontend again
• If an audio file exists, disable LiteSpeed Cache (page cache) for that specific URL and test again

Issue 2: Memory exhaustion in admin
The trace lines you shared (class-wpdb.php:2351 and functions.php:7230) are generic WordPress internals.

They do not show which code path is causing the memory issue. I need the full stack trace to identify the source.

Please do the following:

1. Add these lines to wp-config.php: define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
2. Reload the Voices page, then Player Settings, until the fatal error appears again
3. Send the full wp-content/debug.log file to [email protected]

Also include:

• A list of active plugins
• Your PHP version
• Whether the issue still occurs after temporarily disabling all other plugins

Disabling other plugins quickly confirms whether this is a conflict and saves time in debugging.

Once I have the full trace, I can identify exactly what is causing the memory exhaustion.

Custom voices will not display like the “other” system voices. If you save your voice id in the filed, that is the voice that will be used when generating audio.

You can bulk generate audio for all your 200+ articles from the posts listing page. Feature is already there.

Shortcode should look similar to this:

[mementor-tts audio="shortcode_067157_2qdzy-nb.mp3"]

Hi again @rapidasia .

Just a quick update: We’ve now released a new version (v.2.0.3) of the text to speech plugin that directly addresses the issue you experienced.

The update includes:

• Automatic permission validation when you save your API key (it now checks all required ElevenLabs permissions, including Voices: Read).
• A detailed permission status panel showing exactly which permissions are missing, with clear checkmarks/crosses.
• A direct link to your ElevenLabs API key settings, so you can fix the missing permissions quickly.
• A “Re-validate Permissions” button, so you can re-check everything after updating your key.
• Improved fallback loading, so if your API key doesn’t have Voices: Read, the plugin will still load voices using the built-in shared key.
• Better error handling, so the plugin can now tell the difference between an invalid key and a key with missing permissions.

This should make API key setup much easier, and should prevent the “Failed to load voices” issue going forward.

If you update to the latest version and re-validate your key, everything should work smoothly. Let me know if you want me to check your setup!