fix: Page data panel is never hidden in the Canvas editor

Problem/Motivation

Canvas Override sets drupalSettings.canvas.hidePageDataPanel in hook_js_settings_alter() to hide the editor's Page data panel on a Canvas Override enabled node. It never fires, so the panel is never hidden.

The guard reads the entity from route parameters:

$entity_type = $this->routeMatch->getParameter('entity_type');
if ($entity_type !== 'node') {
  return;
}

Drupal Canvas serves its editor shell through a route match that carries no entity_type / entity parameters. Verified by logging inside the hook while loading /canvas/editor/node/2 on a Canvas Override enabled node: the only routes that ever reach it are canvas.boot.empty and canvas.api.config.list, both with entity_type = NULL. The guard therefore always returns early and the setting is never written.

Second problem: even when the flag was set, nothing consumed it. The code that read hidePageDataPanel lived in Drupal Canvas's front-end sources, and Canvas ships its editor as a prebuilt bundle loaded from canvas.libraries.yml. Confirmed the shipped bundle contains no occurrence of hidePageDataPanel. So the feature depended on a Canvas patch that could never take effect through Composer, since composer install restores the shipped bundle.

Steps to reproduce

1. Install Canvas Override on Drupal 11.4.5 with Drupal Canvas 1.10.0.
2. Enable Canvas Override on a content type.
3. Open /node/{nid}/canvas for a node of that type.
4. In the browser console, evaluate drupalSettings.canvas.hidePageDataPanel — it is undefined.

Proposed resolution

Make the feature work inside Canvas Override, with no dependency on a Drupal Canvas front-end patch:

1. Resolve the node from the request path (/canvas/editor/node/{nid}) rather than from route parameters, still falling back to route parameters when Drupal does upcast them.
2. Ship the editor behaviour as this module's own library (canvas_override/editor) and attach it with hook_library_info_alter() by adding it to canvas/canvas-ui's dependencies. It then loads with the editor without patching Drupal Canvas, and survives every composer install and Canvas upgrade.
3. The behaviour hides the Page data tab ([data-testid="canvas-contextual-panel--page-data"]) and moves selection to the next available tab when that tab is active, using a MutationObserver because the editor re-renders as the user works.

Remaining tasks

• ✅ File an issue
• ✅ Identify why the flag is never set
• ✅ Confirm the shipped Canvas bundle has no consumer for the flag
• ✅ Resolve the node from the request path
• ✅ Add the canvas_override/editor library and attach it via hook_library_info_alter()
• ✅ Verify on a live site
• ➖ Testing to ensure no regression
• ➖ Automated unit testing coverage
• ➖ Automated functional testing coverage
• ➖ UX/UI designer responsibilities
• ➖ Readability
• ➖ Accessibility
• ➖ Performance
• ➖ Security
• ➖ Developer Documentation
• ➖ User Guide Documentation
• ➖ Reviewed by human
• ➖ Code review by maintainers
• ➖ Full testing and approval
• ➖ Credit contributors
• ➖ Review with the product owner
• ➖ Release notes snippet
• ✅ Release

User interface changes

• The Page data panel is now actually hidden in the per-node Canvas editor, which is what the module always intended.

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• Fixes the Page data panel not being hidden in the per-node Canvas editor, and removes the module's dependency on a Drupal Canvas front-end patch for it.

AI-Generated: Yes. AI (Claude Code) assisted with diagnosis and implementation for this issue; the human contributor (Rajab Natshah) is responsible for the logic, security and licensing.