The question: "Blog posts should be in posts, right? ... and for posts, we should probably just grab the content and check if it is just using the plain text editor." And then: "does that include custom post types as well? We can also make the site converter write custom post types in functions.php, right?"

The question: The extension that turns Unyson+ elements into Elementor widgets is listed as "Elementor Widgets". Would it be better to name it just "Elementor", since more Elementor features may be added to it later?

The question: Now that the converter is going to write Elementor pages — and Divi, Bricks and the rest after it — how should it be organised so that each new builder is cheap to add, and none of them can break the Unyson+ output that already works?

The question: When a site is converted into Elementor, its colours and fonts live in Unyson+ Theme Settings and in the Elementor Site Kit. Is it possible to make them bi-directional — edit either one and the other follows — and what else besides colours and fonts should follow?

The question: WordPress already ships Application Passwords. Why give Short Links its own API keys, and how should it tell other apps that something changed?

The question: we are adding a link shortener to Unyson+. What should its storage, defaults and admin look like, and what should it deliberately do differently from the plugins people would be switching from?

The question: a converted card grew an overline reading 01 / 3 that the source does not draw above the title. Is the right answer to put it where the source draws it, to build somewhere for it to go, or to delete it?

The question: the rule that decides whether a card's box belongs to the shortcode or to its container already existed on the column path. Should the flexbox path get the same rule — and if so, where?

The question: The product-name rule is about site conversion. Can the docs simply name AI products, tools, agents and WordPress plugins?

The question: the measurement tools had grown to ten files. Were they duplicating each other, or conflicting? And if so, should the overlapping ones be merged?

The question: we had a runbook for training the converter on a site and a separate one for fixing a converted site. Should they stay separate — different audiences, different permissions — or is that split the reason neither job ever gets finished properly?

The question: the converter never seemed to overwrite pages like /about/ — they kept content from an earlier conversion. Should it force an overwrite, with a notice so the user can opt a page out?

The question: What should a WordPress security extension for UnysonPlus actually contain — separating what protects from what only implies protection — and where does a custom admin / login URL belong?

The question: The AI Assistant should be easy enough that a newcomer can use it right away without tinkering. And how do you reset it?

The question: The assistant offered the same three generic starters on every screen and forgot the conversation on every refresh. Can it know where the person is and suggest what to do there — and keep the conversation — and if so, where should those suggestions and that history come from?

The question: Can someone with no AI subscription still use the AI Assistant, with a free model running on their own PC (the AI Dev Kit already runs one for the Site Converter) — and if so, how does a live site talk to it?

The question: The Menu Item Style control offered ten treatments, but Box and Highlight rendered from the identical fill rule, Pill was just Box with a rounder radius, and Fade only changed the resting opacity — something that would happily sit on top of any other style. We wanted to add premium treatments (a gliding indicator, a gradient underline, a marker swipe). Do we keep appending tiles to one flat picker, or is the list itself the wrong shape?

