Release Notes

If you made a field editable on a layout container — the box that holds a button or a card, rather than the text or image inside it — the component recorded that field incompletely. Nothing complained: it saved, it read back correctly, and the page rendered exactly right on the front end. But when you selected an instance in the editor, the whole left panel was replaced by a red "Something went wrong", and every field on that component became uneditable, not just the one. That combination is what made it so hard to place — a section that looks finished on the canvas and cannot be edited at all.

Two things fixed. New fields are recorded correctly from now on, on both of the routes that create them. And because there was previously no way to correct a component this had already happened to, there is a new repair: point it at one component or let it sweep the whole site, and it lists exactly which fields it would change before touching anything. It only fixes fields that are genuinely broken — a field on a normal text, image or button element is left completely alone — and running it a second time does nothing, so it is safe to re-run.

Found by an agency using NVBC on a live build, and reported with enough detail to pin it to a single stored value.

The class tool takes an action — add, remove, or replace — and a list of classes. If either was left out, it quietly assumed "replace" and "with nothing", which is the most destructive thing it can do: every class on the element gone, and a cheerful success message. It was easy to trigger by accident, because writing {"add": [...]} instead of {"action": "add", "classes": [...]} is the natural mistake — and it left nothing pointing at the class tool, so the missing styling reads as a stylesheet problem and sends you looking somewhere else entirely. Neither value is assumed any more. Leave one out and you get a refusal that says why; use a class name as the action by mistake and it tells you the exact wording to use instead. Every response now also shows the classes before and after, and calls out anything that was removed — so a destructive result is visible immediately instead of on a follow-up check.

Reading a post's custom data could report "empty" when it was full. WordPress hides internal fields from a bulk read, and on a page built with Elementor every field is internal — so the answer came back completely empty and looked like a definitive "there's nothing here". It now says which fields were hidden and how to ask for them, so an empty result can no longer be mistaken for an empty post. (The same treatment already applies to the audit tools.)

You can now read a component's editable fields. If you build a reusable component in Elementor and expose fields on it, placing a copy and filling those fields in one step needs their names — and nothing could tell you them. There is now a tool that lists every field, what it is called, which group it is in, and what it is attached to. The component list also shows a field count per component, which immediately turns up components with no editable fields at all. And inspecting a component no longer costs a full export: a lighter option returns just the structure, around 57% smaller on a typical component.

