isVar in components not working since last update

Support
#1

Hi!

Since the last version of Cornerstone some things broke on our website.
First of all we use fontSize in our heading parameters together with a maxWidth parameter. And since the latest update our headings got the value of the maxwidth instead of the fontSize. I fixed this by changing fontSize to headingFontSize. Are there reserved parameter names? I stacked components, so our hero had a fontSize parameter and so does the heading component inside it. Can this conflict?

The problem I’m having right now is with our components and the isVar property. It’s not working. It’s always returning the desktop value. I tried to disable all plugins, downgrade to 6.8.4, switched to the main theme instead of the child theme and also to copy the component. So far, the problem exists in all scenario’s. However, it cannot be replicated on other websites. Could you guys check if it’s a Cornerstone bug or something we need to fix on our side? In the example I’ll share you will see that the padding values for bottom and top are not updated when previewing different breakpoints. This is the same for the color parameter.

I do sometimes get a few errors in the console:
A couple of “Could not find element cX, ID unknown…”
And:
jquery-migrate.min.js?ver=3.4.1:2 JQMIGRATE: Migrate is installed, version 3.4.1
csslint-tco.min.js?ver=7.0:5 Uncaught ReferenceError: Cannot access ‘ne’ before initialization
at csslint-tco.min.js?ver=7.0:5:9061
at csslint-tco.min.js?ver=7.0:5:9245
at js/vendor/csslint/parserlib.js (csslint-tco.min.js?ver=7.0:6:10765)
at csslint-tco.min.js?ver=7.0:1:250
at csslint-tco.min.js?ver=7.0:8:28934
at csslint-tco.min.js?ver=7.0:8:28941
(anonymous) @ csslint-tco.min.js?ver=7.0:5
(anonymous) @ csslint-tco.min.js?ver=7.0:5
js/vendor/csslint/parserlib.js @ csslint-tco.min.js?ver=7.0:6
(anonymous) @ csslint-tco.min.js?ver=7.0:1
(anonymous) @ csslint-tco.min.js?ver=7.0:8
(anonymous) @ csslint-tco.min.js?ver=7.0:8

Thread got closed while still waiting for an update
#2

Hey @100leiden,

1. Naming Conflicts & Stacking Components

Yes, conflicts can definitely occur when stacking (nesting) components with similar parameter names.

  • Dynamic Content Collision: Cornerstone resolves component parameters using dynamic content tags like {{dc:p:fontSize}}. When you nest a component (like a Heading) inside another component (like a Hero), they share the VM callstack. If both components define the exact same parameter key (such as fontSize), the inner component’s resolution can clash or mistakenly inherit or overwrite the parent’s parameters during evaluation.
  • Reserved Parameter Names: Cornerstone does have internal/reserved control configurations (like id, class, style, css, and built-in CSS/layout variables). Using generic keys like fontSize or maxWidth in stacked components increases the risk of clashing inside the layout parser.
  • Fix/Recommendation: Changing the key name to a more specific descriptor (e.g., headingFontSize) is the correct solution. It ensures the key namespace is unique and avoids collisions in the callstack when rendering nested elements.

2. The isVar Property Always Returning the Desktop Value

The reason the isVar property is stuck on the desktop value is not a bug in the component itself, but a consequence of the JavaScript and PHP console errors halting the execution of Cornerstone’s builder preview engine.

How isVar works under the hood:

When you enable isVar: true for a control parameter, Cornerstone’s CSS engine does not generate static values (like padding: 20px). Instead, it generates CSS variable calls (e.g. padding: var(--param-...)) and relies on a JavaScript-driven preview script in the editor to dynamically update these CSS variables’ values at different preview breakpoints.

If the builder’s JavaScript execution crashes during loading or preview generation, the script that updates these CSS variables fails to run. As a result, the preview defaults to the base (desktop) value and never updates when resizing or switching breakpoints.

3. Diagnosing the Console Errors

The crash preventing your preview script from running is caused by the two console errors:

A. PHP/REST API Exception: "Could not find element cX, ID unknown…"

This error originates from the backend in TreeDataREST.php.

  • What happens: The builder tries to fetch the element tree via the REST API. If a component or element (with ID cX) is referenced (e.g., in a looper, condition, or global setting) but cannot be found in the current layout structure, the server throws a DomainException.
  • The Impact: This causes the REST API request to return a 500 Internal Server Error or malformed JSON data, leaving the frontend builder script with an incomplete layout tree and crashing the editor.

