Audio coverage console for your WordPress blog archive

Build me an app for turning my WordPress blog archive into audio. The job it solves is coverage: I need to see at a glance which of my published posts already have a narrated version and which do not, then backfill the missing ones in bulk without re-doing work I have already paid for.

The main surface is a coverage table listing every published post. Load it from WordPress List Posts with status set to published, paging through every page rather than stopping at the first one, since the whole point is seeing the full archive. Each row shows the post title linking out to the live article, the publish date, its category, the word count, a clear has-audio indicator, and the duration of the audio when one exists. Default the sort to oldest first, because the backlog is what people come here to clear.

Give the table a filter bar: a No audio yet toggle that should be on by default, a category filter, a date range, and a title search. Pass the category, date and status filters into List Posts itself so the server does the narrowing rather than fetching everything and filtering in the browser. One catch worth knowing up front: there is no WordPress operation in the catalog for listing categories, so build the category dropdown from the distinct categories present on the posts you have already loaded rather than trying to fetch a taxonomy list.

Before anything is counted or narrated, clean the post body: strip HTML tags, WordPress shortcodes in square brackets, captions, embed markup and any script or style blocks, then collapse the leftover whitespace. The word count column is computed from that cleaned text, not the raw body. A settings value holds a minimum word count, default it to around 300, and posts below it render as Too short to narrate and cannot be selected, so link posts and one-paragraph announcements never get picked up by a bulk run.

The narration voice comes from Cartesia List Voices. Show the available voices in settings with a preview of the name and description, let me pick one as the default narration voice, and remember it. Keep the audio settings there too: the mp3 output format and bit rate, and the Google Drive folder the files are written to.

Rows carry checkboxes with a select-all that applies to the current filter, not just the visible page. As soon as anything is selected, a summary bar shows the number of posts selected and the total character count of the cleaned text across the selection, plus a rough runtime estimate. This is the guardrail against burning credits by accident, so the bulk run button opens a confirm step that repeats those numbers before anything is sent to Cartesia.

Running the batch processes each selected post in turn. Send the cleaned text to Cartesia Text to Speech (Bytes) with the chosen voice and mp3 output. Upload the returned audio to Google Drive with Upload File (Resumable), naming the file after the post slug and publish date, and use the resumable path rather than a simple upload because long articles produce files well past the 5MB limit for a single-shot upload. Then call Google Drive Create Permission on the new file with type anyone and role reader so the audio is playable by readers, and build the shareable link from the file id.

Finally, use WordPress Update a Post to prepend a Listen to this post block to the top of the post body, pointing at the Drive link. Wrap that block in a stable marker comment so the app can recognize its own insertion later: on a regenerate, replace the existing block rather than stacking a second player on the article, and never insert one twice. Preserve the rest of the body exactly as it was, and do not change the post status, title or publish date.

There is no WordPress media library upload operation available, so the audio must be hosted in Google Drive and linked into the post as described. Do not write a step that uploads the mp3 into the WordPress media library.

Persist a record per narrated post: the post id, the Drive file id, the public link, the duration, the character count, the voice used and the timestamp. That store is what drives the has-audio column and what makes a re-run cheap, since posts already recorded are skipped and only newly published ones come back as uncovered. Offer an explicit per-post Regenerate for articles I have rewritten, which is the one path allowed to overwrite an existing record.

While a batch runs, show per-row progress moving through narrating, uploading, sharing and updating the post, with a running completed count. Isolate failures so one bad post does not abort the batch: mark that row failed with a readable reason, carry on with the rest, and let me retry just the failed rows afterwards. If a post fails partway, do not record it as covered.