Preserving already-saved content across option changes
View All Tags
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: 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: 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: 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: 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: 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?