Browser: Chrome 110 OS: macOS / Windows / Linux / etc. URL: Link to a page that illustrates this issue Video: Short screen recording that illustrates this issue (free tool: jam.dev)
Hi Bricks Team,
I’m relatively new to using Bricks and have encountered a critical issue after cloning my live site to a staging environment on Kinsta.
The live site works perfectly, but after using Kinsta’s Push to Staging feature for further development, the **staging site crashed with a fatal error:
There has been a critical error on this website.
(Standard WordPress fatal error message)
The Kinsta error log shows the following PHP error:
PHP Fatal error: Uncaught TypeError: array_column(): Argument #1 ($array) must be of type array, false given in /themes/bricks/includes/helpers.php:1060
After investigating, I found:
The crash was caused by a call to Bricks\Helpers::get_component_by_cid('hhhmzg')
hhhmzg is the ID of a global sticky header I had saved and reused inside both the Transparent Header and Normal Header templates
On the staging site, the global component appears to be missing or not properly resolved, causing get_component_by_cid() to return false
This led to a hard crash because array_column() was called on a non-array value, without any validation
As a result, Bricks was unable to load any page or template, including the Builder itself — making recovery extremely difficult without directly editing the database to remove the broken references.
Additional Information:
Bricks version: 2.0
PHP version: 8.3
Hosting: Kinsta
Issue only occurs on staging (live site is unaffected)
Fix required manual DB cleanup (deleting header templates and broken global component references)
that’s interesting. By reading your description, it looks like the cloning was not done properly.
Were there any errors that would indicate the issue when cloning?
Kinsta’s native cloning process completes without any error prompts. However, I’ve encountered a specific issue with this project that’s worth highlighting.
When I use the All-in-One WP Migration plugin to migrate the multisite to another server or environment, everything works as expected. The issue arises only when pushing the site from Kinsta’s live environment to staging or vice versa.
The missing component is the global “Sticky Header”, which is used in both the transparent and normal header templates. I’ve assigned it a custom class (sticky-header), and Bricks also auto-generates a default class (.brxe-hhhmzg) based on the component ID.
After pushing from live to staging, I ran the following SQL query:
SELECT ID, post_title, post_name, post_status
FROM wp_posts
WHERE post_type = ‘bricks_template’ AND post_content LIKE ‘%hhhmzg%’;
This returned no results, indicating the referenced component is missing on the staging site.
My working theory is that Bricks may:
Use transient cache or custom structures (like structure or builder cache) that aren’t stored purely in the database;
Require a manual save and structure regeneration to ensure all builder data is committed before cloning;
Depend heavily on internal component IDs (CID) — if a component is unsaved or removed, the reference may persist but the actual data won’t be included in the clone.
Thank you for the additional info. Because of the following, it sounds like Kinsta specific issue. Can you get in touch with Kinsta first, as they may be already aware of it?
I usually migrate my websites using WPVivid or Duplicator, and I can confirm that I have not yet come across issue like this.