50 posts tagged with "Conversion"

The question: "Blog posts should be in posts, right? ... and for posts, we should probably just grab the content and check if it is just using the plain text editor." And then: "does that include custom post types as well? We can also make the site converter write custom post types in functions.php, right?"

The question: Now that the converter is going to write Elementor pages — and Divi, Bricks and the rest after it — how should it be organised so that each new builder is cheap to add, and none of them can break the Unyson+ output that already works?

The question: the measurement tools had grown to ten files. Were they duplicating each other, or conflicting? And if so, should the overlapping ones be merged?

The question: the converter never seemed to overwrite pages like /about/ — they kept content from an earlier conversion. Should it force an overwrite, with a notice so the user can opt a page out?

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: A converted section is a horizontal auto-scrolling marquee — jukeboxburgers.com's #menu-adjacent reel strip: a flex row of video cards looping left, pausing on hover. How should the deterministic converter reproduce continuous motion like this — and, more broadly, motion of any kind the Animation Engine can drive?

The question: jukeboxburgers.com sets its headings in Neutraface Condensed Titling — a commercial face we can't legally rehost — with the web-safe Alfa Slab One declared after it. Headings were rendering in Alfa Slab One (a wide slab — completely wrong proportions for a condensed titling face). Why did the converter "rule Alfa Slab One the closest match", and is there a fundamentally better way to pick the nearest font — should the local AI do it?

The question: the converter can't rehost a licensed source font, so it substitutes the nearest free Google font. A curated name→lookalike map nails the ~40 famous faces (Gotham, Neutraface, Söhne…), but what about the long tail — a bespoke or obscure licensed heading font on some future site the map has never heard of? Is there a tool that finds the closest free font for an arbitrary face, and should we adopt it or build our own?

The question: A converted section is a deep catalog — jukeboxburgers.com's #menu: colour-banded categories (APPETIZERS on white, CLASSIC BURGERS on near-black, CHAPLIN on red), each a grid of {name, description, price} cards, about seven levels deep. It was shipping as one opaque .sc-tw code block (faithful pixels, zero editability). How should the deterministic converter turn it into real, editable builder elements — and how far can that go?

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: 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: Converting jukeboxburgers.com (a restaurant menu — prices shown, but you "Book a Table," there is no online ordering) with Map-to-WooCommerce enabled, should the converter auto-detect that it is a catalog/menu and suppress the shop machinery, or should we add a Catalog Mode option under Map to WooCommerce, or both?

