Remove the Aludra dependency from the shipped theme (4.9.2) - #107
Conversation
Replaces aludra/search-overlay-trigger, which the header-double-bar pattern depended on. Three changes over the block it replaces: - The trigger is a real <button>, not a <figure>, so it is keyboard-reachable. It also traps Tab while the overlay is open and restores focus to the trigger on close. - The overlay markup is rendered in PHP rather than assembled from a JavaScript string, so its strings are translatable. - The script is registered on wp_enqueue_scripts but enqueued from render_block() only when a trigger is actually rendered, and the footer markup is gated the same way, so sites that do not use the pattern load nothing extra. Only core/html blocks are inspected, keeping the filter off the hot path for every other block. The trigger ships hidden and is revealed by the script, so it is never a dead control without JavaScript; an editor-only rule reveals it while editing, where the script does not run.
The top bar's search icon was the theme's only aludra/* block, and it ships in the WordPress.org release — so inserting this pattern without the Aludra plugin installed rendered a block-error placeholder where the search icon belongs. Points at the theme's own trigger instead, making the pattern core-blocks-only like the other 120.
The part was a single core/pattern block pointing at aludra/mega-menu-featured-content, so on a site without Aludra the Mega Menu template part rendered as nothing at all — silently empty rather than a visible block error, which is why it went unnoticed alongside the header trigger. Inlines the equivalent composition in core blocks. Two things from the Aludra original were deliberately not copied: the placehold.co image, since a theme may not reference external resources, and the is-style-list-plain-no-indent class, which is a block style Aludra registers and Elayne does not.
The Lineage note, Requirements list and companion-plugin section all said Elayne's content blocks come from Aludra. Nothing Elayne ships references an aludra/* block or pattern any more, so every pattern and template part renders correctly without it.
Also bumps Tested up to from 7.0 to 7.1. Requires at least stays at 6.6 — nothing in this release needs newer.
Verified end-to-end on the demo, with Aludra inactive
Conditional loading works. Rendered overlay on
Still unverifiedEverything above is server-rendered output checked over HTTP. The interactive behaviour — click to open, ESC, backdrop click, Tab trapped inside the overlay, focus returning to the trigger on close, and the trigger staying hidden with JS disabled — needs a real browser and has not been exercised yet. |
1 participant
Elayne 4.9.1 is live on wordpress.org, and the zip it serves depends on a plugin that isn't in the plugin directory. Anyone who installs the theme from wordpress.org and inserts the Double Bar Header gets a block-error placeholder where the search icon belongs.
Problem
Two Aludra dependencies ship in the released theme — not one. The second was missed on the first pass because it isn't a block reference at all:
patterns/header-double-bar.phpaludra/search-overlay-triggerblockparts/mega-menu-template.htmlcore/pattern→aludra/mega-menu-featured-contentBoth are in the published 4.9.1 zip:
core/patternrenders nothing when its slug isn't registered, which is why the mega menu one never got reported — it fails silently rather than visibly. Anyone auditing the sibling themes should grep foraludra, notwp:aludra/.Aludra is not in the plugin directory, so this can't be resolved by recommending it:
Approach
The overlay moves into the theme rather than the pattern losing its search. Three things improve over the block being replaced:
aludra/search-overlay-trigger<figure>— not keyboard-reachable<button>Loading only where needed. A header pattern renders on every page, so there's no page-level condition to gate on the way
category-filter-drawer.jsgates on WooCommerce archives. Insteadsearch-overlay.jsis registered onwp_enqueue_scriptsand enqueued fromrender_block()only when a trigger actually renders; the footer markup is gated by the same flag. Onlycore/htmlblocks are inspected, keeping the filter off the hot path for every other block. Block rendering happens beforewp_footer, so a script registered$in_footer = truestill prints correctly.Sites that don't use the pattern load nothing — no script, no overlay markup.
No dead control without JS. The trigger ships with
hiddenand the script reveals it, so a visitor with JS disabled sees no button rather than one that does nothing. That script doesn't run in the editor, so an editor-only rule inassets/css/editor.cssreveals it there — otherwise the pattern's top bar would look like it was missing its search icon while being edited.Mega menu part is inlined as core blocks. Two things from the Aludra original were deliberately not copied: the
placehold.coimage, since a theme may not reference external resources, andis-style-list-plain-no-indent, which is a block style Aludra registers and Elayne does not.Result
Every pattern and template part now renders correctly without the plugin. Aludra stays a genuinely optional companion — README's Lineage note, Requirements list and companion-plugin section have been corrected accordingly, since all three described it as supplying Elayne's content blocks.
Also bumps
Tested up to7.0 → 7.1.Requires at leaststays 6.6 —render_blockis WP 5.0 and the mega menu part's grid layout is 6.3, so nothing here needs newer.Test plan
composer run wpcs:scan); the two pattern errors are pre-existing on all 121 patterns, which is whywpcs:scanexcludes*/patterns/*composer run lintclean;node --check assets/js/search-overlay.jscleanstyle.css,readme.txt,package.json,CHANGELOG.mdsearch-overlay.jsrequest on a page without the patternBrowser testing is still outstanding — the Trellis VM was down when this was prepared.