Add HTTP API endpoint for canvasData.v0 to support useSiteData() in Workbench
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3585327. -->
Reported by: [mglaman](https://www.drupal.org/user/2416470)
Related to !1038
>>>
<h3 id="overview">Overview</h3>
<p><code>getSiteData()</code> and <code>getPageData()</code> in the <code>drupal-canvas</code> package read synchronously from <code>window.drupalSettings?.canvasData?.v0</code> — data that Drupal injects only when rendering a full page with the relevant <code>canvas/canvasData.v0.*</code> asset libraries attached. No HTTP endpoint exposes this data. Workbench runs as a local Vite dev server with no Drupal page render, so it cannot call these functions to get live site or page data.</p>
<h3 id="proposed-resolution">Proposed resolution</h3>
<p><strong>PHP: new API route and controller</strong></p>
<p>Add a route <code>canvas.api.v0.site_data</code> at <code>GET /canvas/api/v0/site-data</code> in <code>canvas.routing.yml</code>, following the same authentication and access pattern as other read-only Canvas API routes:</p>
<pre><pre>canvas.api.site_data:<br> path: '/canvas/api/v0/site-data'<br> defaults:<br> _controller: 'Drupal\canvas\Controller\SiteDataController'<br> requirements:<br> _canvas_authentication_required: TRUE<br> _canvas_ui_access: 'TRUE'<br> _format: 'json'<br> methods: [GET]<br> options:<br> canvas_external_api: true</pre></pre><p>Add <code>\Drupal\canvas\Controller\SiteDataController</code>. It calls all relevant <code>CodeComponentDataProvider</code> methods — the same methods already wired in <code>ComponentSourceHooks::jsSettingsAlter()</code> via <code>ASSET_LIBRARY_METHOD_MAPPING</code> — and returns a <code>JsonResponse</code> with the merged <code>canvasData.v0</code> shape:</p>
<pre><pre>{<br> "baseUrl": "https://example.com",<br> "branding": { "homeUrl": "/", "siteName": "My Site", "siteSlogan": "" },<br> "themeAssets": {<br> "logo": { "url": "/themes/custom/my_theme/logo.svg" },<br> "favicon": { "url": "/favicon.ico", "mimeType": "image/x-icon" }<br> }<br>}</pre></pre><p><strong>PHP: OAuth authentication coverage</strong></p>
<p>Add <code>canvas.api.site_data</code> to the <code>$named_routes</code> array in <code>\Drupal\canvas_oauth\Authentication\Provider\CanvasOauthAuthenticationProvider::applies()</code>. The provider explicitly enumerates route names; it will not pick up the new route automatically. This ensures OAuth2 Bearer token requests from the CLI and Workbench are authenticated the same way as artifact upload and push lifecycle routes.</p>
<p><strong>TypeScript: Workbench bootstrap via <code>@drupal-canvas/vite-plugin</code></strong></p>
<p><code>@drupal-canvas/vite-plugin</code> already uses <code>transformIndexHtml</code> to build a <code>window.drupalSettings = { canvasData: { v0: ... } }</code> script tag and inject it into the page at bootstrap. It currently populates only <code>baseUrl</code> and <code>jsonapiSettings</code> from local environment config.</p>
<p>Extend the plugin so that when a Drupal site URL is available, it fetches <code>/canvas/api/v0/canvas-data</code> at bootstrap time (using the CLI's OAuth-authenticated HTTP client) and merges the response into the <code>canvasData.v0</code> object before the script tag is emitted. Because Workbench uses <code>@drupal-canvas/vite-plugin</code> via <code>vite-compat</code>, this means <code>window.drupalSettings.canvasData.v0</code> is fully populated before any component code runs — and the existing <code>getSiteData()</code> and <code>getPageData()</code> functions work with no changes.</p>
<p>The endpoint response includes <code>jsonapiSettings</code> (from <code>CodeComponentDataProvider::getCanvasDataJsonApiSettingsV0()</code>), so the <code>jsonapiPrefix</code> option and <code>CANVAS_JSONAPI_PREFIX</code> env var in the vite-plugin become unnecessary when the HTTP fetch is used — Workbench no longer needs that value configured separately.</p>
<h3 id="ui-changes">User interface changes</h3>
<p>None.</p>
issue