@prefix sioc: . @prefix dc: . @prefix dcterms: . @prefix xsd: . @prefix content: . @prefix rdf: . @prefix rdfs: . a sioc:Post ; dc:title "Architecture notes" ; dcterms:identifier 147454 ; dc:modified "2026-09-14T13:38:00Z"^^xsd:dateTime ; dc:created "2026-09-14T13:38:00Z"^^xsd:dateTime ; sioc:link ; sioc:has_creator ; sioc:has_container ; content:encoded "

One bridge, both directions

Every conversion routes through the same FormatBridge::convertResult() call from automattic/blocks-engine-php-transformer, which is symmetric across its html, markdown and blocks adapters. The plugin supplies the source and target format and otherwise stays out of the way.

Markdown input is a genuinely weaker source than HTML, for a structural reason rather than a quality one: the richer block patterns are triggered by inline styles and CSS shapes, and Markdown has no way to declare them. Use HTML for anything needing layout, media, buttons or styling; Markdown is fine for plain prose.

Why convert-post-to-blocks exists separately

It would appear redundant: a caller could call convert-to-blocks and hand the resulting markup to some other ability’s content parameter. In practice that two-step composition requires transcribing a large, deeply-escaped block-markup string by hand between two calls. On a real run that transcription silently dropped a closing tag and corrupted a live entry, caught only by chance on review.

convert-post-to-blocks removes that failure mode structurally rather than warning against it: only a post ID crosses the boundary, never the markup. This is worth preserving as a design constraint, not just an implementation detail.

Capability model

The ability-level gate is coarse and answers one question: does this caller edit content here. Authorisation for a specific post is a separate question, answered per ID inside convert-post-to-blocks via current_user_can( 'edit_post', $id ). Routing through edit_post rather than a hand-rolled author comparison means map_meta_cap applies, so published-post restrictions, custom capability types, and any plugin filtering map_meta_cap are all honoured rather than bypassed.

Vendor dependency

The transformer library lives in this plugin’s own vendor/ directory via Composer. A WordPress zip install wipes that directory, so composer install must be re-run after any such install. A missing autoload returns a clear error rather than fatalling, and the three abilities that need the library check for it before doing anything else. get-pattern-guide is unaffected, as it returns static data only.

"^^rdf:XMLLiteral ; sioc:content "Part of: LH MCP Block TransformerOne bridge, both directionsEvery conversion routes through the same FormatBridge::convertResult() call from automattic/blocks-engine-php-transformer, which is symmetric across its html, markdown and blocks adapters. The plugin supplies the source and target format and otherwise stays out of the way.Markdown input is a genuinely weaker source than HTML, for a structural reason rather than a quality one: the richer block patterns are triggered by inline styles and CSS shapes, and Markdown has no way to declare them. Use HTML for anything needing layout, media, buttons or styling; Markdown is fine for plain prose.Why convert-post-to-blocks exists separatelyIt would appear redundant: a caller could call convert-to-blocks and hand the resulting markup to some other ability’s content parameter. In practice that two-step composition requires transcribing a large, deeply-escaped block-markup string by hand between two calls. On a real run that transcription silently dropped a closing tag and corrupted a live entry, caught only by chance on review.convert-post-to-blocks removes that failure mode structurally rather than warning against it: only a post ID crosses the boundary, never the markup. This is worth preserving as a design constraint, not just an implementation detail.Capability modelThe ability-level gate is coarse and answers one question: does this caller edit content here. Authorisation for a specific post is a separate question, answered per ID inside convert-post-to-blocks via current_user_can( 'edit_post', $id ). Routing through edit_post rather than a hand-rolled author comparison means map_meta_cap applies, so published-post restrictions, custom capability types, and any plugin filtering map_meta_cap are all honoured rather than bypassed.Vendor dependencyThe transformer library lives in this plugin’s own vendor/ directory via Composer. A WordPress zip install wipes that directory, so composer install must be re-run after any such install. A missing autoload returns a clear error rather than fatalling, and the three abilities that need the library check for it before doing anything else. get-pattern-guide is unaffected, as it returns static data only." ; sioc:topic . rdfs:seeAlso . rdfs:seeAlso .