v2.15.3

Fixed

• Query loops accept include and rand, and page per loop (#403). QueryRuntime treats include as an alias of postIn and returns those rows in the requested order, accepts rand as random ordering, and pages a loop with a queryId on its own query-{queryId}-page variable, so two loops on one page paginate independently.
• Preset classes match the editor's class names for letter–digit slugs (#401). The editor names preset classes with WordPress's kebab case, which splits letters from digits: a fontSize: "h2" block carries has-h-2-font-size. GlobalStylesEmitter emitted only .has-h2-font-size, so h1–h6 style size presets (and any color, gradient or font family slug like gray900) didn't apply in the Site Editor canvas. Each preset class now also lists the WordPress kebab-case form when it differs (.has-h2-font-size, .has-h-2-font-size); custom property names are unchanged. The emitter cache key moves to v12.
• styles.blocks rules for artisanpack/* block forks reach the blocks (#405). GlobalStylesEmitter mapped artisanpack/x only to .wp-block-artisanpack-x. visual-editor's forks of core blocks render the core class (.wp-block-post-content, .wp-block-quote), so their block, element and element-state rules never applied. artisanpack/x now targets both classes, as visual-editor's BlockStyleCssCompiler::blockSelectors() does: :root :where(.wp-block-x, .wp-block-artisanpack-x) for the block and :root :where(.wp-block-x h2, .wp-block-artisanpack-x h2) for each element. First-party blocks that aren't forks still match through .wp-block-artisanpack-x. core/* and other namespaces are unchanged, and block names are still validated. The emitter cache key moves to v13.
• Post blocks inside a record's own content render the record (#407). HasRenderedBlockContent::renderContent() rendered the block tree with a binding context but skipped visual-editor's entity passes, so post-title, post-excerpt, post-terms and other post-* blocks in a record's content rendered empty wrappers. It now runs them first, in <x-ve-blocks>'s order: synced patterns are inlined, query loops are inlined with the record as host (so a related-posts loop in the content works), and PostResolver::stampTree() stamps the tree against the record. A post-content block inside the record's own content renders empty, and a record already being rendered further up the stack (a loop that lists the record itself) is not rendered again, so neither recurses. Each pass is skipped when visual-editor doesn't provide it, and a pass that throws leaves the tree as it was.
• Theme-file template parts take their area from theme.json (#409). TemplatePartResolver gave a part that exists only as parts/{slug}.html or parts/{slug}.blade.php an area guessed from its slug (header, footer, sidebar or uncategorized) and never read the theme's templateParts. Visual-editor's Navigation block renders an overlay part only when its area is navigation-overlay, so a theme-shipped overlay part never rendered until it had been saved once in the Site Editor. A theme-file part now takes the area of the active theme's theme.json templateParts entry whose name matches the slug (e.g. { "name": "mobile-menu", "area": "navigation-overlay" }), and falls back to the slug guess when there is no entry or the entry has no area. A saved part's own area still wins.
• Query loops default to published content for every post type. QueryRuntime::resolve() now lists only published pages and custom-type records, as it already did for posts. Pages came back in every status, because PageManager doesn't default to published for its admin callers. A custom type now uses its model's published() scope, or status = published when its table has a status column; a model with neither is unfiltered as before. resolve() also ignores a status attribute, since block attributes aren't a trusted source. A host that has already authorized a request to see other statuses can call the new QueryRuntime::resolveTrusted(), which honours status. visual-editor's CmsFrameworkQueryResolver keeps calling resolve() and needs no change.