Three styling values that were documented wrongly or not at all. Backdrop blur is supported (our own notes had said it wasn't); opacity needs a percentage rather than a plain number; and edge positions use start/end wording rather than top/left/right/bottom. All three now carry a copy-paste example, because each failed in a way that gave no clue the format was the problem.

This is the most consequential fix in a long while, because of how completely it hid. When a section or element was added with its styling classes named in plain English — the obvious thing to write — NVBC was supposed to swap those names for the internal IDs Elementor actually matches on. On two of the tools that add content, it wasn't doing that at all. The result was not one class failing. It was Elementor declining to write the page's shared stylesheet at all, so every shared style on that page stopped applying, including ones that were set up perfectly. And nothing said so: the class names were still on the elements, the class list still showed them as present, and the page validated as correct. The page just looked like the design system had been switched off, in a way that reads like a completely different problem. Both tools now resolve names properly and report exactly which ones they swapped, so you can see it happened. If you have pages built before this release that look unaccountably unstyled, the existing repair tool fixes them in one call.

A style setting that Elementor doesn't support used to save, report success, and do nothing. You could set it, re-read it, and see it sitting there — while the actual stylesheet never contained it. Five real cases had shipped that way, including one that had been quietly doing nothing for months on a section we'd built, reviewed and measured. NVBC now refuses these up front, names the setting, and tells you what to use instead — checked against your own installed version of Elementor, so it can never fall out of date. The same check was added to the component library, where it immediately found eight dead settings across six shipped sections; all removed.

Elementor's own elements come with styling you didn't set, and now you can see it. Tabs arrive at a fixed width with a grey border; form fields arrive at a fixed height. Anything you don't explicitly override, those built-in styles keep — which shows up as "half my styling applied", looks like a bug, and isn't one. Asking NVBC about an element now lists what it already sets before you touch it, including its hover and focus states — the case that matters most, because a tab's built-in focus styling can leave keyboard users with no visible highlight at all unless you deliberately override that state.

Smaller fixes, all of them things that previously failed quietly: adding content while keeping your own IDs no longer leaves some elements with no ID at all, and the validator now says "3 elements have no ID" instead of a confusing empty "Duplicate IDs:" message. Custom HTML attributes written in a near-miss format — which render perfectly and would only have surfaced weeks later as "the client can't save the page in Elementor" — are now corrected automatically. When a style value is rejected, the explanation is about the setting that actually failed, listing the values it accepts, instead of a fixed paragraph about a different setting entirely. And a class's position in the styling order is now reported every time you write one, so which of two overlapping classes wins is a fact you can read rather than deduce.

In Elementor's newer V4 forms, a field's label is tied to its field by a matching name rather than by sitting next to it — so a single mistyped character breaks the link. Nothing about the page looks different: the label is right there, in the right place, correctly styled. But clicking it does nothing, and a screen reader reads the field out with no idea what it's for. NVBC now checks that every label actually points at a field that exists, that no field is left without a label at all, and that no two elements share an ID (which quietly breaks label clicks, anchor links and assistive technology alike). Each warning names the element, quotes the label text so the fix is obvious, and explains it — and none of them stop you saving the page. A placeholder is called out as not a label, because it disappears the moment someone starts typing. The report also stopped being ambiguous about its own silence. It used to say nothing when it found nothing — which reads identically to an older version that couldn't check at all. It now always lists the rules it ran, so a clean result is a genuine all-clear, and it says plainly what it doesn't cover: colour contrast and keyboard order still need a person. Two smaller fixes with real consequences. Form labels and submit-button text were invisible to the content and placeholder checks, so a form page could be reported as having no copy on it — and leftover template text sitting in a field label would never have been flagged. Both are read properly now. And when styling a hover, focus or checked state, an unrecognised state name used to be silently discarded — the styling saved, reported success, and simply never appeared. NVBC now rejects it up front and tells you exactly which states Elementor supports, including three that do work and weren't documented.

This is one of the most important reliability fixes NVBC has shipped, because the thing it corrects was reassuring rather than broken. Several checks — placeholder text, content extraction, contrast, stray styling — were written before Elementor's newer V4 sections existed, and on a V4 page they simply found nothing to look at. They didn't error. They returned zero problems, which is indistinguishable from a page that has no problems. Four separate builds shipped defects that way: unreadable colours, leftover placeholder copy, and pages the tools had never actually read. Two things changed. First, the checks that can read V4 sections now do. Placeholder scanning and content extraction understand V4 headings, paragraphs, buttons and images — on one 20-section page all 20 had been reported as "empty" while 19 were full of copy, and on another the tool could see only 204 of its 919 words. Both now read the whole page, which also means leftover template copy inside a V4 section can finally be caught. The same fix covers sections converted to plain HTML, which had likewise been called empty while holding pages of real content. Second, and more important in the long run, every report now states plainly what it could not check. Each carries a verdict — checked everything / checked part of it / checked nothing — plus a count of what was skipped, the reason, and what to do about it. A zero is now either a genuine all-clear or an explicit admission, never an ambiguous number. Two known gaps became visible instead of hidden. The contrast check still can't resolve colour that comes from a shared class, so on a V4 page it says so and names the elements for you to check. And it's now stated outright that it checks text contrast only — a button whose background is nearly the same shade as the band behind it will pass, because its label is perfectly readable; that case needs a human eye. The stray-styling report also got more honest. It was over-reporting: on one page 15 of 32 flagged items were styles that set nothing at all, so nothing had been lost and there was nothing to repair. Those are now separated out and named rather than counted as faults — cutting that page's list nearly in half — and the report states that its findings come from your saved page data rather than the rendered page, so they're candidates to confirm before you change anything.

Two fixes to how a page's styles are applied, both of which were quietly changing what visitors saw. The important one is invisible until you go looking for it. When you set a value directly on an element — or edited a class in Elementor's Class Manager — one of NVBC's own shared styles could silently override it. Everything looked plausible, nothing warned you, and the value you'd set simply never took effect. The cause was where NVBC's stylesheet was being placed on the page: it was landing after everything Elementor writes, so on any property both touched, NVBC won by default. It's now placed deliberately — after Elementor's built-in defaults, which the shared classes are meant to override, but before your own element-level and Class Manager styling, which now takes precedence as it always should have. On one test page this restored 47 settings that had been authored correctly and never applied, including card rows that had been told to match heights and didn't. It also means editing a class in the Class Manager now behaves the way it appears to. The second fix is one you can see. Cards with a lot of copy were silently truncating it — the text was cut off mid-sentence with no scrollbar and no indication anything was missing, and in one case an entire card was hidden. This was worst on phones, where cards stack and the problem affected nearly twice as many of them. Cards now always grow to fit their content, at every screen size, with no change to their width or layout. A related fix stops sections from collapsing to nothing on phones, which had been hiding a video entirely on narrow screens. Alongside these, muted body and caption text now meets WCAG AA contrast on tinted backgrounds — a colour correction that had been made previously but was being overridden by the same stylesheet problem, so it had never actually reached the screen.

Prompted by a real migration of 62 posts and 10 categories, where the tooling worked but made the job far harder than it needed to be. The most important fix is a quiet one. Assigning a category by name used to report success while assigning nothing at all — categories, unlike tags, could only be set by ID, and an unrecognised name was discarded without a word. A migration therefore looked finished while none of its categories had landed, and you'd only discover it in a later audit. Category, tag and custom-taxonomy terms can now be set by name, slug or ID interchangeably, anything missing can be created as it goes, and anything that still can't be resolved is named back to you with the reason. Fixing that surfaced something worse, now also fixed: a failed name lookup didn't just skip the assignment, it wiped the categories the post already had — so on existing content the old behaviour could quietly remove work rather than merely fail to add any. You can also create categories and tags directly now, including parent/child nesting, where before they had to be hand-made in wp-admin first; creating them twice is harmless, so an interrupted import can just be re-run. On top of that: create or update up to 200 posts in one step, with shared settings written once, one bad row skipped rather than aborting the whole run, and duplicate-safe resuming matched on slug (more reliable than title, which can collide or contain symbols that don't survive the trip). Every create and update now reports the categories, SEO and featured image it actually applied, so there's nothing left to double-check, and a whole archive can be listed with its categories, excerpts and SEO in a single call instead of one lookup per post. Finally, old classic/HTML content converts to real WordPress blocks — headings, text, lists, images (keeping captions, links, and matching them to your media library), tables, quotes, code, separators, YouTube/Vimeo embeds and shortcodes — instead of landing as one untouchable block of HTML. You choose whether to keep existing inline styling exactly as it looks or strip it for clean on-brand blocks, and it tells you how much converted either way. Anything it can't map is preserved rather than dropped, and it never modifies the original — it previews, or writes a new draft.

