Framework-wide structure and conventions
View All Tags
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: 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?