The question: Adding a new page logs a red [Violation] Permissions policy violation: unload is not allowed in this document in Chrome's console, traced to wp-tinymce.js. It's harmless — the editor and builder work perfectly — but a red "violation" in DevTools reads as this plugin is broken to anyone who looks. Do we leave it (it's not our code), or make it go away?

The question: At phone width the skin had no link out to the site — stock wp-admin puts a house in the toolbar whose menu holds Visit Site, and the skin hides that item. Should the skin grow its own front-end link in the off-canvas panel, or give core's item back?

The question: A conversion gets a site most of the way, and the rest needs corrections only the site owner can judge. Where do those corrections live so that neither a plugin update, a theme change, nor the next reconversion destroys them — and how do we stop them outliving the defects they were written for?

The question: The converter has always been pointed at a single page — in practice a homepage. Converting a real site means converting its inner pages too. Should that be N single-page conversions run one after another, or one conversion of the whole site?

The question: A converted h1 rendered with an inline color: rgb(245, 245, 245). Every entry in the generated palette is hex. Should the converter normalise rgb() to hex — and beyond format, should the option hold a Color Preset reference (predefined: 'ink') rather than a literal colour at all?

The question: The Admin Skin should be on as soon as the plugin is installed, the way the Page Builder is, rather than sitting unnoticed in the Extensions manager. Where does that activation live, and how should it behave when someone turns the extension back off?

The question: The Image Box media frame draws a ~6px radius that a converted source does not have, and DevTools shows it coming from the element's own .imgbox__media { border-radius: var(--imgbox-radius) }. We already have an Image Style preset that carries corners. Should the shortcode just stop setting a radius?

The question: While sweeping the admin for light surfaces in dark mode, four separate panels came up as "still white — fix it?": the classic editor's writing area, the Box Style / Table Style / Border Hover Animation picker swatches, and the Box Shadow preview. Are those bugs, or are they meant to stay light?

The question: The Forms extension was mail-and-forget — a submission was emailed to the admin and discarded. To make the contact form usable as a booking form, a quote request or a survey, submissions have to be stored somewhere. Since the Newsletter CRM already has a table of people with emails, lists and tags, can the form data just go in there, so everything about a person is in one list?

The question: The Newsletter CRM had only two public endpoints — confirm and unsubscribe. With multiple lists, a subscriber needs a way to say "keep the product news, drop the offers" without leaving entirely. That page needs a credential in the email link, and it needs an answer to the obvious edge case: what does the CRM do when the reader unticks everything and presses Save?

The question: Walking the DOM from <body> down to the first page-builder <section> shows a stack of wrappers — #page.site → #content.site-content → main#main.site-main → article.fw-col-12 → .entry-content → the plugin's .fw-page-builder-content → section. For a full-width, all-builder page that's a lot of nesting. The obvious first cut is the outermost one: drop #page and move its .site layout (the flex column, min-height:100vh) onto <body> itself. Should we?

The question: Is there a way to secure the AI Dev Kit code from developers who want to reverse-engineer it — base64, a password an agent has to supply before reading, something like that? And if not, how do you license the intent?

The question: Creating a new Page opened the Classic editor, with the Unyson+ Builder button sitting there to switch. For a builder-first product that's backwards — the common case (build a page) costs an extra click every time, and a new user doesn't necessarily know the button is the point. Should the builder be the default editor on a new post, and if so, for which post types? Blog posts felt different — those are usually written prose, not built layouts.

The question: We had just re-ordered the Component Presets tabs into a design-system cascade (tokens → containers → components → decoration), which put Box Presets before Buttons. The user-authored Hover Animations list (Pulse Ring, Swing, Rubber Band, …) lived inside the Buttons tab — so the effects a box might want sat behind the tab that came after it. Move the list to Box Presets? Show it in both tabs, kept in sync? Or is a list that updates "both places at once" a bad idea?

The question: People search for ways to convert an HTML site into Elementor, Divi or Bricks. Should the Site Converter become universal and target those builders too, so that reach brings people to Unyson+?

The question: While converting Testimonials off the Bootstrap-style fw-row/fw-col grid, its markup still emitted an inner width wrapper (fw-container, renamed to .testimonials-container). Inside a builder section that already constrains content width, that means the block is contained twice. Should an element carry its own max-width at all — or is width the responsibility of the section / column it sits in?

The question: The Scroll Keyframes control renders its Start, Middle (optional) and End states as one tall stack of sliders — you scroll the modal to reach the End state. Those three states are the textbook case for tabs. The framework already has a tab container type. So: use that, or build a new tabs option type by extracting the compact tab strip Background Pro already uses internally?

The question: Across the openhero.art demo sites the same two patterns kept appearing — frosted-glass panels (backdrop-filter: blur() over a translucent fill) and card grids that grow from a basis and wrap on a min-width (flex: 1 1 300px; min-width: 280px). The converter could already approximate both (glass via a box preset's computed skin; wrapping via a hard Width Override). Do we need to give Flexbox / Section / Div native options for these — and a Theme Settings token for glass — or is the indirect path enough?

The question: the gallery element launched under the name "3D Gallery". But is that the right name? Only some of its designs are actually 3D — and the roadmap makes that gap worse, not better. Should we rename it before launch, and if so, how far does the rename go — just the label, or the folder / tag / CSS / block underneath too?

The question: A converted section is a horizontal auto-scrolling marquee — jukeboxburgers.com's #menu-adjacent reel strip: a flex row of video cards looping left, pausing on hover. How should the deterministic converter reproduce continuous motion like this — and, more broadly, motion of any kind the Animation Engine can drive?

The question: the Model Viewer's Scroll Choreography — pin the element in a fixed, transparent, z-indexed layer and drive its position, scale, rotation and opacity from the page scroll via keyframes, with an opt-in authoring guide — turned out to be the exact "kage-style" foreground effect people wanted for flat images, not just 3D models. So we ported the engine to a new image element. That raised three placement/shape decisions: (1) it's self-contained (its own runtime, no hard Animation-Engine dependency) and its closest structural sibling (Parallax Scene) lives in the shortcodes extension — so does it go there, or in the Animation Engine next to Model Viewer, its closest conceptual sibling? (2) Is "Scroll Choreography" the right element name, or should it be qualified? (3) The standard builder adds Styling / Animation / Advanced tabs only when a shortcode opts in — which of them make sense here?

The question: jukeboxburgers.com sets its headings in Neutraface Condensed Titling — a commercial face we can't legally rehost — with the web-safe Alfa Slab One declared after it. Headings were rendering in Alfa Slab One (a wide slab — completely wrong proportions for a condensed titling face). Why did the converter "rule Alfa Slab One the closest match", and is there a fundamentally better way to pick the nearest font — should the local AI do it?

The question: The Tabs element's per-tab content is a single wp-editor field, but a converted section (jukeboxburgers.com's #menu) needs each tab to hold a full flexbox + grid layout of menu cards. How should a tab — and, by the same mechanism, an accordion or any other repeater — hold rich, nested page-builder content?

The question: the converter can't rehost a licensed source font, so it substitutes the nearest free Google font. A curated name→lookalike map nails the ~40 famous faces (Gotham, Neutraface, Söhne…), but what about the long tail — a bespoke or obscure licensed heading font on some future site the map has never heard of? Is there a tool that finds the closest free font for an arbitrary face, and should we adopt it or build our own?

The question: A converted section is a deep catalog — jukeboxburgers.com's #menu: colour-banded categories (APPETIZERS on white, CLASSIC BURGERS on near-black, CHAPLIN on red), each a grid of {name, description, price} cards, about seven levels deep. It was shipping as one opaque .sc-tw code block (faithful pixels, zero editability). How should the deterministic converter turn it into real, editable builder elements — and how far can that go?

The question: A source section is a styled content card — a white rounded panel (rounded-2xl border bg-background shadow) wrapping a full-bleed image, an overline, a big coloured heading, an address, contact links and a pill button (jukeboxburgers.com's "Visit Us" location card). Should the deterministic (PHP) converter decompose it into native builder elements, or keep it verbatim inside the Tailwind reproducer?

The question: WordPress blocks .svg uploads by default (an SVG is XML that can carry <script>, event handlers and external references — an XSS vector). But SVGs are now an everyday design asset — logos, icons, the foreground images in the new Image Scroll Choreography element. A premium builder like Bricks ships an "SVG uploads" setting with per-role toggles and on-upload sanitisation. Should UnysonPlus add its own SVG-uploads option, or point users at a maintained plugin (Safe SVG / enshrined-svg-sanitize) and stay out of the security-sensitive business of sanitising SVGs?

The question: The tabs content panel (.tab-content) always carries border: 1px solid #dee2e6; border-radius: .375rem; padding: 1rem; background: #fff. A source whose panel is frameless — its content is a card grid that brings its own boxing (jukeboxburgers.com's menu) — then sits inside a bordered white box the source never had. Should we add a disable-border option, and if so, should disabling the border also disable the padding?

The question: A source tabs nav is a centered brand-pill toggle — flex justify-center around an inline-flex bg-muted rounded-full p-1.5 border-2 border-primary track whose active button is rounded-full bg-primary text-primary-foreground shadow-md, buttons uppercase tracking-wide. The converter already classified it as design = segmented, but rendered the built-in segmented look: a left-aligned, light-gray, 10px-radius pill with a white active tab. To make it match exactly, do we add native tabs options for the pill (active fill, container border, pill shape), or read the source's captured styling and emit scoped CSS?

The question: Converting jukeboxburgers.com (a restaurant menu — prices shown, but you "Book a Table," there is no online ordering) with Map-to-WooCommerce enabled, should the converter auto-detect that it is a catalog/menu and suppress the shop machinery, or should we add a Catalog Mode option under Map to WooCommerce, or both?

The question: ModFii's logo has no image at all — the icon is a stack of <div>s with gradient backgrounds, rounded corners and a rotate(3deg), beside a "ModFii" wordmark. The converter's logo detector looks for an <img>, an inline <svg>, a library icon id, or wordmark text — a pure-CSS mark matches none, so it was dropped and the wordmark fell back to the bare page title. Should Theme Settings gain a new "CSS-composed logo" mode that stores and re-renders such nested-div/gradient markup?

The question: The Flexbox options modal feels disorganized — a single element renders a Section band, a Flex row, a Grid, or a plain Block depending on an HTML Tag and a Display select, and the one modal shows every option for every kind. Since nobody switches a root section to a div, or a flex to a grid, after dropping it — should we split the Flexbox into separate shortcodes / item types per kind so each has its own clean, tailored option set?

The question: A section is a grid of image tiles, each a photo with a title overlaid on the bottom (over a dark gradient scrim) and a gentle hover-zoom — jukeboxburgers.com's "Our Food Speaks For Itself" grid. What is the best and proper shortcode to reproduce this, and how do we make the deterministic converter translate it 100%?

The question: In the live editor, when you add a Flexbox / Grid / Block Div, should it drop at the page root the way it does in the backend builder — or should it be encapsulated in a Section (placed inside the last section, or wrapped in a new one when the page has none)?

The question: When a converted site sets its headings in a non-Google, licensed display face — jukeboxburgers.com uses Neutraface Condensed Titling, a commercial House Industries family that is not on Google Fonts — the theme generator can't load it. Should the user download and set it manually, should the deterministic + local AI hunt the web for a copy to grab, or should the converter pick the closest free lookalike on its own?

The question: Is it better to make a design-decision permalink https://docs.unysonplus.com/block-enrichment-which-types-stay-core — flattened to the site root — instead of https://docs.unysonplus.com/decisions/block-enrichment-which-types-stay-core?

The question: The page builder's new flexbox "Div" is a universal container — arbitrary nesting, flex/grid/block, per-device widths — so the Site Converter could now emit a 1:1 mirror of the source's DOM tree. Should it? Is duplicating the source DOM the right output model?

The question: The modern Div renders through utility classes like d-flex, flex-row, justify-content-center, align-items-center and fw-col-6. The unprefixed ones are literally Bootstrap's class names, and fw-col-6 apes Bootstrap's col-6 — so the output reads as Bootstrap and .d-flex even collides with real Bootstrap if a theme loads it. Do we rebrand the utilities (e.g. a new upw- prefix, or Tailwind-style names), and what do we call the column/grid utility?

The question: In the modern layout model every box is one primitive — a Div you tag section / div / article / aside — so the Width control was offered on all of them, including a Div tagged <section>. That let you make a section 5/6 wide. The classic Section never could. Is a resizable section correct, or should a Section always be a full-width band?

The question: Modern, AI-generated sites are built with Tailwind (flex/grid utilities). Should we just integrate Tailwind into UnysonPlus — swap the plugin's own utility classes for Tailwind's — so the layout model is modern and the Site Converter has an easier job converting Tailwind sources?

The question: Model Viewer's Scroll Choreography asks for each keyframe's At (scroll %) — 0 = start, 100 = end. But a typical author cannot guess that "section 3" is ~48%. What is the best way to help them set it?

The question: A demo panel's numbered steps were emitted as <ol style="max-width:60ch;margin:0 auto 1.5rem;color:#3a4757;line-height:1.9">…</ol> inside a text_block — even though text_block already has native max width, spacing (margin/padding), text colour, line-height and font-size options. Why reach for inline CSS at all, and how do we stop this recurring across sessions that build demos or sites?

The question: The block-theme output has an optional enriched vocabulary that emits unysonplus/* blocks instead of core blocks. Should every intermediate type enrich, or do some regions genuinely belong on core blocks even when the user opted into enrichment?

The question: the "Duplicate as landing page" importer assigns a page-landing.php template to get a chrome-less, full-width page. But the theme's Page Settings already have Header (Global / Transparent / Hidden), Hide Site Footer, Content Width, and Hide Page Title. So do we need the template at all — and why was the theme footer still rendering on a landing page that had the template assigned?

The question: Would it be better to make the Customizer (Appearance → Customize → Menus) carry the same mega menu settings and options as Appearance → Menus? Right now the mega controls only appear in the classic menu editor.

The question: I want the "product reveal" effect — a visual that comes apart to show its internals on scroll / hover / drag. It shows up as several techniques (frame scrubbing, layered separation, true 3D). Do we build one clever element that switches between them, or separate elements? And what do we call the new one, given "explode" is only one of its motions?

The question: The page-wide Custom WebGL Background shipped as an on/off switch plus two code editors (Scene DOM and Scene code (JS)) sitting in Page Settings → Animations. It renders a three.js scene behind the whole page. Should all of that instead be one selectable effect in the Animation Engine — for pages only?

The question: On the post editor, the new SEO metabox shows SEO title and Meta description as empty boxes — while the counters underneath them report a real pixel width and character count, and the page really does emit a title and a description. If the extension already knows what those values are, why not just pre-fill the two fields with them?

The question: We're adding an "Add entrance animations" checkbox to the Site Converter that gives a converted page sequential reveal-on-scroll motion. The user framed it as "use the deterministic with the help of the local AI." Where should the intelligence actually live — does the AI decide the animations, or does the deterministic converter, with the AI as a helper?

The question: A source "feature card" is a bordered panel (fill + border + radius + padding) holding an icon, a title and some content. When the deterministic Site Converter reproduces it natively, which container should carry the box — the icon_box's own Box Style, or the enclosing column's Border Preset? And should the box be a real Box Preset or a one-off scoped CSS class?

The question: The Element Mapping tables classify every shortcode option as native / via-CSS / unmapped. Accordion showed 18 unmapped — which looks like the converter is failing. Is a high unmapped count a problem to drive to zero? Should we hand-author “pre-mapping” data, or do we need a pile of real sites to map everything properly?

The question: UnysonPlus has a large PHP surface — ~845 public-prefixed helper functions and ~350 actions/filters. Is it wise to document all of it, the way people mean when they say "document every function"? And if so, how — hand-written pages, or generated?

The question: A testimonial card frequently ends with a small stat/result footer — a muted label ("Total savings") over an emphasized value ("$14,200", or a lone "40% more closes"). The testimonials shortcode had no field for it. When we add one — an Extra Texts field — what value shape should it take: a repeatable list of {label, value} rows, exactly one label+value pair, or a freeform rich-text footer?

The question: A source page has N buttons with slightly different measured skins. How do we distil them into a clean, faithful set of reusable Button Size presets (.btn-lg, .btn-md, …) that every button can be assigned to?

The question: The deterministic converter classified a source FAQ accordion — clearly a Separated list of cards — as Flush. Should we fix the classifier, or let the local AI companion pick the closest style?

The question: UnysonPlus's spacing and gap scales inherit Bootstrap's $spacers. The gap scale caps at slug 5 (3rem/48px), and both scales jump straight from slug 4 (1.5rem/24px) to slug 5 (3rem/48px). Modern (Tailwind-era) layouts lean on the values in between (32px, 40px) and above (64px, 80px). How should the framework — and the Site Converter that maps real sites onto it — represent those?

The question: To map every shortcode and Theme-Settings option faithfully, does the deterministic converter need an individual detector per option — or is there a better, registration-style way to make all options map properly?

The question: To make the Steps/Process shortcode "future-proof," should it adopt the shared Card Rows slot designer that Posts, Testimonials, wc_products and team-member use — a drag-to-reorder row/slot layout with a live card preview — or take the smaller step of adding a Box Preset (box_style) that layers onto its existing layout engine?

The question: The Site Converter's conversion knowledge lived in two places — a deep how-it-works (architecture + algorithm) under the extension docs, and a conceptual how-it-works (capture-first → outside-in → measure) under the AI Dev Kit — and neither was clearly the canonical home. Should we move all the extension's conversion subpages into the AI Dev Kit and reduce the extension section to a basic overview + a link, so all conversion info lives in one place?

The question: After the Site Converter walks a source and clusters every box skin into on-brand Box Presets, what happens to the plugin's four built-in defaults (Card / Outline / Soft Shadow / Hover Lift)? Do the site-derived presets replace them, or do both coexist — and if both, in what order?

The question: A single-URL conversion of an inner page (e.g. https://site/services) — should the user have to manually uncheck Create child theme, Capture header, Capture footer to get "just the sections content"? Will it create a new page or override the homepage? And if it can override the homepage, don't we need a "Create new page" checkbox?

The question: A converted store should get live WooCommerce shortcodes for its product grids ([wc_products], add-to-cart, etc.) rather than the static image_box cards a generic card grid becomes. Should the converter simply auto-detect WooCommerce from the source and map accordingly — or put a checkbox in the Convert panel, greyed out when WooCommerce isn't installed?

The question: How should the theme handle responsive typography long-term — keep stepping sizes at a breakpoint, add per-device controls to every field, or move to a fluid type system? And what has to be true for a fluid system to not fail accessibility?

The question: The Site Converter kept producing pages where a shortcode's own CSS or a unysonplus-theme default silently overruled the styles we mapped from the source — headings rendered bold when the source was regular, service-card icons came out green instead of grey, footer address text went black. Each was fixed one property at a time. Should we build a general "checker/detector" that stops shortcode and parent-theme styles from overruling the source?

The question: A typography overhaul this large can't safely be edited in place on the live control. How do we build and prove it without risking every site, and without leaving a messy v1 / v2 / v3 option-type namespace behind?

The question: Can the group container type carry a label of its own, so we stop faking section headings with a leading html option?

The question: a user wants a header that is transparent over the hero and shrinks its logo once you scroll. Today they can't — "Transparent overlay" and "Sticky + shrink" are two different values of the same Header Behavior dropdown. Why is a header's behavior a single choice at all, and how should we organize it so every setup is possible?

The question: Now that image-picker choices in the popover can be deselected (clearing the selection means "none"), should we remove the standalone "Enable page transitions" style switches across Site-wide UX and let "no image selected" mean "off"?

The question: the page builder validates every saved value through each option type's _get_value_from_input(). A Gutenberg block does not — its attributes reach the element's view directly from the editor. That asymmetry looks like an oversight. Why not close it?

The question: With "Minify combined script" enabled, the generated combined-<hash>.js still had one statement per line — it didn't look minified. Is the minifier failing, and should it collapse to a single line like everyone expects "minified" to?

The question: an audit flagged "no rate limiting" on the framework's public AJAX endpoints. But every one of them verifies a nonce, sanitizes its input and validates it. Is a nonce not sufficient?

The question: the React controls are thin wrappers around WordPress components. They render, they call onChange, the values look correct in the inspector. Writing a PHP test for each one felt like ceremony. Why do it?

The question: Live Editor kept at most 20 revisions per page, which sounds like a bounded feature. One site was holding 150.6 MB of revision postmeta. Where did the bound go?

The question: memoizing a single function halved the plugin's front-end memory. The remaining +15.2 MB has an identifiable cause and a plausible fix. Why not take it?

The question: the modernization plan is explicit that step 6 — rewriting the page-builder canvas off Backbone — should wait for "a concrete reason: a feature it blocks, a bug class it causes. Not on principle." No such reason had appeared. So why did we do it now?

The question: Can we let a user paste a pen (separate HTML, CSS, and optional JS panels) and have it come out as proper UnysonPlus shortcodes — a real special_heading / icon_box / button section — instead of just dumping the markup into a Code Block shortcode? And if so, where does the feature live, and what do we do with pens whose whole point is runtime JS?

The question: Deleting the Mega Menu extension removed it from the Extensions manager entirely — no card, no way to reinstall it. Deleting Breadcrumbs left it listed, offering an Install button. Why do some extensions survive deletion and others don't, and what's the right fix?

The question: Every element's options modal took ~873 ms and ~6.7 MB to open. An existing "lazy multi-picker" optimisation was already in place and clearly not working. What is actually costing that, and can it be deferred without risking saved values?

The question: Some people want the block editor but still want the Unyson+ options framework. Getting elements in front of them could mean porting them to native blocks — block.json, React edit, attributes per option — or exposing the elements that already exist through a bridge. Which, and what does the bridge actually have to do?

The question: fw.js called Backbone.Model.extend and Backbone.View.extend in exactly two places. Replacing them looked like an afternoon. Then the modal underneath turned out to be wp.media.view.MediaFrame — WordPress's media frame, which is Backbone, and which Backbone still loads for anyway. Is removing it worth the risk?

The question: The most common criticism aimed at anything descended from Unyson is that the extension layout itself is obsolete — a config.php / options.php / views/ / static/ folder, options declared as PHP arrays, output rendered through a shortcode. Modern WordPress, the argument goes, means block.json, React InspectorControls, PSR-4 autoloading and a webpack build. Is the UnysonPlus extension architecture legacy debt that has to be rewritten?

The question. A Tailwind-built source (a jiro.build finance template) converted badly on localhost. The obvious shortcut surfaced: the source markup is full of Tailwind utilities that already encode the design (grid grid-cols-2 gap-16 items-center, min-h-screen, absolute inset-0, text-4xl font-bold) — so why does the converter bother mapping each element to native shortcode options at all? Why not paste the source element's class string straight into the shortcode's Advanced → Custom CSS Class (css_class) field and let those classes do the work?

The question: qTip2 has been unmaintained since 2016, and we replaced it with Floating UI. The old implementation put its vendor everywhere — .qtip-fw class names, a 'qtip' script handle, $.fn.qtip(). Do we carry that naming over to the new library and call things floating-ui, or name them something else?

The question: The framework's biggest reputational liability is the inherited "Unyson is outdated" perception. A technology audit of the plugin showed that's largely stale for this fork. Should we publish a public Technology page to rebut it — and if so, how do we handle the fact that such a page also has to acknowledge the remaining legacy?

The question: Shape dividers are used by exactly one place — the Section. So why give them their own Components tab instead of folding them into Section Styles? Should a divider preset carry its own colour? And since the Top and Bottom pickers show the same shapes, should Bottom just be a flip of Top, or should we ship separate bottom presets?

The question: A button set stores the same value a radio stores — one key from a fixed set of choices. Everything else is presentation. So should it be a new option type at all, or just 'display' => 'buttons' on radio?

The question. We just moved the Section shortcode's per-instance styling out of inline style= and into stylesheets: Min Height (a fixed enum) became predefined .section--minh-{40|60|80|100} classes, Container Width (a user-extensible named-width library) and the vertical-align flex became .u{hash}-scoped rules in the per-page page-{id}.css. The background (color / gradient / image / overlay) is now the only thing the section still prints as an inline style="background-…". Should it move to page-{id}.css as well — for a fully inline-free markup — or stay inline?

The question: A converted "About" section used the source's container-narrow class (max-width: 64rem). The section shortcode's Container Width control offered only fixed presets — Narrow 768 / Medium 896 / Wide 1024 / Custom. 64rem is 1024px, so this one mapped to Wide — but the general problem stood: when a site uses a container width the theme has no named slot for (and reuses it across many pages), how should the converter represent it so the result is faithful and reusable, not a value copy-pasted onto every section?

The question. A converted "About" section's subtitle paragraph carried max-w-2xl mx-auto (a 672px centered content measure). The converter dropped it: the section rendered full-width. Two questions fell out of that: (1) what's the rule for putting converted CSS in Theme Settings → Miscellaneous → Custom CSS vs the child theme stylesheet? And (2) what's the strict rule so a class that can't map to a native shortcode option is never silently dropped — it MUST land somewhere?

The question. A source logo is a text wordmark: <a class="font-serif text-2xl md:text-3xl tracking-tight text-foreground hover:text-primary …">Maison</a>. The converter captured the text, colour, size and weight — but the output rendered "Maison" in the theme's sans default, with none of the source's serif, tight tracking, or hover colour. So: when an element's classes can't ALL map to native options, how should we translate them — and does the rule we adopted for content sections apply to chrome (logo / header / footer) too?

The question: In practice the special_heading subtitle was almost never used by the Site Converter — a heading's intro line came through as a separate text_block. Two things to settle: (1) should the converter fold a paragraph right after a title into the subtitle, and (2) should the subtitle option stop being a single-line text field and become a rich editor?

The question: A converted button (scandi-haven-shop's hero "Shop Now") dropped its hover animation — a translucent overlay that rises from the bottom to fill the button. The effect lives entirely on .btn-premium::after + .btn-premium:hover::after, which getComputedStyle(el) never exposes. Once we teach the capture to harvest those rules, what do we DO with them: reproduce the source CSS verbatim on the button, or map it to one of the theme's named hover-effect presets?

The question: The [newsletter] element already renders a form, validates a signup and emails the site admin — but nothing stores it. Building that storage layer means choosing a shape now that still works when campaigns, automations, contact timelines and Mailchimp/MailerLite/Brevo sync arrive. So: custom post type or custom tables? And once that is settled, how are lists, tags and segments modelled — because that is the decision that is expensive to reverse.

The question: When a converted <div class="text-center max-w-2xl mx-auto"><h2>…</h2><p>…</p></div> comes out left-aligned, where does alignment belong? Should we add text_align to the column/section — and if we do, is special_heading's master Alignment option now redundant and safe to remove?

The question: We want the docs site to explain how the deterministic Site Converter turns a source element into a UnysonPlus shortcode — the Priority / Recognizer / Matches when / Becomes table, plus the native options each mapping sets. Two open questions: where does it go — a row added to each /docs/shortcodes/<element> page, or one consolidated table — and do we hand-write it or generate it?

The question: As the AI Dev Kit grew, its root filled with a mix of hand-authored files and machine-fetched folders. Should the fetched/assembled folders be collected into one directory — and if so, what should it be called?

The question: Should the Live Editor's flat "Sections" panel become a full nested Structure tree (section → column → element), like the navigators in Bricks / Elementor / Webflow?

The question: Should a shortcode's default colours be hardcoded, or should they follow the site's Color Presets (the theme palette) automatically — falling back to the hardcoded value only when the palette isn't available?

The questions: the opt-in --share flow sanitizes each conversion into a structural-only JSON and POSTs it to a Google Form. (1) Will an external developer's AI agent send us something we can actually use to improve the converter? (2) What's the right consent cadence — does it send cumulatively or per bug; does one "yes" cover the rest of the site; and is it OK to keep asking after a "no"?

The question: the Site Converter is deterministic, so an outside AI agent will hit cases it can't map. Will that make the agent ship a half-baked site? And to fully convert, should the agent fork the converter (or keep a custom converter folder/hook) and report its changes?

The question: when an agent creates a new shortcode, how does it choose where the shortcode lives — and should it ask the user how they want to install / distribute it (child theme vs an uploadable zip they can hand out), or just decide?

The question: the spacing scale (unysonplus_default_spacing_scale()) has no 32px or 40px step — the range 24→48px is one gap — so the Site Converter, which snaps a source's captured padding to the nearest slug, rendered e.g. a 40px bottom padding as 48px (up to 12px error). Should we renumber the whole scale to Tailwind numbering (pt-8=32px, pt-10=40px…) to fill the gap, or keep the scale and add arbitrary values (pt-[40px])?

The question: a decomposed element carries styling a shortcode has no option for (a heading's font-extrabold leading-[1.1], a paragraph's md:text-xl text-foreground/70). The Special Heading shortcode — and every shortcode's Advanced tab — has a CSS Class field. Rather than synthesizing Custom CSS for each effect, why not just put the source's own utility classes in that field and let the section's carried CSS render them? Isn't that cleaner and more editable?

The question: The new Card Rows designer lives on a Card tab, but the reusable border/corners/shadow/fill preset you apply to that card is called Box Style (from Box Presets). That looked inconsistent — should we rename everything to one word ("Box tab / Box Rows", or "Card Box Style / Card Box Presets")?

The question: the theme's Container Width setting (Theme Settings → General → Layout) drives .fw-container { max-width: … }. But the container also carries a left/right gutter as padding, and with box-sizing: border-box that padding is inside the max-width — so setting the width to 1280 (to match a source's max-w-7xl) rendered only ~1216px of actual content. Should "Container Width" mean the outer box (Bootstrap's model, current) or the content width (Tailwind's model, expected)?

The question: the wc_products (Products) element controlled a product card three overlapping ways — a Classic/Slot "Card Layout" dropdown, a column of per-element show/hide switches (Price, Rating, Rating Number, Short Description, Quick View, Add to Cart, Wishlist, Stock), and an editable Card Rows slot designer. Do we keep all three, or is one model enough? And with the fixed "Classic" markup gone, where should a card's visual skin (border, corners, shadow, hover) come from?

The question: the compact rounded-label shortcode — sub-tag, message, leading/trailing icons, optional link — was called announcement_pill. It renders status badges, "what's new" hero chips, eyebrow labels and announcement bars. Is "announcement pill" the right name for it, or should it be badge — and if we rename, do we need a migration?

The question: the converter kept producing sections with the wrong spacing, a missing overline color, a dropped background. One proposed fix: extract all of Tailwind's official utility classes (a finite, canonical set) and selectively pre-map each to a shortcode option, so coverage is "complete" and we stop missing things. Is that the right primary mechanism, or a regression to brittle class-name parsing?

The question: while reproducing a source site, the converted output had many small misses (a button missing its shadow-lg, a pill rendered as a plain <span>, borders and paddings off). The fast instinct is to hand-fix that one site — nudge misc_custom_css, tweak a preset value — until it matches. But should the AI hand-patch the output, or should every fix go into the deterministic Site Converter so it produces the correct result on its own?

The question: we already decided the converter's job is to fix the algorithm, not the output. But in practice, when a build hits a section the converter can't map yet (e.g. a WooCommerce product grid), what is the exact, repeatable iteration — and when do you actually write a recognizer versus just hand-build it?

The question: the copyright bar's alignment kept coming out wrong when cloning a source (centered in the source, left in ours). Do we give each copyright column its own alignment control, or infer the alignment from how many columns there are?

The question: every no-code post type builder has the same objection sitting under it — now my content schema depends on your plugin. It is a fair objection. Do we answer it with documentation, or with a feature?

The question: Custom Fields could not link content to content. No way to point a Property at its Agent, a Case Study at related Case Studies, a Team Member at a WordPress user. That is the single most common reason to reach for ACF instead. Do we build a relationship option type?

The question: removing a post type row from the Post Types screen doesn't delete anything, but it makes every item of that type invisible — no admin menu, no edit screen, URLs stop resolving. A user who "cleans up" a row loses access to their content with no warning and no obvious way back. What should the screen do about it?

The question: the Post Types extension already deferred flush_rewrite_rules() to the request after a save, which is the pattern most no-code CPT plugins get wrong. So why were third-party permalinks occasionally 404-ing after someone saved the screen?

The question: the Post Types screen silently dropped invalid rows — a reserved key, a duplicate, a taxonomy attached to nothing. The user saved, saw "Saved.", and nothing appeared, with no way to find out why. Adding validation was obvious. Whether validation should refuse the save was not.

The question: Phase 0 of the Animation Engine's motion roadmap is "make scrolling feel effortless everywhere, and give every scroll-driven effect one shared clock." That raised two forks. (1) Where should the new inertia smooth-scroll live — a new engine module, or an extension of the theme's existing anchor-link "Smooth Scroll"? (2) How do we unify the scroll-reactive modules so they stay in lockstep — port them all to GSAP's ScrollTrigger, or reuse the engine's own shared animation loop?

The question: the Scroll Motion Custom Code (Motion Snippet) field lets an author hand-write GSAP, but a newcomer faces a blank editor with no idea of the API surface. A code generator would help — but how much of GSAP should it expose: everything (a general GSAP playground), or only what the field actually gives you?

The question: the roadmap's Phase 1 is "a real motion timeline" for the builder — keyframing several properties over one scrubbable axis. How much timeline do we actually build: a dynamic keyframe editor, or something smaller that still covers the need? And what drives the scrub?

The question: UnysonPlus had grown a scatter of sibling upload folders in the WordPress uploads root — unysonplus-icon-packs, unysonplus-asset-optimizer, unysonplus-lottie, unysonplus-rive, unysonplus-templates, unysonplus-designs, unysonplus-shortcodes, unysonplus-presets, plus a plain unysonplus/ for generated CSS. Should each keep its own top-level folder, or move under a single uploads/unysonplus/ parent?

The question: the Animated Icons extension has per-technology toggles (Lottie, Rive, Animated SVG, Animated raster). Should they live on the extension's own Settings page, or move into Theme Settings → Icons — perhaps as a new tab?

The question: Can the header/footer columns' addable-popups drag-and-drop between each other (not just reorder within one column)? Is that a big refactor of the option type, or do we need a new post type for it?

The question: on a cinematic reference site the footer isn't a band below the page — its closing tagline sits on the bottom of the last full-height scene, overlaid. That also removes the blank gap a pinned last section leaves after it fades out. Should this be a one-off per-site hack, or a first-class Footer option — and if an option, how do we make it generic and safe?

The question: Should we add an "Icon Badge preset" like Box Presets — a reusable, globally-editable badge style for icons in Theme Settings?

The question: the Animated icon kind plays Lottie animations from a URL/upload as raw Lottie JSON. Should it also accept .lottie (dotLottie) files, and would that help pages that show many animated icons at once?

The question: a reference site's scroll section plays as a sequence of batches — each batch is a set of photos that scatters onto the surface, holds around a centered line of text, then scatters away as the next batch (with different photos and a different line) arrives. How do we build that so each batch has its own images, its own text, and its own entrance/exit — and stays editable in the builder?

The question: a reference site's hero underline is a hand-drawn scribble that draws itself on when the hero appears and then idly waves. How is that built, and how do we reproduce it — an animated SVG path (stroke-dashoffset draw-on) or something else?

The question: The Animation Engine → Text Effects module already ships rotating_words and typewriter (among ~40 effects) that can be applied to any text element. Does the standalone animated_heading shortcode still earn its place, or should it be deprecated in favor of "special_heading + a text effect"?

The question: a reference site's scene sections look like a film camera slowly glides across the scene as you scroll — a genuinely cinematic touch. Is that a real 3D camera move (rendered footage), and if not, how do we reproduce it in UnysonPlus without baking a video?

The question: to make a demo's animation flow match a heavily scroll-animated reference site, do we bake the continuous "camera ride" into one pre-rendered video / frame sequence that scrubs with scroll (the way the reference site itself does it), or do we keep every card, device screen, image and line of copy as a live page-builder element and drive the camera moves with scroll animation over an optional decorative backdrop?

The question: GSAP + ScrollTrigger already drive the Scroll Motion module, but the builder only exposed a hand-picked slice — Style presets, direction, distance, start. Power users kept hitting a wall (no easing choice, no way to choreograph several elements, no way to write anything the presets couldn't express). How much of GSAP should we surface, and where does exposing-more stop being "friendly to advanced users" and start being "a code editor bolted onto a page builder"?

The question: the Motion Snippet (rung 5 of the GSAP ladder) lets a user type GSAP that executes on the front end. That's arbitrary JavaScript — the same trust surface as a Custom HTML block or a theme's custom-JS box. How do we make it safe without breaking it, and where does the capability check actually belong?

The question: every new content library (page-builder templates, then component presets, then icon packs) was about to get its own GitHub data repo. That felt messy. Can we put all library content in one repo — and if so, what actually has to stay split?

The question: the engine's model was one effect per element, each firing independently when it scrolls into view. A GSAP timeline is the opposite — several elements animating in a choreographed order with relative timing. How do you translate that into page-builder options a non-coder can drive, without shipping a keyframe editor or a code field?

The question: Builder pages started rendering the theme's page title as an H1 bar above the built content (so "every page has exactly one H1"). Was that a good default — or should the theme title simply be disabled whenever the Page Builder is used, leaving the per-page "Hide the page title" checkbox to classic-editor pages only?

The question: for the 3D Gallery's Scroll-scrub motion, should the gallery pin on screen while the visitor's scroll drives the animation (instead of scrolling past with only a sliver of movement visible)? And should the Motion options become a multi-picker so each mode reveals only its own settings?

The question: cards needed to link somewhere on click — a per-image URL, and ideally "each portfolio card links to its portfolio page." Where does a per-image URL live when the Images option is a multi-upload that stores only attachment IDs?

The question: a "Photo Scatter" effect — photos scattered flat on a tabletop, gliding in from the edges, dwelling, then reshuffling to the next set — is unmistakably a gallery. The core [gallery] element already has 20+ layout designs. So does a new gallery design belong there, or in the Animation Engine's [gallery_3d]?

The question: The Portfolio extension has its own Settings page (archive columns, per-page, order, single-view toggles). The theme is gaining a Theme Settings → Portfolio tab. Who owns which settings — and how do the two coexist without drifting or double-defining everything?

The question: [posts post_type="fw-portfolio"] already renders project listings with layouts, card styles and pagination. Should [portfolio] stay a lightweight filter-grid and steer users to [posts], or grow into the full portfolio element?

The question: we keep building cinematic scroll-driven sites (a pinned "camera ride" frame-sequence background with full-screen text scenes keyed to scroll segments). Should that become a brand-new Animation Engine module / shortcode, or grow out of something that already exists — and either way, how does a typical builder user author one without touching code?

The question: An AI browsing agent reads a page two ways — through the accessibility tree (roles, names, states) and through the server-rendered HTML (text, links, and machine-readable structured data). Should UnysonPlus invest in being "agent-ready" across both channels? And does that investment include building a WebMCP integration (page-exposed tools an in-browser agent can call) now?

The question: The Posts "Card Style" list felt redundant — several styles are just an image mask or a fill on top of a base layout, and we already have Box Presets. How should image treatments be organized, and should they become a reusable Theme Settings preset?

The question: How should the footer support 5+ distinct bands cleanly — a child theme dropping a footer-container-4.php / footer-container-5.php options file per extra bar, or something lighter?

The question: The footer Column Ratio slider can't reproduce a real design's columns (a wide brand block beside three content-sized link lists). Do we hit a grid limitation — and if so, do we build a new flex container/section, or fix the existing column control?

The question: Internal Page-Builder pages ship with no <h1>. Should we require a special_heading (H1) in each page's builder content, or have the theme render the page title as the H1?

The question: Should other developers using the AI Dev Kit have their agents change the Site Converter — and if we instead want them to report improvements back, is GitHub the right place, given not everyone has an account?

The question: Should the kit's theme-settings-reference.md go deeper — documenting every preset's options and all their choices — and split into a folder, one file per main tab?

The question: The default heading sizes look kind of large. What's a better scale?

The question: Would it help to add a markdown file to each option-type folder in framework/includes/option-types?

The question: A theme bug made text unselectable everywhere (the selection highlight was invisible). While fixing it, we realised some site owners actually want selection disabled as a copy deterrent. So: expose it as a real Theme Settings option — and where should it live, a new "Others" tab or somewhere that already exists?

The question: The Mega Menu's per-column width control was a plain select. The page builder's Column shortcode has a much nicer "Width Override" — visual width tiles. Should the mega column width just reuse that same control for consistency?

The question: On the Background Effect popover you can pick an effect but never un-pick it — once a tile is selected there's no way back to "off". Do we bolt a None tile onto every popover picker, or make the popover itself let you select and deselect a choice?

The question: Almost everything modern — WordPress core, Gutenberg, most new page builders — is React. UnysonPlus's page builder, option types and Live Editor are Backbone.js + Underscore templates + jQuery. Should we rewrite the builder in React?

The question: The parent theme draws a thin line above each footer section (protection toolkit, helpline, copyright). A child theme that doesn't want those lines has to override them — should the divider stay a default that every site turns off, or default to nothing and be turned on only when a site actually wants it?

The question: The live editor moves actual front-end DOM nodes when you drag something. But nesting a column needs an inner .fw-row that doesn't exist in the rendered page yet — the corrector only creates it at render/save time. So when I drop a column into another column, do we hand-build that inner-row DOM inside the editor frame, or do we re-render?

The question: The first time I put a column inside a column, the frontend came out broken — the content truncated and a literal [/column][/row] showed up as text on the page. Why does nesting the same element blow up, and how do we render a column-inside-a-column without WordPress choking?

The question: I want a page-builder column to be able to contain other columns. Do we add a dedicated "Inner Row" element you drag into a column (like Elementor's inner section or WPBakery's inner row), or do we just let a column accept columns directly and build the row ourselves? And how deep should nesting go?

The question: Can we make the Off-Canvas header mode more flexible? Right now it only displays the menu. Can it display Snippets — I want the ability to add shortcodes or custom info in that panel. Perhaps a select where the user chooses default menu or snippet, and for snippet a dropdown of snippets?

The question: I want the Design tab to show only the options that matter for the current choice — so layout_mode, card_style, pagination_type should become image-pickers that reveal their own sub-options. But those are existing selects with real saved data, and turning a select (a string) into a multi-picker (an array) is a value-shape change. How do I do that without breaking every already-saved Posts/Testimonials block?

The question: The Posts grid's Column Gap and Row Gap were plain px inputs. The rest of the builder (Section, Row, Column) takes gaps from the theme's Gap Scale presets. Should Posts do the same?

The question: Posts now has 20-plus card designs. The markup only ever outputs the chosen design, but does the CSS? Should every page with a Posts block load all designs' styles, or only the one in use — and if only one, how do we wire that without a list to maintain as designs keep growing?

The question: The card read-more link can render as a button. Do we add Button Content and Button Styling tabs to Posts that mirror the Button shortcode's options, so the read-more is as configurable as a real button?

The question: Now that the basic color-picker shows the Color Presets as swatches, should we just use it for every color in Theme Settings and drop the preset picker? Those colors go into the dynamic stylesheet, not classes, anyway — so what's the preset picker even for?

The question: I want a shortcode to ship lots of visual designs — and to keep adding more — without the view file turning into an ever-growing pile of conditionals. How should "which design renders" be structured so a new design is cheap and safe to add?

The question: Would it be better to make the testimonial Quote field a wp_editor (a full visual editor) so authors can format their quotes?

The question: The testimonial rating stars showed up as tofu (□□□□□) on a live site. Do we enqueue Font Awesome so the fa-star glyphs resolve, or render the stars some other way that doesn't depend on a webfont being present?

The question: Now that we want every color control to show all the Color Presets as clickable swatches, can we keep using WordPress's built-in Iris picker? And should opacity just be on everywhere?

The question: UnysonPlus is a fresh restart of Unyson. The rich typography control shipped as typography-v2 while the original typography was a weaker, older implementation. Do we upgrade typography-v2 in place, or promote it to the clean typography name and scrap the -v2 suffix?