Border control crashes block when attributes contain empty arrays (GreenShift 13.2.0)

Hello GreenShift team,

we found a reproducible editor crash in the Border control (GreenShift 13.2.0, WordPress 7.1.2, also affects the Container block and any block using the border attribute).

Summary
When a block’s border attribute contains empty arrays instead of empty objects, e.g.

“border”:{“borderRadius”:{“values”:[],”locked”:true},”style”:{“all”:[“solid”]},”size”:{“all”:[1]},”color”:{“all”:[“#e6e6e6″]},”styleHover”:[],”sizeHover”:[],”colorHover”:[],”custom”:[],”customEnabled”:[]}

the first change in the Border panel silently deletes borderRadius.values, and the next interaction with the radius crashes the block (“This block has encountered an error and cannot be previewed”).

Why the data contains [] instead of {}
Any server-side round trip through PHP (parse_blocks() / json_decode(…, true) followed by serialize_blocks() / json_encode()) turns an empty object {} into an empty array [], because PHP cannot distinguish the two. This happens routinely with WPML (translation jobs re-serialize block attributes), with migrations and with programmatic content updates. On our site 103 posts / 1,615 attribute values were affected, mostly WPML translations.

Root cause in build/gspbLibrary.js (Border control)

clear_null_values() (minified as Qm) deletes properties where the check null != e[t] && 0 != e[t] fails. For an empty object 0 != {} is true, but for an empty array 0 != [] is false ([] coerces to “” and then to 0). So all empty arrays are deleted, including borderRadius.values.
The radius handler then reads o?.borderRadius?.values[e] (4 occurrences). The optional chain does not protect the bracket access, so when values is undefined this throws TypeError: Cannot read properties of undefined (reading 'topLeft').

Steps to reproduce

Insert a Container block and save a post whose content contains the border attribute above (with “values”:[]).
Open the post in the editor, select the block, change any border setting (e.g. width or color).
Change the border radius -> the block crashes.

Suggested fix

Use o?.borderRadius?.values?.[e] in the radius handler, and/or
normalise the border attribute on load (convert [] to {} for values, style, size, color, styleHover, sizeHover, colorHover, custom, customEnabled), and/or
in clear_null_values(), do not rely on 0 != value; check explicitly for null/undefined/”” and treat empty arrays like empty objects.

As a workaround we converted the affected attributes in the database from [] to {}, but they will reappear with the next WPML translation sync, so a fix in the plugin would be much appreciated.

Thank you and best regards
Manfred
cobizz GmbH, Wuppertal

cobizz GmbH

⏱

Sep 25, 2026 at 9:00 am

Replies

GreenshiftWP

Admin

Sep 25, 2026 at 9:03 am

border is not crashing. Problem is in old blocks. Or if you used agents and it’s added wrong data.

just clean border (click on clean button) and add border that you need
cobizz GmbH

Member

Sep 25, 2026 at 9:31 am

Subject: Re: Border control crashes block when attributes contain empty arrays (GreenShift 13.2.0)

Hello,

thank you for the quick reply. We double-checked your suggestion, and unfortunately “Clean” only helps until the page is saved and opened again. We could reproduce the crash with a block that was created with exactly the data GreenShift itself saves, without old blocks and without any agent involved.

Test setupWordPress 7.1.2, WooCommerce active, GreenShift 13.2.0. A new draft page with one Container block, border 1px solid, stored exactly as GreenShift saves it:”border”:{“borderRadius”:{“values”:{},”locked”:true},”style”:{“all”:[“solid”]},”size”:{“all”:[1]},”color”:{“all”:[“#cccccc”]},”styleHover”:{},”sizeHover”:{},”colorHover”:{},”custom”:{},”customEnabled”:{}}

Result

We opened the page in the editor. The block editor received “values”:[] and all other empty keys as [], although the database contains {}. The reason: WordPress 7.x runs the Block Hooks API inside WP_REST_Posts_Controller (insert_hooked_blocks_into_rest_response on load, update_ignored_hooked_blocks_postmeta on save). This re-serializes the content in PHP, and PHP turns every empty object {} into []. WooCommerce registers hooked blocks, so this happens on practically every WooCommerce site.

We changed the border width from 1 to 2. The border attribute became {“borderRadius”:{“locked”:true},”style”:{…},”size”:{“all”:[2]},”color”:{…}}, so clear_null_values() had removed borderRadius.values and all empty keys, because 0 != [] is false.

We changed the border radius to 8. Console:TypeError: Cannot read properties of undefined (reading ‘topLeft’)at gspbLibrary.js?ver=8ba47dfb99773cce8e58:1:727743The block then shows “This block has encountered an error and cannot be previewed.”

Control test: with the same page and the Block Hooks disabled for pages (filter rest_block_hooks_post_types), the editor receives {} and exactly the same two steps work without any error.

Steps to reproduce on your side

WordPress 7.x + WooCommerce + GreenShift 13.2.0.

New page, add a Container block, set a border (e.g. 1px solid), save.

Reload the editor.

Change the border width, then change the border radius. The block crashes.

Suggested fix

Use optional chaining for the bracket access: o?.borderRadius?.values?.[e]

Normalise empty arrays to objects when the border attribute is read

Do not delete empty arrays in clear_null_values() through the 0 != value check

We currently work around it by removing page, post and wp_block from rest_block_hooks_post_types. A fix in the control would help all WooCommerce users.

Best regardsManfredcobizz GmbH, Wuppertal
GreenshiftWP

Admin

Sep 26, 2026 at 10:08 pm

I was able to reproduce bug. but fix should be another. Thank you, we will add fix

Border control crashes block when attributes contain empty arrays (GreenShift 13.2.0)

Responses