The question: ModFii's logo has no image at all — the icon is a stack of <div>s with gradient backgrounds, rounded corners and a rotate(3deg), beside a "ModFii" wordmark. The converter's logo detector looks for an <img>, an inline <svg>, a library icon id, or wordmark text — a pure-CSS mark matches none, so it was dropped and the wordmark fell back to the bare page title. Should Theme Settings gain a new "CSS-composed logo" mode that stores and re-renders such nested-div/gradient markup?

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: When a converted site sets its headings in a non-Google, licensed display face — jukeboxburgers.com uses Neutraface Condensed Titling, a commercial House Industries family that is not on Google Fonts — the theme generator can't load it. Should the user download and set it manually, should the deterministic + local AI hunt the web for a copy to grab, or should the converter pick the closest free lookalike on its own?

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 block-theme output has an optional enriched vocabulary that emits unysonplus/* blocks instead of core blocks. Should every intermediate type enrich, or do some regions genuinely belong on core blocks even when the user opted into enrichment?

The question: We're adding an "Add entrance animations" checkbox to the Site Converter that gives a converted page sequential reveal-on-scroll motion. The user framed it as "use the deterministic with the help of the local AI." Where should the intelligence actually live — does the AI decide the animations, or does the deterministic converter, with the AI as a helper?

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: The Element Mapping tables classify every shortcode option as native / via-CSS / unmapped. Accordion showed 18 unmapped — which looks like the converter is failing. Is a high unmapped count a problem to drive to zero? Should we hand-author “pre-mapping” data, or do we need a pile of real sites to map everything properly?

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: The deterministic converter classified a source FAQ accordion — clearly a Separated list of cards — as Flush. Should we fix the classifier, or let the local AI companion pick the closest style?

The question: UnysonPlus's spacing and gap scales inherit Bootstrap's $spacers. The gap scale caps at slug 5 (3rem/48px), and both scales jump straight from slug 4 (1.5rem/24px) to slug 5 (3rem/48px). Modern (Tailwind-era) layouts lean on the values in between (32px, 40px) and above (64px, 80px). How should the framework — and the Site Converter that maps real sites onto it — represent those?

The question: To map every shortcode and Theme-Settings option faithfully, does the deterministic converter need an individual detector per option — or is there a better, registration-style way to make all options map properly?

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: The Site Converter's conversion knowledge lived in two places — a deep how-it-works (architecture + algorithm) under the extension docs, and a conceptual how-it-works (capture-first → outside-in → measure) under the AI Dev Kit — and neither was clearly the canonical home. Should we move all the extension's conversion subpages into the AI Dev Kit and reduce the extension section to a basic overview + a link, so all conversion info lives in one place?

The question: After the Site Converter walks a source and clusters every box skin into on-brand Box Presets, what happens to the plugin's four built-in defaults (Card / Outline / Soft Shadow / Hover Lift)? Do the site-derived presets replace them, or do both coexist — and if both, in what order?

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: A converted store should get live WooCommerce shortcodes for its product grids ([wc_products], add-to-cart, etc.) rather than the static image_box cards a generic card grid becomes. Should the converter simply auto-detect WooCommerce from the source and map accordingly — or put a checkbox in the Convert panel, greyed out when WooCommerce isn't installed?

The question: The Site Converter kept producing pages where a shortcode's own CSS or a unysonplus-theme default silently overruled the styles we mapped from the source — headings rendered bold when the source was regular, service-card icons came out green instead of grey, footer address text went black. Each was fixed one property at a time. Should we build a general "checker/detector" that stops shortcode and parent-theme styles from overruling the source?

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. 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: 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: We want the docs site to explain how the deterministic Site Converter turns a source element into a UnysonPlus shortcode — the Priority / Recognizer / Matches when / Becomes table, plus the native options each mapping sets. Two open questions: where does it go — a row added to each /docs/shortcodes/<element> page, or one consolidated table — and do we hand-write it or generate it?

The questions: the opt-in --share flow sanitizes each conversion into a structural-only JSON and POSTs it to a Google Form. (1) Will an external developer's AI agent send us something we can actually use to improve the converter? (2) What's the right consent cadence — does it send cumulatively or per bug; does one "yes" cover the rest of the site; and is it OK to keep asking after a "no"?

The question: the Site Converter is deterministic, so an outside AI agent will hit cases it can't map. Will that make the agent ship a half-baked site? And to fully convert, should the agent fork the converter (or keep a custom converter folder/hook) and report its changes?

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 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: a decomposed element carries styling a shortcode has no option for (a heading's font-extrabold leading-[1.1], a paragraph's md:text-xl text-foreground/70). The Special Heading shortcode — and every shortcode's Advanced tab — has a CSS Class field. Rather than synthesizing Custom CSS for each effect, why not just put the source's own utility classes in that field and let the section's carried CSS render them? Isn't that cleaner and more editable?

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 converter kept producing sections with the wrong spacing, a missing overline color, a dropped background. One proposed fix: extract all of Tailwind's official utility classes (a finite, canonical set) and selectively pre-map each to a shortcode option, so coverage is "complete" and we stop missing things. Is that the right primary mechanism, or a regression to brittle class-name parsing?

The question: while reproducing a source site, the converted output had many small misses (a button missing its shadow-lg, a pill rendered as a plain <span>, borders and paddings off). The fast instinct is to hand-fix that one site — nudge misc_custom_css, tweak a preset value — until it matches. But should the AI hand-patch the output, or should every fix go into the deterministic Site Converter so it produces the correct result on its own?

The question: we already decided the converter's job is to fix the algorithm, not the output. But in practice, when a build hits a section the converter can't map yet (e.g. a WooCommerce product grid), what is the exact, repeatable iteration — and when do you actually write a recognizer versus just hand-build it?

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: Should other developers using the AI Dev Kit have their agents change the Site Converter — and if we instead want them to report improvements back, is GitHub the right place, given not everyone has an account?

The question: Should the kit's theme-settings-reference.md go deeper — documenting every preset's options and all their choices — and split into a folder, one file per main tab?