Summary
Opening a post/page in Breakdance when that post is rendered by a Breakdance Template (via Template assignment/conditions) fails to show the expected "This post can't be edited directly" redirect modal. Instead, the builder loads with no Canvas ("No canvas element" console error), unstyled/unrendered content, no Structure pane, and the Add (+) button in the Components pane spins indefinitely with no result.
This is not limited to a specific post type, hierarchical CPTs, or parent/child post relationships. It reproduces across all public post types on the affected sites.
Steps to reproduce
- Create a CPT
- Assign a Single "post_type" template
- Enable direct editing in Breakdance > Settings > Post Type for the created post type
- Create a single CPT and publish
- Edit in Breakdance
- Instead of seeing the modal like you would in Posts eg. "This Post can't be edited directly.", you are presented with unstyled content, Add pane spins indefinitely and
No canvas element error in the console.
Expected behaviour
When editing a post directly in Breakdance where that post is currently rendered via an assigned/matched Breakdance Template (and the template does not contain a Template Content Area element), Breakdance should present the "This post can't be edited directly" modal with the option to Edit Template or Go back.
Actual behaviour
The modal does not appear. The builder attempts to load the Canvas and fails silently in the UI (browser console shows "No canvas element"). The result is:
- No Canvas / unstyled content rendered in the builder
- No Structure pane
- Add (+) in the Components pane spins indefinitely and never resolves
Environment
|
|
| WordPress Core |
7.0.2 |
| Breakdance |
2.8.0, 2.8.1, 3.0 Beta 2 (all affected) |
| Breakdance |
<=2.7.2 (confirmed working, not affected) |
| PHP |
8.2 |
| Hosting |
WP Engine |
| Tested environments |
Production, Staging, Development (3 separate WP Engine environments, same result on all three), Tested in breakdance.com/try instawp site, same behaviour. |
Steps to reproduce
- On a site with one or more Breakdance Templates assigned via Template conditions (post type, taxonomy, or custom condition) to a public post type.
- Ensure a given post does not have a Template Content Area element in the applicable Template.
- Open that post directly in Breakdance ("Edit with Breakdance" from the post list or block editor).
- Observe that the "This post can't be edited directly" modal does not appear.
- Observe the builder loads with no Canvas, no Structure pane, and a spinning Add (+) button in Components.
- Downgrade Breakdance to 2.7.2 on the same post/environment and repeat step 3. The modal displays correctly and the builder does not attempt to load the Canvas.
Bisection
This was isolated by version downgrade/upgrade on the same site and same post, with no other changes. 2.7.2 works correctly. 2.8.0, 2.8.1, and 3.0 Beta 2 all reproduce the issue.
Supporting investigation
Comparing the 2.7.2 and 2.8.1 plugin source, doesRuleApply() in themeless/request.php now passes an additional 'templating' context argument to condition callbacks that did not exist in 2.7.2:
// 2.8.1
call_user_func(
$maybeCondition['callback'],
$rule['operand'] ?? '',
getCleanValueFromRuleValue($rule['value'] ?? null),
$rule['ruleDynamic'] ?? '',
'templating'
);
Correspondingly, themeless/rules/conditions/singular.php was updated to consume this new $context argument and call is_singular() conditionally when $context === 'templating'. This appears to be new template-evaluation-context handling introduced in 2.8.0 that behaves differently to 2.7.2 when a Template's assignment conditions are evaluated for the post currently open in the builder. I haven't been able to trace this all the way through to the specific function responsible for the modal/editability check in the builder's document-load request, so I can't say with certainty this is the root cause, but it is a confirmed, version-gated behavioural change in the area of the code this bug sits in, and is offered here as a starting point for investigation.
Impact
Editors on affected post types cannot open Breakdance on any post currently governed by a Template, since the intended safety redirect (the modal) doesn't fire and they're instead dropped into a non-functional builder state.
Summary
Opening a post/page in Breakdance when that post is rendered by a Breakdance Template (via Template assignment/conditions) fails to show the expected "This post can't be edited directly" redirect modal. Instead, the builder loads with no Canvas ("No canvas element" console error), unstyled/unrendered content, no Structure pane, and the Add (+) button in the Components pane spins indefinitely with no result.
This is not limited to a specific post type, hierarchical CPTs, or parent/child post relationships. It reproduces across all public post types on the affected sites.
Steps to reproduce
No canvas elementerror in the console.Expected behaviour
When editing a post directly in Breakdance where that post is currently rendered via an assigned/matched Breakdance Template (and the template does not contain a Template Content Area element), Breakdance should present the "This post can't be edited directly" modal with the option to Edit Template or Go back.
Actual behaviour
The modal does not appear. The builder attempts to load the Canvas and fails silently in the UI (browser console shows "No canvas element"). The result is:
Environment
Steps to reproduce
Bisection
This was isolated by version downgrade/upgrade on the same site and same post, with no other changes. 2.7.2 works correctly. 2.8.0, 2.8.1, and 3.0 Beta 2 all reproduce the issue.
Supporting investigation
Comparing the 2.7.2 and 2.8.1 plugin source,
doesRuleApply()inthemeless/request.phpnow passes an additional'templating'context argument to condition callbacks that did not exist in 2.7.2:Correspondingly,
themeless/rules/conditions/singular.phpwas updated to consume this new$contextargument and callis_singular()conditionally when$context === 'templating'. This appears to be new template-evaluation-context handling introduced in 2.8.0 that behaves differently to 2.7.2 when a Template's assignment conditions are evaluated for the post currently open in the builder. I haven't been able to trace this all the way through to the specific function responsible for the modal/editability check in the builder's document-load request, so I can't say with certainty this is the root cause, but it is a confirmed, version-gated behavioural change in the area of the code this bug sits in, and is offered here as a starting point for investigation.Impact
Editors on affected post types cannot open Breakdance on any post currently governed by a Template, since the intended safety redirect (the modal) doesn't fire and they're instead dropped into a non-functional builder state.