Some of NVBC's richest sections — the comparison table especially — rely on the plugin being active in order to be saved from the Elementor editor. The page always renders fine without it, but with the plugin gone the editor would refuse to save that page again. A new eject action removes that tie for good: point it at a section and it converts it into ordinary HTML, keeping the markup identical — same table structure, same headings, same screen-reader behaviour, same text — and freezing the section's styling in alongside it so nothing changes visually. Your site's brand colours, fonts and spacing stay live references, so an ejected section still follows a rebrand instead of hardening into fixed values. It previews everything before writing, never touches the original (it can write to a different page, and keeps a copy of what it replaced), and won't run by accident — it's an explicit, one-way call, and the ejected section is no longer editable piece-by-piece in Elementor afterward. Two things it does deliberately: it refuses rather than guesses, listing exactly what it can't safely convert (per-element custom styling, dynamic content, nested components) instead of dropping it silently; and it tells you when the page isn't finished yet — ejecting one section doesn't free the whole page, so it reports how much still depends on the plugin and says plainly whether the page would now save with NVBC switched off. Verified by actually running the site with the plugin disabled: the converted page saves cleanly where the original could not, and renders identically. Currently covers layout containers, headings and body text — everything the comparison table is built from.

If you (or your AI client) send content for a field the block doesn't have — a small misspelling like "body" where the block expects "description", or "heading" where it expects "headline" — that content used to be discarded in silence, leaving the block's own sample text in place. The page then looked finished while quietly showing placeholder copy, and nothing flagged it. Now every ignored field is reported back by name, along with the list of fields that block actually accepts and a plain statement that the slot still holds placeholder text — so a typo is a five-second fix instead of something you discover on a live page. This applies to both a block's main fields and the fields inside its list items (cards, steps, testimonials).