B. JavaScript Crash: "Uncaught ReferenceError: Cannot access ‘ne’ before initialization in csslint-tco.min.js"

This script is Cornerstone’s built-in CSS validator registered in App.php as csslint-tco. The crash occurs due to:

  • Server-level or CDN Minification/Caching: Even if you disabled all WordPress plugins, many hosting environments (such as SiteGround, LiteSpeed, or CDNs like Cloudflare) have server-level minification/concatenation active. This often breaks block-scoped ES6 scripts (like CSSLint’s IIFE structure) by causing a Temporal Dead Zone (TDZ) reference error where variables (minified to ne) are accessed before initialization.
  • Modern CSS in Custom CSS Fields: The CSSLint engine used by Cornerstone is older and does not support modern CSS syntaxes (such as @container queries, CSS nesting, or modern grid layouts). If you have custom CSS in your Global CSS or Element CSS containing these modern declarations, it can crash the parser when loading the builder, causing the JS execution to halt.

Action Plan / Recommended Steps

  1. Disable Server/CDN Optimization: Check if you have CSS/JS minification enabled on your hosting control panel or Cloudflare. Exclude Cornerstone’s editor paths (/x/, /pro/, /cornerstone/) from being minified or concatenated.
  2. Clean up Element References: Inspect your layout, loopers, and conditions to find any references to missing or deleted elements (cX) to resolve the backend exception in TreeDataREST.php.
  3. Inspect Custom CSS: Temporarily cut/paste any Global or Element CSS into a local text editor to see if removing modern syntax resolves the CSS Lint crash.

If that doesn’t help, please copy your site to a staging server then provide the following details in a Secure Note

  • Staging WordPress Login URL
  • Admin username and password
  • Page URL where we can see the issue
  • FTP login credentials

You can find the Secure Note button at the bottom of your posts.

secure-note
secure-note1040×250 15.3 KB

Thanks.

#3

Ive resolved the css lint issue. I had to exclude it to our caching plugin. Is this something that has been added since the last update?

Also, I’ve disabled all plugins + child theme and any global JS. The undefined error still exists, however it pops up sometimes and is not consistent. Does a bug in 1 page infect the whole page builder? Because when I only load the heading component it does not work. It’s pretty hard to debug since we have so many pages. I tried disabling the footer + menu and strip everything from a page, no success.

Edit:
I created a second staging where I stripped out everything. No pages, layouts, menu’s, footers etc. Switched to the main theme instead of the child theme, cleared all caching. Reset the break point values inside the theme options. Deleted transients. Created a fresh component and the responsive values from isVar are not working.

I’ve included the details in my previous comment. Could you guys give me any directions?
Also included the second staging inside the secure note.

#4

Hey @100leiden,

We are investigating the issue. Please stay tuned.

1 Like
#5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

#6

Hey @100leiden,

It looks like there’s an issue with Pro but we need to confirm this with our development team. For now, you can possibly bypass this by flattening your parameter keys so that they are not nested inside a "type": "group" block.

Instead of wrapping them under headingPadding with top/bottom sub-params, define them as top-level individual fields. This prevents path nesting (headingPadding.top) and sidesteps the loop variable clash.

Updated Schema Configuration:

{
  "headingPaddingTop" : {
    "label"    : "Heading Padding Top",
    "type"     : "dimension",
    "initial"  : "0em",
    "isVar"    : true,
    "slider"   : true,
    "keywords" : [ "auto" ],
    "units"    : [ "px", "em", "rem" ],
    "ranges"   : {
      "px"  : { "min" : 0, "max" : 150, "step" : 1 },
      "em"  : { "min" : 0, "max" : 32,  "step" : 1 },
      "rem" : { "min" : 0, "max" : 32,  "step" : 1 }
    }
  },
  "headingPaddingBottom" : {
    "label"    : "Heading Padding Bottom",
    "type"     : "dimension",
    "initial"  : "0em",
    "isVar"    : true,
    "slider"   : true,
    "keywords" : [ "auto" ],
    "units"    : [ "px", "em", "rem" ],
    "ranges"   : {
      "px"  : { "min" : 0, "max" : 150, "step" : 1 },
      "em"  : { "min" : 0, "max" : 32,  "step" : 1 },
      "rem" : { "min" : 0, "max" : 32,  "step" : 1 }
    }
  }
}

Then, map them in your Element CSS accordingly:

$el {
  padding-top: {{dc:p:headingPaddingTop}};
  padding-bottom: {{dc:p:headingPaddingBottom}};
}