Why the default heading scale shrank — and why line-height was the real fix
The question: The default heading sizes look kind of large. What's a better scale?
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?