Two fixes to how list sections lay out. (1) The testimonials section was never really a grid — its cards sat in a single row that just got narrower every time you added one, so five testimonials ended up squeezed to about 240px each. It's now a proper grid that wraps: five testimonials come out as three-plus-two at around 420px each, and the same fix means it adapts to any number you add. (2) Each list block now knows how wide its own content needs to be. Previously up to five items were always forced onto one row, which suits slim numbered steps but crushes content cards. Blocks now carry their own sensible maximum per row — slim step blocks still go five across, feature cards top out at four, testimonial cards at three — and anything beyond that wraps into balanced rows rather than a full row plus a lonely leftover (four heavy cards come out two-and-two, not three-and-one). (3) Feature cards now carry a soft tint so they read as distinct panels on a white background instead of disappearing into it, and the block now tells you that icons, while optional, are recommended — a card with no icon renders as plain text and looks unfinished next to its neighbours. Place that block on a white/plain band, since a tinted card needs an untinted background behind it.

The process/step blocks (3, 4, 5 and 6 steps) were built to an older look and stood out when dropped onto a current page. They now use your site's own colours and type scale throughout: the numbered circles are filled in your accent colour with a white numeral instead of a pale circle with a faint grey ring, the eyebrow, heading and step titles sit on the same type scale as every other section, and the band's tint matches your other tinted bands rather than reading warm against them. Two spacing fixes come with it: the section's left and right edges now line up with every other section on the page — including on phones, where it previously ran edge-to-edge with no margin at all — and its top/bottom spacing matches the standard band rhythm. The numbered circles also no longer change colour on hover: they aren't clickable, so the hover was promising something that never happened. The connector line between the steps still lines up exactly as before.

Four fixes to how sections are built and checked on Elementor sites. (1) A list block's layout follows the number of items you added. Blocks that hold a list — feature cards, process steps, category grids — used to be locked to three across whatever you gave them, so four steps rendered as three-plus-one and eight cards left an empty cell dangling in the last row, both needing manual cleanup in Elementor. Four steps now fill a row of four, eight cards land as four-by-two, and larger counts pick the arrangement that fills every row; tablet and phone layouts adjust with them. (2) Each list block tells you the item range it's designed for. A block that recommends a maximum used to accept far more without a word; it now says when you've gone past what it was designed to hold — while still building the section — so you can judge whether it reads well rather than finding out on the page. (3) The stray-spacing check now reads spacing the way the browser does. It used to flag correctly-built V4 sections as problems because it couldn't see spacing set in the element's own style panel — most of what it reported on a clean page was a false alarm. It now reports only real problems, and its one-click fix finally repairs V4 sections too, which previously had to be corrected by hand. (4) New sections arrive without that stray inset at all — anything NVBC adds to a page, including whole hand-authored sections, imported templates and nested groups of containers, has Elementor's unintended 10px inset cancelled as it goes in, so bands line up with the rest of the page from the start. Spacing you set on purpose is never touched.

The block library you could previously reach through an AI client now has its own screen in the WordPress admin (NVBC → Block Builder, on Elementor sites). Pick a block from the searchable library on the left, fill in its fields on the right, choose a page, and click Insert — your copy goes in exactly as written and the section lands as native Elementor with its styling intact, no AI involved. The form is built from each block's own fields, grouped and clearly labelled: required fields are marked, list-style blocks (testimonials, feature cards, process steps) get Add/Remove buttons for as many items as you need, and fields that assert something real (a rating, a person's name, a credential) are flagged "evidence" so they're never pre-filled with placeholder text. A built-in Sitewide re-emit panel lets you refresh every placement of a block at once — it previews the matches first and only writes when you confirm. This is the fastest, lowest-effort way to assemble on-brand pages, and everything stays fully editable in Elementor afterward.

