31 posts tagged with "Page builder"

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: Creating a new Page opened the Classic editor, with the Unyson+ Builder button sitting there to switch. For a builder-first product that's backwards — the common case (build a page) costs an extra click every time, and a new user doesn't necessarily know the button is the point. Should the builder be the default editor on a new post, and if so, for which post types? Blog posts felt different — those are usually written prose, not built layouts.

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: In the live editor, when you add a Flexbox / Grid / Block Div, should it drop at the page root the way it does in the backend builder — or should it be encapsulated in a Section (placed inside the last section, or wrapped in a new one when the page has none)?

The question: The page builder's new flexbox "Div" is a universal container — arbitrary nesting, flex/grid/block, per-device widths — so the Site Converter could now emit a 1:1 mirror of the source's DOM tree. Should it? Is duplicating the source DOM the right output model?

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: Modern, AI-generated sites are built with Tailwind (flex/grid utilities). Should we just integrate Tailwind into UnysonPlus — swap the plugin's own utility classes for Tailwind's — so the layout model is modern and the Site Converter has an easier job converting Tailwind sources?

The question: Model Viewer's Scroll Choreography asks for each keyframe's At (scroll %) — 0 = start, 100 = end. But a typical author cannot guess that "section 3" is ~48%. What is the best way to help them set it?

The question: A demo panel's numbered steps were emitted as <ol style="max-width:60ch;margin:0 auto 1.5rem;color:#3a4757;line-height:1.9">…</ol> inside a text_block — even though text_block already has native max width, spacing (margin/padding), text colour, line-height and font-size options. Why reach for inline CSS at all, and how do we stop this recurring across sessions that build demos or sites?

The question: the "Duplicate as landing page" importer assigns a page-landing.php template to get a chrome-less, full-width page. But the theme's Page Settings already have Header (Global / Transparent / Hidden), Hide Site Footer, Content Width, and Hide Page Title. So do we need the template at all — and why was the theme footer still rendering on a landing page that had the template assigned?

The question: The page-wide Custom WebGL Background shipped as an on/off switch plus two code editors (Scene DOM and Scene code (JS)) sitting in Page Settings → Animations. It renders a three.js scene behind the whole page. Should all of that instead be one selectable effect in the Animation Engine — for pages only?

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?

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: the engine's model was one effect per element, each firing independently when it scrolls into view. A GSAP timeline is the opposite — several elements animating in a choreographed order with relative timing. How do you translate that into page-builder options a non-coder can drive, without shipping a keyframe editor or a code field?

The question: Builder pages started rendering the theme's page title as an H1 bar above the built content (so "every page has exactly one H1"). Was that a good default — or should the theme title simply be disabled whenever the Page Builder is used, leaving the per-page "Hide the page title" checkbox to classic-editor pages only?

The question: for the 3D Gallery's Scroll-scrub motion, should the gallery pin on screen while the visitor's scroll drives the animation (instead of scrolling past with only a sliver of movement visible)? And should the Motion options become a multi-picker so each mode reveals only its own settings?

The question: we keep building cinematic scroll-driven sites (a pinned "camera ride" frame-sequence background with full-screen text scenes keyed to scroll segments). Should that become a brand-new Animation Engine module / shortcode, or grow out of something that already exists — and either way, how does a typical builder user author one without touching code?

The question: Internal Page-Builder pages ship with no <h1>. Should we require a special_heading (H1) in each page's builder content, or have the theme render the page title as the H1?

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?

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?