11 posts tagged with "Extensions"

The question: On the post editor, the new SEO metabox shows SEO title and Meta description as empty boxes — while the counters underneath them report a real pixel width and character count, and the page really does emit a title and a description. If the extension already knows what those values are, why not just pre-fill the two fields with them?

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: With "Minify combined script" enabled, the generated combined-<hash>.js still had one statement per line — it didn't look minified. Is the minifier failing, and should it collapse to a single line like everyone expects "minified" to?

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: Deleting the Mega Menu extension removed it from the Extensions manager entirely — no card, no way to reinstall it. Deleting Breadcrumbs left it listed, offering an Install button. Why do some extensions survive deletion and others don't, and what's the right fix?

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?