A new, low-effort way to assemble pages that keeps your copy exactly as written and stays fully editable afterwards. (1) A library of proven, on-brand section blocks — hero, content splits, call-to-action band, testimonials, feature cards, and process steps — each placed by simply filling in its fields (heading, body, buttons, list items) with your text used verbatim; no re-writing, no guesswork. The blocks that hold lists (testimonials, feature cards, steps) let you add or remove as many items as you need. Every block brings its own styling with it, so it looks right the moment it lands and keeps working even if the plugin is later removed. (2) Fields now carry friendly labels and groupings, and can be flagged as "evidence" (a real rating, name, or credential) so they're never auto-filled with placeholder text. (3) Update a placed block everywhere in one step — change a shared call-to-action's link or heading across every page that uses that block, without hunting page by page; it previews the matches first and only writes when you confirm. (4) Behind the scenes, browsing the block library is now much lighter/faster for your AI client, and a caching issue that could show stale content right after an edit was fixed.

Three fixes for the native-component workflow on Elementor V4 sites. (1) Placing a component no longer leaves its section slightly narrower than the rest of the page — the wrapper NVBC creates around a placed component used to pick up a stray 10px inset, which nudged a full-width band in from the edges and knocked it out of line with every other section; it now sits flush like the others. (2) Curating a component's editable fields no longer wipes fields you added in the Elementor editor — relabelling or adding one field used to silently replace the entire set, quietly discarding anything you'd made editable in the editor since. It now merges by default (your other fields are kept), tells you up front exactly which fields a change would remove, and only replaces everything if you explicitly ask it to. (3) A new check finds — and can fix — sections carrying that stray inset, one page at a time, so any bands placed before this fix can be brought back into alignment.

Building on the previous release's component control, you can now use components the way a page-builder should. (1) Drop a component onto a page and fill in its content in a single action — pick the component, set its fields (heading, text, buttons, links, image) by their friendly labels, and it's placed and populated at once. (2) Edit an instance's fields directly, without detaching it — change the copy or links on one placement while it stays connected to the source component, so later updates to the component still flow through. Every value is checked against the component's own field rules before saving, so a bad value is refused up front instead of breaking the page. (3) Detaching now keeps your filled-in content — previously, detaching an instance you'd customized was blocked; now it inlines the instance with your edits baked in, so you can fill a component and then detach it to make a structural change (add or remove elements). (4) Bulk find-and-replace now reaches Elementor V4 text — heading, paragraph, and button copy on V4 pages is now included in a page-scoped find/replace, making it practical to re-word or rebrand a V4 page's copy in one pass.

On Elementor V4 sites you can now manage the editor's own Components (right-click → "Create component") end-to-end through NVBC — not just export them. (1) Create a component from any section already on a page — your AI client saves that section as a reusable component with its design intact. (2) Name and organize a component's editable fields into folders — give each instance-editable field (text, icon, image, link) a clear label and group it into named folders (e.g. "Content", "Call to Action", "Stats"), so anyone editing an instance sees a tidy, understandable panel; it can also expose a new field on an element that wasn't editable before. (3) Detach an instance back into normal, independently-editable elements when you want to customize one placement without affecting the component. (4) Delete a component safely — before removing one, NVBC checks every page for places that still use it and refuses to break them unless you explicitly force it. Each of these previews what it will do before making any change. Also: editing components is snappier — component changes no longer rebuild the whole site's stylesheet cache, only what's actually affected.

Clicking Save Tokens used to overwrite the entire token set with just the fields on screen — so values managed elsewhere (parts of the color palette, the fluid type and spacing scales, URLs, button settings) could be silently wiped. Save now merges your edits into the existing tokens instead of replacing them, and the color palette shows every color it stores, so nothing gets dropped on save.

Groundwork for the brand-kit system, so a site's whole color identity is driven from one place. (1) The full accent family now remixes together — as well as your main accent color, its soft/tint and on-dark variants are now first-class brand tokens, so changing your accent updates the whole family everywhere in one save. (2) New "Auto-map v4 Variables" button on NVBC → Design Tokens — it matches your brand-token colors to your Elementor V4 Variables by color value, so the two stay wired together even when their names differ (your token "secondary" and an Elementor variable named "accent" are recognised as the same color). Previously this had to be filled in by hand. It previews what it will map, explains in plain language what it will add versus what it leaves untouched (so you can save with confidence), and prompts you clearly to click Save Tokens to apply. (3) The Design Tokens screen now shows every color's variable mapping (with a color swatch), instead of just three — so the whole map is visible and editable. (4) Removed two unfinished tabs ("Component Styles" and "Template Library") that were placeholders — styling is handled through Design Tokens and native Elementor settings, and section building through your AI client, so nothing is lost. (5) "Push v4 Variables" no longer creates duplicates. It now updates the Elementor V4 Variables your tokens are already linked to (and reuses any existing variable that already holds the same color) instead of making a second, parallel set — so pushing keeps one clean variable per color and your components keep following it.

