21 posts tagged with "Back-compat"

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: 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 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 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 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: 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?

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 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: 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: 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?