44 posts tagged with "Shortcodes"

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: Across the openhero.art demo sites the same two patterns kept appearing — frosted-glass panels (backdrop-filter: blur() over a translucent fill) and card grids that grow from a basis and wrap on a min-width (flex: 1 1 300px; min-width: 280px). The converter could already approximate both (glass via a box preset's computed skin; wrapping via a hard Width Override). Do we need to give Flexbox / Section / Div native options for these — and a Theme Settings token for glass — or is the indirect path enough?

The question: the gallery element launched under the name "3D Gallery". But is that the right name? Only some of its designs are actually 3D — and the roadmap makes that gap worse, not better. Should we rename it before launch, and if so, how far does the rename go — just the label, or the folder / tag / CSS / block underneath too?

The question: the Model Viewer's Scroll Choreography — pin the element in a fixed, transparent, z-indexed layer and drive its position, scale, rotation and opacity from the page scroll via keyframes, with an opt-in authoring guide — turned out to be the exact "kage-style" foreground effect people wanted for flat images, not just 3D models. So we ported the engine to a new image element. That raised three placement/shape decisions: (1) it's self-contained (its own runtime, no hard Animation-Engine dependency) and its closest structural sibling (Parallax Scene) lives in the shortcodes extension — so does it go there, or in the Animation Engine next to Model Viewer, its closest conceptual sibling? (2) Is "Scroll Choreography" the right element name, or should it be qualified? (3) The standard builder adds Styling / Animation / Advanced tabs only when a shortcode opts in — which of them make sense here?

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 source section is a styled content card — a white rounded panel (rounded-2xl border bg-background shadow) wrapping a full-bleed image, an overline, a big coloured heading, an address, contact links and a pill button (jukeboxburgers.com's "Visit Us" location card). Should the deterministic (PHP) converter decompose it into native builder elements, or keep it verbatim inside the Tailwind reproducer?

The question: WordPress blocks .svg uploads by default (an SVG is XML that can carry <script>, event handlers and external references — an XSS vector). But SVGs are now an everyday design asset — logos, icons, the foreground images in the new Image Scroll Choreography element. A premium builder like Bricks ships an "SVG uploads" setting with per-role toggles and on-upload sanitisation. Should UnysonPlus add its own SVG-uploads option, or point users at a maintained plugin (Safe SVG / enshrined-svg-sanitize) and stay out of the security-sensitive business of sanitising SVGs?

The question: The tabs content panel (.tab-content) always carries border: 1px solid #dee2e6; border-radius: .375rem; padding: 1rem; background: #fff. A source whose panel is frameless — its content is a card grid that brings its own boxing (jukeboxburgers.com's menu) — then sits inside a bordered white box the source never had. Should we add a disable-border option, and if so, should disabling the border also disable the padding?

The question: A source tabs nav is a centered brand-pill toggle — flex justify-center around an inline-flex bg-muted rounded-full p-1.5 border-2 border-primary track whose active button is rounded-full bg-primary text-primary-foreground shadow-md, buttons uppercase tracking-wide. The converter already classified it as design = segmented, but rendered the built-in segmented look: a left-aligned, light-gray, 10px-radius pill with a white active tab. To make it match exactly, do we add native tabs options for the pill (active fill, container border, pill shape), or read the source's captured styling and emit scoped CSS?

The question: The Flexbox options modal feels disorganized — a single element renders a Section band, a Flex row, a Grid, or a plain Block depending on an HTML Tag and a Display select, and the one modal shows every option for every kind. Since nobody switches a root section to a div, or a flex to a grid, after dropping it — should we split the Flexbox into separate shortcodes / item types per kind so each has its own clean, tailored option set?

The question: A section is a grid of image tiles, each a photo with a title overlaid on the bottom (over a dark gradient scrim) and a gentle hover-zoom — jukeboxburgers.com's "Our Food Speaks For Itself" grid. What is the best and proper shortcode to reproduce this, and how do we make the deterministic converter translate it 100%?

The question: The modern Div renders through utility classes like d-flex, flex-row, justify-content-center, align-items-center and fw-col-6. The unprefixed ones are literally Bootstrap's class names, and fw-col-6 apes Bootstrap's col-6 — so the output reads as Bootstrap and .d-flex even collides with real Bootstrap if a theme loads it. Do we rebrand the utilities (e.g. a new upw- prefix, or Tailwind-style names), and what do we call the column/grid utility?

The question: In the modern layout model every box is one primitive — a Div you tag section / div / article / aside — so the Width control was offered on all of them, including a Div tagged <section>. That let you make a section 5/6 wide. The classic Section never could. Is a resizable section correct, or should a Section always be a full-width band?

The question: I want the "product reveal" effect — a visual that comes apart to show its internals on scroll / hover / drag. It shows up as several techniques (frame scrubbing, layered separation, true 3D). Do we build one clever element that switches between them, or separate elements? And what do we call the new one, given "explode" is only one of its motions?

The question: A source "feature card" is a bordered panel (fill + border + radius + padding) holding an icon, a title and some content. When the deterministic Site Converter reproduces it natively, which container should carry the box — the icon_box's own Box Style, or the enclosing column's Border Preset? And should the box be a real Box Preset or a one-off scoped CSS class?

The question: A testimonial card frequently ends with a small stat/result footer — a muted label ("Total savings") over an emphasized value ("$14,200", or a lone "40% more closes"). The testimonials shortcode had no field for it. When we add one — an Extra Texts field — what value shape should it take: a repeatable list of {label, value} rows, exactly one label+value pair, or a freeform rich-text footer?

The question: A source page has N buttons with slightly different measured skins. How do we distil them into a clean, faithful set of reusable Button Size presets (.btn-lg, .btn-md, …) that every button can be assigned to?

The question: To make the Steps/Process shortcode "future-proof," should it adopt the shared Card Rows slot designer that Posts, Testimonials, wc_products and team-member use — a drag-to-reorder row/slot layout with a live card preview — or take the smaller step of adding a Box Preset (box_style) that layers onto its existing layout engine?

The question: Some people want the block editor but still want the Unyson+ options framework. Getting elements in front of them could mean porting them to native blocks — block.json, React edit, attributes per option — or exposing the elements that already exist through a bridge. Which, and what does the bridge actually have to do?

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: 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: In practice the special_heading subtitle was almost never used by the Site Converter — a heading's intro line came through as a separate text_block. Two things to settle: (1) should the converter fold a paragraph right after a title into the subtitle, and (2) should the subtitle option stop being a single-line text field and become a rich editor?

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

The question: Should a shortcode's default colours be hardcoded, or should they follow the site's Color Presets (the theme palette) automatically — falling back to the hardcoded value only when the palette isn't available?

The question: when an agent creates a new shortcode, how does it choose where the shortcode lives — and should it ask the user how they want to install / distribute it (child theme vs an uploadable zip they can hand out), or just decide?

The question: The new Card Rows designer lives on a Card tab, but the reusable border/corners/shadow/fill preset you apply to that card is called Box Style (from Box Presets). That looked inconsistent — should we rename everything to one word ("Box tab / Box Rows", or "Card Box Style / Card Box Presets")?

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: the compact rounded-label shortcode — sub-tag, message, leading/trailing icons, optional link — was called announcement_pill. It renders status badges, "what's new" hero chips, eyebrow labels and announcement bars. Is "announcement pill" the right name for it, or should it be badge — and if we rename, do we need a migration?

The question: Should we add an "Icon Badge preset" like Box Presets — a reusable, globally-editable badge style for icons in Theme Settings?

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: to make a demo's animation flow match a heavily scroll-animated reference site, do we bake the continuous "camera ride" into one pre-rendered video / frame sequence that scrubs with scroll (the way the reference site itself does it), or do we keep every card, device screen, image and line of copy as a live page-builder element and drive the camera moves with scroll animation over an optional decorative backdrop?

The question: a "Photo Scatter" effect — photos scattered flat on a tabletop, gliding in from the edges, dwelling, then reshuffling to the next set — is unmistakably a gallery. The core [gallery] element already has 20+ layout designs. So does a new gallery design belong there, or in the Animation Engine's [gallery_3d]?

The question: [posts post_type="fw-portfolio"] already renders project listings with layouts, card styles and pagination. Should [portfolio] stay a lightweight filter-grid and steer users to [posts], or grow into the full portfolio element?

The question: The Posts "Card Style" list felt redundant — several styles are just an image mask or a fill on top of a base layout, and we already have Box Presets. How should image treatments be organized, and should they become a reusable Theme Settings preset?

The question: The Posts grid's Column Gap and Row Gap were plain px inputs. The rest of the builder (Section, Row, Column) takes gaps from the theme's Gap Scale presets. Should Posts do the same?

The question: Posts now has 20-plus card designs. The markup only ever outputs the chosen design, but does the CSS? Should every page with a Posts block load all designs' styles, or only the one in use — and if only one, how do we wire that without a list to maintain as designs keep growing?

The question: The card read-more link can render as a button. Do we add Button Content and Button Styling tabs to Posts that mirror the Button shortcode's options, so the read-more is as configurable as a real button?

The question: I want a shortcode to ship lots of visual designs — and to keep adding more — without the view file turning into an ever-growing pile of conditionals. How should "which design renders" be structured so a new design is cheap and safe to add?

The question: Would it be better to make the testimonial Quote field a wp_editor (a full visual editor) so authors can format their quotes?

The question: The testimonial rating stars showed up as tofu (□□□□□) on a live site. Do we enqueue Font Awesome so the fa-star glyphs resolve, or render the stars some other way that doesn't depend on a webfont being present?