Drupal Canvas

#3583897: Page preview should not scroll to top in Workbench when HMR reloads page

Fri, 10 Apr 2026 14:17:31 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 61c3322
Discussion: #3583897 · 1 contributor · 8 comments
Followers: 2

Summary

When HMR triggers a re-render in the Canvas Workbench, the page preview iframe no longer resets its scroll position to the top. Scroll still resets when navigating to a different page or component. This is purely a Workbench developer-experience improvement with no effect on site visitors.

Impact

No upgrade or configuration changes required.

Technical details

The preview iframe in Canvas Workbench stays mounted as the shell switches between pages and components. Previously, every re-render caused window.scrollTo(0, 0), which meant HMR updates (same target, new markup) also jumped the user back to the top.

The fix introduces a useRef (lastPreviewTargetKeyRef) in PreviewFrameApp and a useLayoutEffect that compares a stable key derived from the render type and render ID. The helper getPreviewTargetKey() in preview-target-key.ts builds this key as "${renderType}:${renderId}". When the key changes (user navigated to a different preview target), scroll resets to top. When the key is the same (HMR update for the same target), the effect skips the scroll call, preserving the user's position.

New tests in PreviewFrameApp.test.tsx cover both paths: scroll-to-top on target change and scroll preservation on same-target re-render. The jsdom devDependency was added to the workbench package to support the vitest jsdom environment these tests require. The package-lock.json diff reflects this addition plus recalculated peer-dependency flags.

Contribution

Timeline

Opened: April 9, 2026
First commit: April 9, 2026
Last commit: April 10, 2026 (1 day and 2 commits later)

Key contributors

