The page builder, its items, and the shortcode grid
View All Tags
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: 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. 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: 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. 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?