Bug found when using the same components on the page

Support
#1

Sometimes when you use the same components on the page Cornerstone sees them as the same element which means changing the text in heading component A also reflects the same change in heading component B. You also see both elements highlighted in the builder layer overview.

Has this already been reported? We have the issue on multiple sites and refreshing doesnt work right away. But after enough refreshes it fixes it.

I’ve included a screen recording in a hidden note

#2

Hey @100leiden,

Why This Issue Occurs

There are two main reasons this behavior happens in Cornerstone:

  1. Component Instance Linking (Default Design)
    By design, Cornerstone Components act as a single “master” template. If you place the same component in multiple locations on a page, any direct text or style change you make to one instance will modify the master component, immediately propagating that change to all other instances.

  2. React Key / ID Collision (The “Refresh” Quirk)
    Under the hood, the Cornerstone editor is built on React. When you duplicate or place multiple component instances, the builder’s engine generates unique internal IDs (React keys) to track each element.

    • The Cache Delay: Sometimes, the builder’s local state fails to immediately register the new elements with unique tracking keys, causing an ID collision.
    • Because both elements share the same internal ID in the editor’s memory, the builder sees them as the same DOM node. This causes the Layers Panel to highlight both at once, and editing one modifies the other in the browser state.
    • Why refreshes help: Reloading the builder forces Cornerstone to re-parse the page data from the WordPress database, resolving the memory state collision and assigning the elements their correct, separate tracking references.

How to Solve and Avoid It

Depending on how you want to use the elements, you can resolve this in a few ways:

1. Use Parameters (To keep the design synced but have different text)

If you want to keep the styling of the heading component identical across the site but want different text on each instance, you should use Parameters:

  • Open your component in the Component Builder.
  • Select the heading element and click on its text input field. Look for the “Connect / Set as Parameter” option (the cog icon).
  • Create a text parameter (e.g., heading_text).
  • When you place the component on a page, you will now see a Parameters field in the element inspector. Edit the text here. This allows each instance to have unique text while remaining linked to the master design.

2. Detach the Component (To make them completely independent)

If you want to edit the layout, styles, and text of the heading independently:

  • Select the component instance in the page editor.
  • In the inspector pane or Layers panel context menu, click Detach (or Make Independent).
  • This breaks the link to the master component, turning the instance into a standard heading element that won’t affect any others.

3. Clear Caching & Increase Memory Limit

Since this issue occurs across multiple sites and behaves inconsistently, check for underlying state-saving bottlenecks:

  • System Cache: In your WordPress admin, go to Cornerstone > Settings (or Pro > Settings), scroll down to System, and click Clear System Cache.
  • WP Memory Limit: If the editor state is failing to save dynamically, ensure your WordPress memory is not running low. You can increase it by adding this to your wp-config.php:
    define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
#3

Hi Christian!

Thanks for the reply.
The problem occurs inside the drop-in zones inside the components. Since we already work with parameters and push Cornerstones component features to its limit sometimes, we spot these issues.

These little bugs have been occuring since the last couple of updates, like the isVar bug that has been updated in the last release (or beta release). So it’s not something we encountered when we first started setting this up, been using this set-up since 2 years now and these issues only appeared recently.

We first started out with what you have been suggesting with the parameters and populating the child elements through the parameters, but you know how it goes. Clients and colleagues always want a small alternative on what we build for them.

“Can we remove or add a button?” Sure! We can add a button for you that you can edit through the parameter options.
"But what if I want to add more buttons? Like a primary and secondary?" Oh well yeah now we need to alter the whole component or create a separate one.

This is not a viable option, because before we know it, we have multiple variants of the same component. So that’s why we use the drop-in zones to create that flexibility. We build all the individual elements and give the user the freedom to put them inside these drop-in zones. The reason we love and are committed to Cornerstone and Pro is because it lets us scale in complexity. Take full control over everything, forms, woocommerce, layouts and archives. Something your competitors lack. So when you suggest these things, it means we lose this advantage and it defeats the purpose.

Just my 2 cents :slight_smile:

Bug that breaks the whole component usage that has not been fixed in the new update
#5

Do you think you could export the page with this problem and send it to me? Or send the site with login credentials for me? I just want to make sure I see your page is in the flesh.

image