0.7.0 — media-library images that render

Added

• bdox/set-image — point an image element at a media-library attachment so it actually renders, at a named size and with a srcset. The built-in path cannot do this. Measured on Oxygen 6.2.0-beta.2: an OxygenElements\Image with from: media_library and size: "large" renders the builder's 540×540 grey placeholder while edit-post reports success and reads the data back exactly as written. The element resolves its src as content.image.media.sizes[size].url, but the MCP schema declares media with only id, url, alt and additionalProperties: false, so sizes can never be written and the lookup falls through to |default(). attributes.srcset is unreachable the same way, so an API-created image emits no srcset at all.

  Measured end to end on a probe page: before, src="data:image/svg+xml…" and one placeholder; after, src="…-1024x640.png" with a five-candidate srcset and zero placeholders. An unknown size is the one remaining way to get a placeholder, so it is rejected with the list of real sizes.

  alt needed its own handling. The element does not render media.alt from the tree — its template reads get_attachment_alt(media.id) in from_media_library mode and custom_alt in custom mode, so an attachment without _wp_attachment_image_alt renders an <img> with no alt attribute at all. Passing alt switches the element to custom mode, and alt_mode in the response says when the attachment's own alt is empty.

  Upstream report: soflyy/agent-connector-for-wp#79

Changed

• New helpers bdox_pack_get_tree() / bdox_pack_save_tree() / bdox_pack_map_node(). _oxygen_data is not the tree — it is an object whose single key tree_json_string holds the tree as an encoded string, so decoding one level and subscripting ['root'] yields null. map_node is copy-based rather than a reference finder: an aliasing finder previously duplicated whole subtrees across seventeen pages.