Three accuracy fixes to the audit tools on Elementor V4 sites. (1) The page-weight audit's estimated DOM-node count used a rough one-size-fits-all formula that badly over-counted modern V4 pages (a real 1,500-node page was reported at ~2,400 and wrongly flagged "too heavy") and under-counted small ones. It now estimates per element type and accounts for your theme's header/footer, landing within about 10% of the real rendered count — so the "heavy page" warning fires only when a page truly is. (2) The nested-padding audit no longer flags containers whose spacing is already handled by a style class — on a typical V4 page this cut false alarms from ~250 down to the handful that are real, which also makes its auto-fix safe to run. (3) "Find elements by class" now works when you search by a class's friendly name (e.g. nvbc-meta-item), not only its internal ID — so it returns the elements that use it instead of nothing.

Two site-management additions. First, you can now cap how many revisions WordPress keeps for each page or post — or turn revisions off entirely — from NVBC → Features → Max Post Revisions. A common, invisible cause of database bloat is WordPress storing a full copy of a page on every save and never cleaning up; capping to the last 10–20 keeps a useful undo history without the pile-up. It's applied safely without editing any server files, warns you if a revision limit is already set elsewhere on the site, and only limits new revisions — it never deletes ones you already have. Second, the change-log tab is now MCP Revisions and makes it clear who made each change: for edits made through an AI client it shows the named connection that made them — the connection is the real actor, since anyone can create one — and flags in pink any connection that no longer exists (revoked or renamed). The tab also explains how this differs from WordPress's own revisions, and lets you set how many log entries to keep per page so the log itself stays small.

On Elementor V4 sites, setting a heading or paragraph's HTML tag (h1–h6, or p/span) through your AI client could save it in a form Elementor refused to accept — making the editor unable to save the page, with no way to undo it short of deleting and rebuilding the element. NVBC now stores the tag in the exact format Elementor expects, so headings set by your AI client save cleanly. An out-of-range tag (like "h7") is rejected up front with a clear message instead of a cryptic error, clearing a tag resets it to a sensible default instead of jamming, and the "fix atomic validation" repair now also corrects any headings already stuck this way on existing pages.

Your AI client can now delete an Elementor V4 kit variable, and run a one-shot hygiene sweep that clears out the junk that builds up over time — duplicate style classes (e.g. leftover "DUP_" copies from imports), empty placeholder classes that clutter the Class Manager, and duplicate variables. Both are careful by default: they preview what they'd remove without changing anything, and they refuse to touch a class or variable that's still used anywhere on your site unless you explicitly override. Nothing in active use gets removed by accident, and class deletions can be undone from a snapshot. (Deleting a global class was already supported; this fills in variable deletion and the batch cleanup.)

