32 posts tagged with "Conversion"

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?