lauriii (Acquia)
balintbrews (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3576521: defineComponentCatalog function from drupal-canvas package doesn't resolve schema references for props

Thu, 09 Apr 2026 20:29:15 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 068c093
Discussion: #3576521 · 2 contributors · 7 comments
Followers: 3

Summary

The defineComponentCatalog function in the drupal-canvas package failed when a component's props contained Canvas-specific $ref URIs (e.g. json-schema-definitions://canvas.module/image). Zod's fromJSONSchema could not resolve these custom URIs, causing an error when building the catalog. This is now fixed so components using schema references in their props work correctly in the catalog.

Impact

No upgrade or configuration changes required.

Technical details

Canvas component metadata can reference shared type definitions via custom $ref URIs like json-schema-definitions://canvas.module/image. The defineComponentCatalog function (added in #3573867) passes each component's props JSON schema through Zod's fromJSONSchema, which only understands standard local JSON Pointer refs (#/$defs/...), not Canvas-specific URIs. Any component using these references would fail.

The fix adds a rewriteCanvasRefs function in json-render-utils.tsx that recursively walks schema objects and rewrites $ref values starting with json-schema-definitions://canvas.module/ to local #/$defs/ pointers. The project's root schema.json contains $defs with shared type definitions (image, video, heading-element, etc.). These definitions are imported, themselves rewritten (since they can contain nested $ref URIs, e.g. image references image-uri), and attached to each component's JSON schema as $defs in metadataToCatalogEntry. This gives fromJSONSchema everything it needs to resolve the rewritten local pointers.

Contribution

Timeline

Opened: March 2, 2026
Committed: April 9, 2026 (1 month later)

Key contributors

wotnak (Smartbees)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3583947: Fix CLI push to not push files that are distributed with Canvas

Thu, 09 Apr 2026 19:04:05 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: e81f712
Discussion: #3583947 · 2 contributors · 9 comments
Followers: 3

Summary

The Canvas CLI push command could accidentally bundle packages and alias imports that Canvas already provides in its global import map. This change prevents those files from being included in the push output. It also adds eslint rules that warn developers when they use the old @/lib/utils, @/lib/jsonapi-utils, or @/lib/drupal-utils import paths, and offers auto-fixes to switch them to drupal-canvas.

Impact

Affects site owners.

Config change: Six new entries added to DRUPAL_CANVAS_EXTERNALS: @tailwindcss/typography, next-image-standalone, @drupal-api-client/json-api-client, @/lib/FormattedText, @/lib/utils, @/lib/jsonapi-utils, @/lib/drupal-utils.

Technical details

Canvas distributes a set of packages and aliased utility modules via its global import map. The CLI push command builds and uploads local component code, but the DRUPAL_CANVAS_EXTERNALS list in vite-build-config.ts was incomplete. Packages like @tailwindcss/typography, next-image-standalone, and @drupal-api-client/json-api-client were missing, along with four @/ alias paths (@/lib/FormattedText, @/lib/utils, @/lib/jsonapi-utils, @/lib/drupal-utils). This meant the build could bundle these into the push output even though Canvas already ships them.

The fix adds these entries to DRUPAL_CANVAS_EXTERNALS. That list is already used in two places for Vite's external option (build-vendor.ts and build-local-import.ts), so adding entries there prevents bundling. The collectImports function in import-analyzer.ts now also checks alias imports against DRUPAL_CANVAS_EXTERNALS and skips matches, so they do not end up in aliasImports or unresolvedAliasImports.

The eslint-config package's component-imports rule gains three new checks for @/lib/utils, @/lib/jsonapi-utils, and @/lib/drupal-utils. Each reports that the path is now provided by Canvas and auto-fixes the import to 'drupal-canvas'. The @/lib/drupal-utils case has a special carve-out: if the import includes sortMenu, the auto-fix is suppressed because that export was renamed to sortLinksetMenu in the drupal-canvas package. The existing @/lib/FormattedText error message was also updated to clarify that the path is provided by Canvas and cannot be used for local files.

Contribution

Timeline

Opened: April 9, 2026
Committed: April 9, 2026

Key contributors

wotnak (Smartbees)
mglaman (Acquia)

Collaboration

Comment #9 notes a release dependency: a new version of eslint-config must be released alongside the new CLI version.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582273: Prevent Workbench preview from reloading when links are clicked

Thu, 09 Apr 2026 12:32:28 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 79f0121
Discussion: #3582273 · 3 contributors · 8 comments
Followers: 4

Summary

Clicking a link inside the Workbench preview iframe no longer causes the iframe to reload and render the entire Workbench application inside itself. Instead, recognized Workbench routes (known pages and components) navigate within the app, and external or unrecognized links open in a new tab. Form submissions inside the preview are also blocked.

Impact

Affects module maintainers.

API change: New shellPath optional field on PreviewRenderRequest.payload; new PreviewShellSync message type in the preview contract.

Technical details

The Workbench preview renders components and pages inside a sandboxed iframe. When a user clicked a link in the previewed content, the iframe navigated normally, which served the Workbench shell HTML (because the dev server's SPA fallback returned index.html), nesting the entire app inside its own preview frame.

The initial proposal was to intercept all link clicks and prevent their default behavior, borrowing the approach from Canvas UI's preview mode. In comment #3, lauriii suggested that clicks should instead navigate within Workbench when the target is a recognized route, and open unrecognized or external links in a new tab. The implementation follows that direction.

Navigation resolver. A new pure function resolveWorkbenchPreviewNavigation in resolve-workbench-preview-navigation.ts decides whether a URL should produce an in-app navigate or a new-window open. It checks the URL against known page slugs, component IDs, and mock indices from the discovery result and preview manifest. Vite internals (/@, /node_modules/, /__), cross-origin URLs, and mailto:/tel: links all fall through to open.

Iframe click and form interception. PreviewFrameApp now fetches the discovery result and preview manifest on mount so it can build the navigation context. A document-level click handler (registered with capture: true) intercepts anchor clicks, resolves them through the navigation function, and either calls window.open for external links or uses react-router's navigate for internal ones. A separate handler prevents all form submissions inside the iframe.

Shell-iframe sync via postMessage. Two new sync mechanisms keep the parent shell and iframe router aligned. The parent shell now includes a shellPath field in PreviewRenderRequest messages, which the iframe's MemoryRouter uses to stay on the correct route. In the other direction, a new preview:shell-sync message type lets the iframe tell the parent shell to navigate when a user clicks an internal link in previewed content. The parent App.tsx handles this message using a locationRef pattern to avoid stale closure reads of the current location.

SPA fallback and plugin ordering. shouldServeWorkbenchIndexHtml was broadened from matching only /component and /page paths to serving index.html for any extensionless path that is not an API endpoint, Vite internal, or non-HTML file under /canvas/. To ensure this middleware runs before other plugins' middleware, the workbench plugin was moved to enforce: 'pre' and placed first in the plugins array, and its middleware is registered at the top of configureServer.

Iframe sandbox. The iframe's sandbox attribute gains allow-popups so that window.open calls from the click handler can open new tabs. The preview iframe entry point is wrapped in a MemoryRouter with initial entry /page.

Contribution

Timeline

Opened: March 30, 2026
Committed: April 9, 2026 (9 days later)

Key contributors

balintbrews (Acquia)
mayur-sose
shubham.prakash (OpenSense Labs)
lauriii (Acquia)

Collaboration

lauriii's comment #3 redirected the approach. The original plan was to simply block all link clicks in the preview (matching what Canvas UI does). lauriii suggested instead navigating within Workbench for recognized routes and opening unrecognized or external links in a new tab, which is what the final implementation does.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580221: Add CLI push/pull for fonts

Wed, 08 Apr 2026 19:04:32 +0000

Project: Drupal Canvas
Type: Normal feature request
Version: 1.x-dev
Status: Fixed
Diff: 040e79d
Discussion: #3580221 · 2 contributors · 8 comments
Followers: 3

Summary

The Canvas CLI can now push and pull Brand Kit fonts, allowing font configuration to be version-controlled and deployed like other Canvas assets. When a canvas.brand-kit.json file is present in the project root, canvas push resolves each font family (via unifont for provider-based fonts, or a local file path), uploads the font files to the Drupal site, and syncs the full font list to the global Brand Kit. canvas pull fetches fonts from the global Brand Kit, downloads the files into a local fonts/ directory, and writes local src entries back to canvas.brand-kit.json. Font sync is entirely opt-in: the file must be present for any font operations to run. The administer brand kit permission is no longer hidden from the Drupal permissions page when the canvas_dev_mode module is not installed.

Impact

Affects module maintainers and site owners.

Config change: New optional canvas.brand-kit.json file in the project root for font configuration; default CLI OAuth scope now includes canvas:brand_kit
Permission change: administer brand kit permission is no longer hidden from the Drupal permissions page when canvas_dev_mode is not installed
New API: New createFontsPullTask export in pull.ts and pushFonts / buildFontPushPlannedResults exports in font-push.ts; new TypeScript interfaces FontsConfig, FontFamilyEntry, FontDefaults, FontAxisDefaults, BrandKitConfigFile exported from config.ts

Technical details

The global Brand Kit entity stores font configuration site-wide. Previously it was editor-only; the CLI had no way to version or deploy fonts. This change adds font sync to both push and pull as an optional step gated on the presence of canvas.brand-kit.json in the project root.

Config (packages/cli/src/config.ts): The Config interface gains a fonts?: FontsConfig field. At startup, loadFontsFromBrandKitFile() reads and parses canvas.brand-kit.json (if present) and stores the fonts block. New TypeScript interfaces describe the full font config shape: FontsConfig, FontFamilyEntry (a union of LocalFontFamilyEntry with a src path and ProviderFontFamilyEntry with an optional provider), FontDefaults, FontProviderOptions, and FontAxisDefaults. The BRAND_KIT_CONFIG_FILENAME and BRAND_KIT_GLOBAL_ID constants are exported. The default OAuth scope gains canvas:brand_kit (was canvas:js_component canvas:asset_library; now canvas:js_component canvas:asset_library canvas:brand_kit).

Font push (packages/cli/src/lib/fonts/font-push.ts): pushFonts() validates the config first (via font-validate.ts), then fetches the current Brand Kit to diff against remote. For provider-based families it calls createFontResolver() (a unifont wrapper in font-resolver.ts) and then downloadResolvedFaces() to fetch font files to temp paths. For local src entries it reads the file from disk. Variable font axes are extracted from the font binary using opentype.js (decompressing woff2 with woff2-encoder first) via font-metadata.ts. Axis tags get human-readable display names (e.g. wght → "Weight") for the Brand Kit UI. axisDefaults overrides are clamped to each axis min/max. Only variants not already present on the remote Brand Kit are uploaded; push replaces the remote font set in full so fonts not in config are deleted. All outcomes (create/update/delete/unchanged) are reported. An empty families array clears all fonts on the Brand Kit.

Font pull (packages/cli/src/lib/fonts/font-pull.ts): pullFonts() fetches the Brand Kit via api.getBrandKit(), skips variants already represented in canvas.brand-kit.json (matched by a normalized family\0weight\0style key), and for each new variant downloads the file via api.downloadFile() into a fonts/ directory with slugified filenames. Variable font weight ranges are reconstructed from stored axes (wght min/max). updateBrandKitConfig() merges new LocalFontFamilyEntry objects into the existing file, preserving other top-level keys. createFontsPullTask() in pull.ts wraps this as a PullTask that runs alongside components and global CSS.

OAuth (CanvasOauthAuthenticationProvider): BrandKit::ENTITY_TYPE_ID is added to the list of protected config entity types so the existing config entity REST endpoints (canvas.api.config.get, canvas.api.config.patch, etc.) accept OAuth tokens for Brand Kit operations.

canvas.module: canvas_form_alter() is removed. This hook was hiding the administer brand kit permission entry from the Drupal permissions UI when canvas_dev_mode was not installed. Its removal means the permission is always visible.

New npm dependencies added to the CLI: unifont ^0.7.4, opentype.js ^1.3.4, woff2-encoder ^2.0.0.

Upgrade

If you have CANVAS_SCOPE set explicitly in .env or your environment, add canvas:brand_kit to enable font push/pull:

CANVAS_SCOPE="canvas:js_component canvas:asset_library canvas:brand_kit"

If CANVAS_SCOPE is unset, the new default already includes canvas:brand_kit.

To opt in to font sync, create canvas.brand-kit.json in your project root:

{
  "fonts": {
    "families": [
      {
        "name": "Inter",
        "provider": "google",
        "weights": ["400", "700"],
        "styles": ["normal", "italic"]
      },
      {
        "name": "My Font",
        "src": "fonts/MyFont-Regular.woff2",
        "weights": ["400"],
        "styles": ["normal"]
      }
    ]
  }
}

No changes are required if you do not create canvas.brand-kit.json; the push and pull commands continue to work as before.

Contribution

Timeline

Opened: March 19, 2026
Committed: April 8, 2026 (20 days later)

Key contributors

lauriii (Acquia)
hooroomoo (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3583386: Code Component: Prop Type Change Fails to Reset Configuration

Wed, 08 Apr 2026 12:49:31 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: e58c60d
Discussion: #3583386 · 5 contributors · 12 comments
Followers: 6

Summary

When using the Code Component editor, changing a prop's type (for example, from "Formatted Text" to "Link" or "Date and time") did not clear the previous type's configuration fields. The contentMediaType and x-formatting-context fields set by the "Formatted Text" type were carried over into the new type's saved configuration. On page reload, the prop derivation logic would see those stale fields and incorrectly re-classify the prop as formattedText, causing broken or inconsistent front-end rendering.

Impact

No upgrade or configuration changes required.

Technical details

Prop types in the Code Component editor are "derived" -- the system inspects serialized JSON Schema fields (format, contentMediaType, x-formatting-context, enum, etc.) to determine which derivedType a prop belongs to. The formattedText type is identified by the presence of contentMediaType: 'text/html' and 'x-formatting-context': 'block'.

When a user switched away from formattedText, the onValueChange handler in Props.tsx dispatched an updateProp action that reset derivedType, $ref, and format, but did not clear contentMediaType or 'x-formatting-context'. Those fields persisted in the Redux store and were serialized to config. On the next page load, deserializeProps in utils.ts re-derived the prop type from the saved fields and would classify it as formattedText again because those stale fields were still present and took precedence over format or enum.

The fix has two parts:

Prevention in Props.tsx: The updateProp dispatch when switching types now explicitly sets contentMediaType: undefined and 'x-formatting-context': undefined. A comment instructs future contributors to add any new type-specific fields here when introducing new prop types.
Backwards compatibility in deserializeProps (utils.ts): A new guard detects already-corrupted saved configs -- specifically, props that derive as formattedText but also carry a format value or non-empty enum (which belong to other types). When detected, contentMediaType and 'x-formatting-context' are deleted from the deserialized prop (and from items for multi-value props), and the correct derivedType is re-derived by running the derivation logic without those stale fields. This repairs existing configs without requiring a data migration.

Tests cover all target types (Date and time, Link, Text, Integer, Number, Boolean, Image, Video, List: text, List: integer) for the prevention side, and date, date-time, link (uri and uri-reference), list:text, and multi-value array props for the backwards-compatibility repair side.

Contribution

Timeline

Opened: April 7, 2026
Committed: April 8, 2026 (1 day later)

Key contributors

chandu7929 (Acquia)
isholgueras (Acquia)
narendrar (Acquia)

Collaboration

The backwards-compatibility repair in deserializeProps was not in the original bug report. The issue author described the forward-looking fix (clear fields on type switch), but the committed solution also added the deserializeProps guard to repair already-saved corrupted configs, which was a meaningful design decision made during implementation.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3583230: Code-component editor: NULL value error when reordering multivalue prop with empty slots in limited mode

Wed, 08 Apr 2026 12:30:37 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 91371bd
Discussion: #3583230 · 4 contributors · 15 comments
Followers: 5

Summary

In the code-component editor, reordering a multivalue prop in "limited" mode (with some empty slots) after reloading from the backend caused a NULL value error on save. The backend saves only the filled values (e.g., 3 items for a limit of 5). When reloaded, the UI renders all 5 slots but the underlying array only has 3 items. Accessing the empty slots returned undefined, which became null during JSON serialization, and the backend rejected null for string fields. This bug only appeared after a component was saved and reloaded, not on the first save.

Impact

No upgrade or configuration changes required.

Technical details

The root cause was a mismatch between the sortable list item count and the actual display array in limited mode. In FormPropTypeArray.tsx and FormPropTypeLink.tsx, the PropValuesSortableList items were generated using Array.from({ length: limitedCount }) (5 indices), but the displayArray backing those slots was not padded and only contained the filled values from the backend (3 items). When the drag handler called arrayMove(displayArray, ...), it operated on the unpadded 3-item array, so indices 3 and 4 resolved to undefined. These undefined values were then serialized to null by JSON.stringify.

The fix introduces a shared createDisplayArray function in ui/src/features/code-editor/utils/arrayPropUtils.ts. In limited mode, it pads the array to exactly limitedCount items using exampleArray[i] ?? '', replacing missing entries with empty strings instead of leaving them undefined. In unlimited mode, it keeps the existing behavior of falling back to [''] when the array is empty. All three affected form components (FormPropTypeArray, FormPropTypeDate, FormPropTypeLink) now call this shared function via useMemo. The PropValuesSortableList items are also simplified to always derive from displayArray.map((_, index) => index) since displayArray is now guaranteed to have the correct length. FormPropTypeDate previously used exampleArray[i] || '' (logical OR), which would have silently replaced 0 with ''; the new ?? '' (nullish coalescing) is more correct.

Contribution

Timeline

Opened: April 6, 2026
Committed: April 8, 2026 (2 days later)

Key contributors

kunal.sachdev (Acquia)
narendrar (Acquia)
isholgueras (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582804: Add endpoint to retrieve a canvas_page by UUID

Tue, 07 Apr 2026 21:24:25 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 52a5f25
Discussion: #3582804 · 2 contributors · 7 comments
Followers: 4

Summary

A new GET /canvas/api/v0/content/canvas_page/by-uuid/{uuid} endpoint lets callers retrieve a canvas_page by its UUID instead of its integer entity ID. It returns the same response as the existing GET /canvas/api/v0/content/canvas_page/{id} endpoint. This is useful when the integer ID is not known but the UUID is.

Impact

Affects module maintainers.

New API: New GET /canvas/api/v0/content/canvas_page/by-uuid/{uuid} endpoint retrieves a canvas_page by UUID, returning the same response as the existing integer-ID endpoint.

Technical details

The existing canvas.api.content.get route requires an integer entity ID in the path. The new canvas.api.content.get.by_uuid route at /canvas/api/v0/content/canvas_page/by-uuid/{canvas_page} reuses the same controller method, ApiContentControllers::get.

UUID-to-entity resolution is handled by a new CanvasEntityByUuidConverter param converter (src/Routing/CanvasEntityByUuidConverter.php), registered as a paramconverter service. It applies to any route parameter whose type starts with the canvas_entity_by_uuid: prefix, then calls EntityRepositoryInterface::loadEntityByUuid() to load the entity. If the entity is not found, it throws ParamNotConvertedException, resulting in a 404 response.

The route is added to the $page_route_names list in CanvasOauthAuthenticationProvider so that OAuth token authentication applies to it. OpenAPI documentation is also updated with a new entityUuid path parameter component and a path entry for the new endpoint.

Contribution

Timeline

Opened: April 2, 2026
Committed: April 7, 2026 (5 days later)

Key contributors

attilatilman (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3502691: Introduce pagination for HTTP API to get list of content(pages).

Tue, 07 Apr 2026 16:53:16 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 8b4a449
Discussion: #3502691 · 6 contributors · 22 comments
Followers: 9

Summary

The HTTP API endpoint for listing content pages (/canvas/api/v0/content/{entity_type}) now supports offset-based pagination. Previously the endpoint returned a flat object keyed by entity ID with a hard cap of 50 items and no way to page beyond that. It now accepts page[offset] and page[limit] query parameters (limit capped at 50), and the response wraps results in a data array with meta.count (total items) and JSON:API-style links for self/first/prev/next/last. The CLI listPages() command automatically follows links.next until all pages are fetched, replacing the earlier 50-page warning that told users some pages may have been missed.

Impact

Affects module maintainers.

API change: GET /canvas/api/v0/content/{entity_type} response changed from a flat keyed object to {data: [...], meta: {count}, links: {...}}; page[offset] and page[limit] query parameters added; search responses return data only with no meta/links.
New API: New OffsetPage value object (Drupal\canvas\Resource\OffsetPage) for parsing page[offset]/page[limit] query parameters.

Technical details

The previous endpoint returned a flat JSON object keyed by entity ID (e.g. {"1": {...}, "2": {...}}), always with a range of 0–50. There was no way to page past the first 50 results, and the CLI emitted a warning when it hit that cap.

OffsetPage value object (src/Resource/OffsetPage.php): A new final class that parses page[offset] and page[limit] from the request. MAX_SIZE = 50 clamps the limit; negative offsets are floored to 0.

ApiContentControllers::list(): When no search parameter is present, OffsetPage::createFromRequest() is called to read offset/limit. A separate count query ($storage->getQuery()->count()) runs first to populate meta.count. The main query then uses ->range($offset, $limit). Results are placed in a data array, and buildPaginationLinks() produces the link set. The url.query_args:page cache context is added only for non-search requests.

When search is present, pagination is intentionally skipped. This is because search combines stored entity query results with auto-save matches in memory, making offset-based pagination against only the stored query impractical. Search responses return {data: [...]} with no meta or links.

buildPaginationLinks(): A private method that constructs JSON:API-style link objects. self is always present; first/prev appear when $offset > 0; next/last appear when $offset + $limit < $total. last_offset is computed as floor(($total - 1) / $limit) * $limit.

executeQueryInRenderContext(): Return type widened from array to array|int to accommodate the count query.

CLI (packages/cli/src/services/api.ts): listPages() now loops, following body.links?.next?.href until null. The 50-item warnings in pull.ts and push.ts are removed.

UI (ui/src/services/content.ts): ContentListResponse interface updated from {[key: string]: ContentStub} to {data: ContentStub[], meta?: {count: number}, links?: ...}. transformResponse now returns response.data instead of Object.values(response).

docs/config-management.md: The bullet "Canvas's HTTP API does not need pagination support" is narrowed to "Canvas's config entity HTTP API does not need pagination support" to reflect that content entity APIs do support pagination.

Upgrade

The GET /canvas/api/v0/content/{entity_type} response shape changed.

Before:

{
  "1": { "id": 1, "title": "Home", ... },
  "2": { "id": 2, "title": "About", ... }
}

After:

{
  "data": [
    { "id": 1, "title": "Home", ... },
    { "id": 2, "title": "About", ... }
  ],
  "meta": { "count": 42 },
  "links": {
    "self": { "href": "/canvas/api/v0/content/canvas_page?page[offset]=0&page[limit]=50" },
    "next": { "href": "/canvas/api/v0/content/canvas_page?page[offset]=50&page[limit]=50" },
    "last": { "href": "/canvas/api/v0/content/canvas_page?page[offset]=0&page[limit]=50" }
  }
}

Search responses omit meta and links:

{
  "data": [
    { "id": 1, "title": "Home", ... }
  ]
}

Any code that treated the response as a keyed object must be updated to read from response.data. To page through all results, follow links.next.href until it is absent.

Contribution

Timeline

Opened: January 28, 2025
Committed: April 7, 2026 (1 year later)

Key contributors

amangrover90 (Acquia)
mglaman (Acquia)
catch (Third and Grove)
wim leers (Acquia)
penyaskito (Acquia)
lauriii (Acquia)

Collaboration

wim leers closed the issue in comment #7, arguing that search (#3518292) made general pagination unnecessary and that it was better to search for content rather than page through all of it. The issue was reopened when #3575144 (Add unstable v0 external Canvas Page API endpoints) surfaced the need again. The doc comment in config-management.md that had been used to justify closing it ("does not need pagination support") was narrowed in this very diff to apply only to config entities.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3563780: Push command should respect dependency order between components

Tue, 07 Apr 2026 13:48:49 +0000

Project: Drupal Canvas
Type: Major bug report
Version: 1.x-dev
Status: Fixed
Diff: f479c68
Discussion: #3563780 · 4 contributors · 13 comments
Followers: 7

Summary

When pushing multiple JavaScript components via the CLI, the push command sent components to the server in an arbitrary order. If a component that imports another component was pushed before its dependency existed on the server, the backend rejected it with a validation error. The push command now sorts components by dependency order before uploading, so dependencies are always created first and deleted last.

Impact

No upgrade or configuration changes required.

Technical details

The Canvas CLI push command builds and uploads JavaScriptComponent config entities to the Drupal backend. The backend's JavaScriptComponent::addJavaScriptComponentsDependencies() validates that every imported component already exists when a component is created or updated. If components are pushed in an order where a component that imports another arrives before its dependency, the server returns an error like [importedJsComponents.0] The JavaScript component with the machine name 'foo_button' does not exist.

The fix has two parts. First, a new sortByDependencies utility (packages/cli/src/utils/dependency-sort.ts) implements Kahn's topological sort algorithm with wave/level tracking. It returns an array of waves, where each wave contains items that share the same dependency depth. Items within a wave can be processed in parallel; waves must be processed sequentially.

Second, uploadComponents in prepare-push.ts was refactored. It now separates tasks into creates, updates, and deletes before processing:

Creates: sorted into dependency-first waves (leaf components first, composites last), with each wave processed in parallel via the existing processInPool helper, waves run sequentially.
Updates: processed in parallel as before, because the components already exist on the server and order does not matter.
Deletes: also sorted by sortByDependencies, then the wave array is reversed. This ensures dependents are deleted before their dependencies, preventing a "component still referenced" error from the backend. For components being deleted that have no local file, the code parses sourceCodeJs from the server response using Babel's parse and getImportsFromAst to extract the dependency list.

The importedJsComponents field was added to both the ComponentUploadTask union type and the PreparedComponent interface to carry dependency information through the pipeline.

Circular dependencies are not detected; they are silently grouped into a final wave. Follow-up issue #3583474 tracks adding explicit circular dependency validation to the push command.

The UI is not affected by this bug. When a component is first created through the Canvas UI, a JavaScriptComponent entity is created immediately (empty), so any component that can be referenced via @import in the UI already exists on the server.

Contribution

Timeline

Opened: December 17, 2025
Committed: April 7, 2026 (3 months later)

Key contributors

hooroomoo
wotnak (Smartbees)

Collaboration

A passing comment from penyaskito asked whether the Canvas UI's auto-save publishing had the same ordering problem. effulgentsia and hooroomoo explained that it does not: the UI creates the config entity as soon as a component is first added, so any component that can be typed into an @import statement already exists on the server. This confirmed the bug was CLI-only and scoped the fix accordingly.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3581622: Create PredictableImageStyleItokTestTrait

Tue, 07 Apr 2026 02:30:24 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 19c552c
Discussion: #3581622 · 2 contributors · 13 comments
Followers: 3

Summary

This is a test-only cleanup with no user-facing effect. A block of code that fixed the private key and hash salt to produce predictable image style itok values was duplicated in at least five kernel test files. That block is now consolidated into a new PredictableImageStyleItokTestTrait in tests/src/Kernel/Traits/. Because the new shared hash salt value is slightly different from the old per-file value, the hard-coded itok strings in several test assertions were updated.

Impact

No upgrade or configuration changes required.

Technical details

Image style URLs in Drupal include an itok query parameter derived from a hash of the private key and hash salt. Kernel tests that assert on those URLs need a fixed, predictable itok. The pattern used ReflectionClass to override the Settings singleton and set system.private_key state to known values.

This pattern was copy-pasted into five kernel test classes and base classes: JsonapiSupportTest, ParametrizedImageStyleTest, GeneratedFieldExplicitInputUxComponentSourceBaseTestBase, PropSourceTestBase, and CanvasTwigExtensionFiltersTest. The issue asked to consolidate them into a single trait.

The new PredictableImageStyleItokTestTrait (at tests/src/Kernel/Traits/PredictableImageStyleItokTestTrait.php) exposes one method, setupPredictableItok(). It sets the system.private_key state to 'dynamic_image_style_private_key' and replaces the Settings singleton with a new instance whose hash_salt is 'dynamic_image_style_hash_salt_large_enough_for_simple_oauth'. That value is slightly longer than the previous per-file value ('dynamic_image_style_hash_salt'), which changed the resulting itok tokens and required updating the expected strings in several test data sets.

Contribution

Timeline

Opened: March 26, 2026
Committed: April 7, 2026 (11 days later)

Key contributors

penyaskito (Acquia)
sapnil_biswas

Collaboration

sapnil_biswas's initial patch included unrelated cypress/playwright changes. penyaskito asked for those to be reverted before the patch was accepted.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582772: Video multivalue props throw "Cannot read properties of undefined (reading 'endsWith')" error when switching to Limited mode

Mon, 06 Apr 2026 12:45:46 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 7de8238
Discussion: #3582772 · 4 contributors · 14 comments
Followers: 5

Summary

This fixes a crash in the Canvas code component editor when switching video props with "Allow multiple values" enabled to "Limited" mode. The editor tried to initialize the video array with empty strings, but video props expect objects with a src property. When serialization attempted to process these strings, it threw "Cannot read properties of undefined (reading 'endsWith')". The fix ensures video and image props are initialized with empty arrays or existing valid objects instead of empty strings, and adds defensive filtering during serialization to skip invalid items.

Impact

No upgrade or configuration changes required.

Technical details

The issue was a regression from #3581869. When a multivalue prop switched to limited mode, the initialization code in Props.tsx called createArrayWithCount with an empty string ('') as the default value for all prop types. This worked for primitive types like text and numbers, but video and image props expect objects with a src property.

When the serializeExample function in utils.ts tried to serialize these arrays, it called serializeVideoSrc on the empty strings. This function (or code it calls) attempts to access properties like src.endsWith(), which failed when the value was a string instead of an object.

The fix modifies Props.tsx to detect video and image props by checking their derivedType field. For these types, the limited mode initialization now preserves any existing valid objects from the current example array (using slice(0, count)) or starts with an empty array, rather than filling with empty strings. This logic was added in two places: the value mode change handler when switching to limited mode, and the createLimitedExample helper function used when adjusting the limited count.

In utils.ts, the serializeExample function adds defensive filtering for both video and image arrays. Before processing, it filters out any items that are not objects, lack a src property, or have an empty src. For videos, the filtered array is then mapped with serializeVideoSrc. This ensures serialization doesn't crash even if invalid data enters the example array.

The tests verify that serializeProps handles arrays containing empty strings without throwing errors, and that all prop types can switch to limited mode successfully.

Contribution

Timeline

Opened: April 2, 2026
Committed: April 6, 2026 (4 days later)

Key contributors

kunal.sachdev (Acquia)
narendrar (Acquia)

Collaboration

Comment #6 noted that Image props did not show the same error, questioning whether the fix should apply to them. Comment #7 confirmed Image props weren't failing but explained they need the same handling as Video props for consistency, since both are object types that could encounter the same issue.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582709: Provide an endpoint to identify that a push is starting and has stopped

Fri, 03 Apr 2026 14:34:35 +0000

Project: Drupal Canvas
Type: Normal feature request
Version: 1.x-dev
Status: Fixed
Diff: 4a242b3
Discussion: #3582709 · 1 contributor · 12 comments
Followers: 3

Summary

The Canvas CLI push command now signals the server when a push starts, completes, or fails. This allows the Canvas editor UI to display a notification showing the push is in progress, then update it to show success or failure when the push finishes. The endpoints also dispatch events that other systems can subscribe to.

Impact

Affects module maintainers.

New API: Three POST endpoints: /canvas/api/v0/push/start, /canvas/api/v0/push/complete, and /canvas/api/v0/push/fail for CLI push lifecycle signaling

Technical details

The Canvas module has an existing notification system that displays messages in the editor UI. This change adds three REST endpoints that the CLI push command calls to signal lifecycle events.

ApiPushController provides three methods that each create a notification and dispatch an event. The start() method creates a "processing" notification. The complete() method creates a "success" notification. The fail() method creates an "error" notification and accepts an optional JSON body with a message field. All three use the same notification key (cli-push), so the existing notification system's KEY_REPLACE_TYPES logic automatically replaces the processing notification when complete or fail is called.

Each method dispatches a PushEvent containing a PushStatus enum value (Started, Completed, or Failed) for extensibility.

The CLI push command in packages/cli/src/commands/push.ts calls /push/start before beginning work and either /push/complete or /push/fail at the end. The calls are best-effort: they are wrapped in try-catch blocks and failures do not affect the push itself. Error handling was refactored to throw exceptions instead of calling process.exit() directly, so the fail signal can be sent in the catch block.

The OAuth authentication provider was updated to recognize these three routes alongside the existing artifact upload route.

Contribution

Timeline

Opened: April 1, 2026
Committed: April 3, 2026 (1 day later)

Key contributors

mglaman (Acquia)
wotnak (Smartbees)
penyaskito (Acquia)
hooroomoo (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3581431: Error in link prop type when reordering list or select values

Fri, 03 Apr 2026 10:29:14 +0000

Project: Drupal Canvas
Type: Normal bug report
Version: 1.x-dev
Status: Fixed
Diff: 4bbc7c8
Discussion: #3581431 · 6 contributors · 26 comments
Followers: 8

Summary

This fixes errors that occurred when reordering multi-value link or datetime fields in Canvas. The issue was that empty rows weren't being handled correctly during transformation to the backend format. Empty rows are now converted to null placeholders to preserve their position in the list, while trailing empty rows are removed. Records with weight values are now properly sorted before transformation.

Impact

No upgrade or configuration changes required.

Technical details

The transforms in ui/src/utils/transforms.ts convert form values to backend format. The link and dateTime transformers for multi-value fields had bugs when handling empty rows and reordering.

Two new helper functions were introduced. trimTrailingNulls maps empty strings to null so the backend can render filled rows at the correct positions, then removes trailing nulls because empty rows at the end have no positional significance. normalizeMultipleRecords handles object and array inputs, sorts by _weight (other widgets) or weight (media library) fields, and keeps non-weighted values like add_more after weighted records.

The link transformer now uses both helpers and adds a hasStringUri type guard for safer type checking. The dateTime transformer uses trimTrailingNulls for multiple values. The mainProperty function was updated to use normalizeMultipleRecords.

Tests verify position preservation (null placeholders for empty rows in the middle), trailing null removal, empty array return when all rows are empty, and weight-based sorting for both simple URIs and titled links.

A second commit removed an array check at the start of normalizeMultipleRecords that prevented arrays from being processed through the weight-sorting logic, which was blocking reordering from persisting for multi-value fields.

Contribution

Timeline

Opened: March 25, 2026
First commit: April 1, 2026 (6 days later)
Last commit: April 3, 2026 (1 day and 2 commits later)

Key contributors

vipin.mittal18 (Acquia)
chandu7929 (Acquia)
narendrar (Acquia)
utkarsh_33 (Acquia)
bnjmnm (Acquia)
tim.plunkett (Acquia)

Collaboration

bnjmnm requested explanatory comments be added to the merge request to distinguish moved code from new logic before approval. A regression was discovered after the first commit where reordering wasn't persisting, fixed in a second commit by removing a condition that blocked array inputs from weight sorting.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580217: [Notifications] Toast notifications

Thu, 02 Apr 2026 22:07:06 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 521904b
Discussion: #3580217 · 2 contributors · 8 comments
Followers: 4

Summary

Canvas now shows toast notifications in the top-right corner when new notifications arrive after the page was opened. Toasts display the notification's title, message, and action links with type-specific styling (colored borders and backgrounds matching the Activity Center). They automatically dismiss after 15 seconds without marking the notification as read. Users can explicitly dismiss a toast by clicking X, which marks it as read, or click an action button to mark it as read and open the link in a new tab. Toasts only appear when dev mode is enabled.

Impact

No upgrade or configuration changes required.

Technical details

The implementation uses custom React components rather than the existing Sonner library. The existing Sonner Toaster in Toast.tsx remains for the bottom-center saving overlay only. NotificationToastManager is mounted at the app level in App.tsx, gated by drupalSettings.canvas.devMode. It subscribes to the RTK Query notifications cache (polling is configured on NotificationBell via useGetNotificationsQuery) and filters for notifications with timestamp > pageOpenedAt from Redux state. The manager maintains a visibleToasts state array and a shownIds ref set for deduplication. When new notifications arrive, it adds them to visibleToasts and starts a 15-second timer (TOAST_DURATION constant in constants.ts). Auto-dismiss removes the toast without calling useMarkNotificationsReadMutation. Explicit dismiss (X button) and action button clicks both call markRead with the notification ID and remove the toast. Action clicks also open the link via window.open(href, '_blank', 'noopener,noreferrer'). NotificationToast is a presentational component that renders the icon, title, message, action buttons, and dismiss button. It uses a data-type attribute for CSS styling hooks. Type-specific colors are defined in NotificationToast.module.css: warning uses --amber-9 border and --amber-2 background, error uses --red-9 border and --red-3 background, info and processing use --blue-9 border, and success uses --green-9 border. The processing type icon has a spin animation applied via the styles.spin class. The toast container uses position: fixed at top: var(--space-9) and right: var(--space-4) in NotificationToastManager.module.css, stacking toasts vertically with flex-direction: column. Component tests use Vitest with fake timers to verify timestamp filtering, deduplication, auto-dismiss timing, and the markRead call on explicit dismiss. Playwright E2E tests seed notifications via Drush after page load and verify toast appearance, styling, dismiss behavior, and feature flag gating.

Contribution

Timeline

Opened: March 19, 2026
Committed: April 2, 2026 (14 days later)

Key contributors

justafish (Acquia)
lauriii (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582632: Transform authored prop values for pages to server side format before push

Thu, 02 Apr 2026 19:08:10 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 9f93a89
Discussion: #3582632 · 2 contributors · 7 comments
Followers: 3

Summary

This change improves the Canvas CLI's pull/push workflow for pages. When pulling pages from the server, they are now stored locally with resolved prop values that match the format used for rendering. When pushing pages back to the server, the CLI automatically transforms these values to the backend format. This makes it easier to modify and render pages locally and work with coding agents, because the local files use the same prop value format as the json-render tooling.

Impact

No upgrade or configuration changes required.

Technical details

Canvas backend stores certain prop types differently from how they're used when rendering. Formatted text props are stored as { value, format } objects on the server but rendered as plain strings. Link props are stored as { uri, options } objects but rendered as plain URL strings.

The pull direction now stores inputs_resolved instead of raw inputs in local JSON files. The pageToAuthoredSpec function uses inputs_resolved when available. The CanvasComponentTreeNode interface was updated to include an optional inputs_resolved field.

For push, a new transformation layer was added in prop-transforms.ts. It implements a transformer pattern where each transformer has a matches method to check if it applies to a prop schema and a serialize method to convert the value. Two transformers were implemented:

The formattedTextTransformer detects props with contentMediaType: 'text/html' and wraps strings into { value, format } objects. The format is canvas_html_inline or canvas_html_block based on the x-formatting-context schema property, defaulting to block when absent.

The linkTransformer detects props with JSON Schema format of uri, uri-reference, iri, or iri-reference. It wraps strings into { uri, options: [] } objects. For uri-reference and iri-reference formats, relative paths without a scheme are prefixed with internal: as expected by Drupal's link field storage.

The preparePages function called during push now loads component metadata, calls serializeElementMapForServer to transform authored props to server format, then calls authoredSpecToComponentTree to build the component tree sent to the server.

Contribution

Timeline

Opened: April 1, 2026
Committed: April 2, 2026 (1 day later)

Key contributors

wotnak (Smartbees)

Collaboration

hooroomoo made their first commit to this issue's fork.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582776: stylelint failures on HEAD

Thu, 02 Apr 2026 11:05:35 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 1d6cd36
Discussion: #3582776 · 2 contributors · 9 comments
Followers: 3

Summary

This change fixes accumulated stylelint violations in CSS files and integrates stylelint into the automatic fix workflow. Stylelint had not been running as part of npm run fix, so formatting violations accumulated over time and were tracked in a suppressions file. The CSS formatting changes (property order, color notation, etc.) do not affect visual output. This is purely internal code quality maintenance.

Impact

No upgrade or configuration changes required.

Technical details

Stylelint was not integrated into the npm run fix command, so CSS formatting violations accumulated. A stylelint-suppressions.json file tracked 307 violations across 34 files.

The fix involved three parts. First, .stylelintrc.json was updated to handle project-specific patterns: the at-rule-no-unknown rule now ignores @theme, @custom-variant, @utility, and @slot at-rules, and selector-pseudo-class-no-unknown now ignores the :global pseudo-class used by CSS Modules. An override disables nesting-selector-no-missing-scoping-root for packages/workbench/src/client/**/*.css. The .stylelintignore file excludes ui/dist/** from linting.

Second, npm run lint:stylelint -- --fix was run across the codebase. This auto-formatted CSS files to comply with configured rules. Changes include property reordering (e.g., display before width), color function notation (rgba() to rgb() with alpha parameter, hsla() to hsl() with alpha), alpha value notation in oklch() (decimal 0.145 to percentage 14.5%), hex color shortening (#ccccff to #ccf), splitting single-line declaration blocks to multiple lines, and using overflow-wrap instead of deprecated word-break: break-word.

Third, the fix script in package.json now includes && npm run lint:stylelint -- --fix. The stylelint-suppressions.json file was deleted since all violations are resolved.

Contribution

Timeline

Opened: April 2, 2026
Committed: April 2, 2026

Key contributors

lauriii (Acquia)
justafish (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580210: [Notifications] REST API endpoints

Wed, 01 Apr 2026 20:03:21 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: a35f3db
Discussion: #3580210 · 1 contributor · 6 comments
Followers: 3

Summary

Canvas's notification system now has REST API endpoints that the Canvas UI uses to fetch and mark notifications as read. These endpoints are internal to Canvas and not intended for external use.

Impact

No upgrade or configuration changes required.

Technical details

The Canvas module provides a notification system for background processes like GitHub sync. This change adds two REST endpoints so the Canvas UI can display and interact with those notifications.

Two routes are added to canvas.routing.yml: GET /canvas/api/v0/notifications and POST /canvas/api/v0/notifications/read. Both require _canvas_authentication_required and _canvas_ui_access checks.

ApiNotificationController implements both endpoints. The list() method calls CanvasNotificationHandler::getRecent() with the current user's ID and returns notifications wrapped in a data object. Each notification includes hasRead state specific to the requesting user. The markRead() method decodes the request body, validates that an ids array is present, calls CanvasNotificationHandler::markRead() with the current user's ID and the notification IDs, and returns 204 No Content.

The OpenAPI spec (openapi.yml) defines both endpoints and adds a Notification schema. The schema includes id (UUID), type (enum: processing, success, info, warning, error), key (nullable string for deduplication), title, message, timestamp (Unix milliseconds), hasRead (boolean), and actions (nullable array of label/href objects).

Tests validate response structure against the OpenAPI spec, per-user read state (one user marking a notification as read does not affect another user's read state), authentication requirements, 204 responses, read state persistence across requests, and request validation. The OpenAPI request validator rejects missing or invalid ids fields before the controller runs.

Contribution

Timeline

Opened: March 19, 2026
Committed: April 1, 2026 (13 days later)

Key contributors

justafish (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580214: [Notifications] RTK Query API and Redux slice

Wed, 01 Apr 2026 13:18:19 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 87b6bcb
Discussion: #3580214 · 1 contributor · 6 comments
Followers: 3

Summary

This adds the frontend data layer for the notification system. It includes an RTK Query API service with endpoints for fetching notifications and marking them as read, a Redux slice for UI state (page open timestamp and activity center visibility), utilities for sorting notifications and formatting timestamps, constants for polling intervals and auto-read notification types, and a document visibility hook. No UI components are built in this ticket.

Impact

No upgrade or configuration changes required.

Technical details

The change creates the Redux and RTK Query infrastructure for a notification system that will be consumed by UI components in later tickets.

RTK Query API (notificationsApi.ts) defines the Notification type with fields for id, type ('processing' | 'success' | 'info' | 'warning' | 'error'), title, message, timestamp, hasRead, and optional actions. Two endpoints are created: getNotifications queries /canvas/api/v0/notifications, and markNotificationsRead posts to /canvas/api/v0/notifications/read with an array of notification IDs. The mutation implements optimistic updates by dispatching updateQueryData to immediately set hasRead: true for the specified IDs in the cached query result, then undoing the patch if the server request fails.

Redux slice (notificationsSlice.ts) manages two pieces of state: pageOpenedAt (initialized to Date.now() when the slice is created) and activityCenterOpen (boolean). It provides a setActivityCenterOpen action and selectors for both state fields.

Sorting utility (sortNotifications.ts) implements a four-tier priority system: processing notifications (priority 0), unread errors (priority 1), unread warnings (priority 2), and everything else (priority 3). Read errors and warnings drop to the lowest tier. Within each tier, notifications are sorted by timestamp descending (newest first).

Badge count utility (selectBadgeCount.ts) returns the count of all notifications where hasRead is false, regardless of type.

Timestamp utility (formatTimestamp.ts) computes the difference between Date.now() and the notification timestamp and returns "Now" for less than 1 minute, "Xm ago" for less than 60 minutes, "Xh ago" for less than 24 hours, or "Xd ago" for 24 hours or more.

Constants (constants.ts) defines AUTO_READ_TYPES as a Set containing 'success' and 'info', which will be used by UI components to determine which notification types are automatically marked as read when displayed. Three polling interval constants are defined (2000ms, 10000ms, 300000ms) for future use by components that will determine polling frequency based on whether processing notifications are present and whether the browser tab is focused.

Document visibility hook (useDocumentVisibility.ts) wraps document.visibilityState with a visibilitychange event listener and returns a boolean indicating whether the document is visible.

Both the API and slice are registered in store.ts by adding them to combineSlices() and adding notificationsApi.middleware to the middleware chain. Unit tests cover the sorting logic, badge count computation, timestamp formatting, and slice reducers.

Contribution

Timeline

Opened: March 19, 2026
Committed: April 1, 2026 (13 days later)

Key contributors

justafish (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580212: [Notifications] cron cleanup

Wed, 01 Apr 2026 11:42:24 +0000

Project: Drupal Canvas
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: 8385152
Discussion: #3580212 · 1 contributor · 6 comments
Followers: 3

Summary

The Canvas module now automatically cleans up notifications via cron. Processing notifications older than 30 minutes are deleted and replaced with error notifications titled "Operation timed out" so users know the operation did not complete. All notifications and read entries older than 30 days are deleted to prevent unbounded database growth. Both operations run automatically on every cron run.

Impact

Affects module maintainers.

New API: Two new public methods on CanvasNotificationHandler: purgeStaleProcessing() and deleteExpired() for manual cleanup triggers

Technical details

The Canvas notification system stores notifications and read status in two database tables. Without cleanup, these tables would grow indefinitely. This change adds two cleanup operations that run on cron.

CanvasNotificationHandler gains two new public methods. purgeStaleProcessing() queries for processing-type notifications with timestamps older than 30 minutes (using the idx_type_timestamp index), creates an error notification for each with the same key and message but title "Operation timed out", then deletes all stale processing notifications in a single query. Non-processing notifications are never affected by this operation.

deleteExpired() removes all notifications and read entries older than 30 days regardless of type. It uses a transaction to ensure both deletes succeed or both fail. Notifications are deleted first, then read entries, to prevent orphaned read entries. Both queries use the same pre-computed cutoff timestamp to ensure consistency.

The timeout (30 minutes) and retention period (30 days) are stored as class constants PROCESSING_TIMEOUT_MS and RETENTION_MS on CanvasNotificationHandler, not configuration values.

NotificationCronHook implements hook_cron using the Hook attribute system. It injects CanvasNotificationHandler and calls purgeStaleProcessing() followed by deleteExpired() on every cron run.

Contribution

Timeline

Opened: March 19, 2026
Committed: April 1, 2026 (13 days later)

Key contributors

justafish (Acquia)
f.mazeikis

This content is AI-generated and may contain errors. See Drupal Digests for more.