Three fixes to how NVBC writes Elementor V4 (atomic) content and styles: (1) Headings, paragraphs, and button labels created through your AI client are now stored in the exact format Elementor expects — previously they could be saved in a way that made the editor refuse to save the page with an "invalid value" error. (2) The existing "fix atomic validation" repair now also corrects this on pages already built, so an affected page can be repaired in place instead of rebuilt. (3) When your AI client creates or edits a style (a global class or an element's own styles), NVBC now checks the values against Elementor's own rules before saving and rejects a bad one with a clear explanation — instead of quietly storing something invalid. This matters most for box shadows: one malformed shadow in a shared style used to block saving on every page of the site, and now it's caught the moment it's written.

Global style classes applied via NVBC rendered correctly on your live site but didn't always appear as editable chips in Elementor's V4 Style panel — so you (or your client) couldn't see or adjust them by hand, even though they were working on the front end. NVBC now keeps the editor's own class list in sync on every class write, so a class your AI client applies is immediately visible and editable in the editor, not just live. Existing sites self-correct on the next class change.

On sites with many Elementor V4 global classes, a rare timing issue could make style classes silently vanish from the Class Manager during AI-assisted editing — stripping their styling from every element that used them. NVBC now protects the class registry by reconciling each write against your actual saved classes, so an incomplete read can never delete a class that still exists. Your built work stays intact as you keep editing.

If you've built a section using Elementor's own native Component feature (V4 sites), your AI client can now export it straight into the same shippable format the component library already uses — no need to rebuild it by hand for other sites. Also fixed a save error ("Styles validation failed... padding: invalid_value") that could block saving after AI-assisted edits to a container's spacing.

Pre-built sections that rely on a shared style class or a brand color/font/spacing value now bring those along automatically when inserted on a site that doesn't have them yet — instead of rendering unstyled. If the target site already has its own version of that style or color, yours is left alone rather than overwritten.

In rare cases, an empty style class slated for deletion could share its identity with a real style still in use elsewhere — deleting the empty one would quietly strip the working style too, with no warning. Your AI client now checks for this before deleting and refuses automatically if it finds a conflict, explaining exactly what's colliding and where. An explicit override is available for the rare case where deleting through the conflict is actually intended.

Fixed a bug where adding or removing a style class through your AI client wouldn't visibly change the page — the change was saved correctly, but the site kept showing the old look until some unrelated edit happened to refresh it. Class edits (and a few related actions — rolling back a change, repairing class references, patching a template) now take effect on the very next page load, no extra steps needed.

Over time, building with an AI client could leave dozens of empty, unused style classes cluttering Elementor's Class Manager and style picker — making it hard to find the styles that actually matter. Your AI client can now delete unused Elementor style classes (with a safe "only if empty" mode and a preview-first dry run), and the cause of the clutter is fixed so it stops accumulating in the first place. Every deletion is snapshotted, so it can be undone. There's also a new read-only check that flags elements whose styling quietly stopped applying due to the old issue, so you know what to review.

Your AI client can now build a real, named Elementor style class — a pill, a card, an eyebrow, any recurring look — that shows up in Elementor's own Style panel with editable controls (colors, spacing, typography, borders) and applies site-wide from one place. Change the class once, every element using it updates. Unlike ad-hoc CSS, these classes stay visible and adjustable by a human in the editor afterward, and they render correctly for logged-out visitors right away — no editor re-save needed.

If the Elementor editor refuses to save a page with an "invalid values" error, NVBC now tells you exactly which element and which setting is at fault, instead of leaving you to hunt for it. It checks your page against Elementor's own rules — and also checks your shared class library, where a single broken class quietly blocks saving on every page of the site, not just the one you're editing. Especially useful on pages built by an AI client, which can otherwise introduce a setting Elementor rejects with no visible warning until you try to save.

Ask your AI client for a preview link to a draft, pending, or scheduled page — it works for anyone who has the link, no login required, until it expires (an hour by default) or you revoke it. Never appears in search results while the link is live. Also added: an optional white-label mode so an agency's own installs can hide the NVBC name from the plugin's admin surfaces entirely.

Your AI client can now read the site's PHP error log, check server/PHP configuration for common performance issues (memory limits, caching status, and more), and turn on temporary detailed error logging for a limited time — without editing any server files. All three are opt-in per site (NVBC → Features → Troubleshooting Tools).

Audit reports no longer dump every finding onto one long page — easier to scan on sites with a lot of findings.

Team members who aren't admins can now generate their own scoped MCP connection from their WordPress profile page, instead of waiting on an admin. Application passwords created outside NVBC are now automatically covered by the same permission rules as ones NVBC issues directly, closing a gap where they'd otherwise get full, unrestricted access.

Every MCP connection can now be restricted to a role — Auditor, Content Editor, Full Builder, or Admin — or a fully custom set of allowed and blocked actions. Restrictions can only take away access, never grant more than the WordPress user already has, so it's safe to hand a scoped connection to a client or a junior editor.

The connection tab now generates the right configuration automatically depending on whether you're connecting Claude Desktop or Claude Code — one less manual step.

Individual audits are now grouped into scored "Skills" — SEO, Performance, Accessibility, Content, Links, and (Elementor sites only) Editability — each returning one ranked, client-ready report instead of a pile of raw findings. Scoring was also refined to weigh findings by how much they actually affect the site, not just how many there are.

Add, update, remove, or move a single navigation menu item directly, without resending the entire menu — and without losing the active-page highlighting that native menu links get.

NVBC now speaks MCP over plain HTTP and through WordPress's own Abilities API (WP 6.9+), alongside the original Node-based connection. For HTTP, it's just a URL and an app password — no local Node install required.