101 posts tagged with "Architecture"

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: 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: Every element's options modal took ~873 ms and ~6.7 MB to open. An existing "lazy multi-picker" optimisation was already in place and clearly not working. What is actually costing that, and can it be deferred without risking saved values?

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: fw.js called Backbone.Model.extend and Backbone.View.extend in exactly two places. Replacing them looked like an afternoon. Then the modal underneath turned out to be wp.media.view.MediaFrame — WordPress's media frame, which is Backbone, and which Backbone still loads for anyway. Is removing it worth the risk?

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. 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: qTip2 has been unmaintained since 2016, and we replaced it with Floating UI. The old implementation put its vendor everywhere — .qtip-fw class names, a 'qtip' script handle, $.fn.qtip(). Do we carry that naming over to the new library and call things floating-ui, or name them something else?