EricJohnsonGuru

That’s a great turnaround, thank you. I read v2.0.3 and here’s what I see from our side without testing on the live site yet:

What’s now covered for TSF:

• meta_title → _genesis_title and meta_description → _genesis_description via auto-detect on update-post. ✅
• ewpa/update-post-meta lets us reach the rest of TSF’s keys (_genesis_canonical_uri, _genesis_noindex/nofollow/noarchive, _tsf_title_no_blogname, _social_image_url/_id, _open_graph_title/_description, _twitter_title/_description, redirect). ✅
• What we’d give up by deleting our companion:
• TSF post-meta cache flush. TSF caches its meta and won’t reflect changes on the frontend until tsf()-flush_post_meta_cache( $post_id ) runs. Without that, edits look applied in the DB but the rendered tags can lag. Would you consider firing a post-write hook (e.g. do_action( 'ewpa_after_update_post_meta', $post_id, $meta_key, $meta_value )) so SEO plugins can hook their cache busters?
• Typed schema / validators per field. Our companion enforces a 0/1/2 enum on the robots flags, same-host validation on canonical/redirect, attachment-ID existence on social_image_id, and a two-pass validate-then-write so a bad field doesn’t half-apply. With raw update-post-meta, the client has to know the contract.
• Single-call read of all TSF SEO fields. With the generic writer there isn’t a generic reader, so an LLM has to issue N get-post-meta calls or guess keys. Probably not worth a dedicated ewpa/*-tsf-seo if Yoast/Rank Math/SEOPress already have parity – but a write-hook for cache busting and maybe a get-post-meta companion would let me retire the snippet fully. Happy to test TSF auto-detect on the live site and report back this week.
• Either way: huge appreciation for shipping this so quickly.

Great thanks.

For those wondering what the answer to generate blocks is the code is:

add_filter( 'generateblocks_do_activation_redirect', '__return_false' );