The setup-wasm-features function is the single source of truth for
resolving the renderer choice (URL param > profile preference > team
flags), storing the result in state[:features]. Several helpers were
re-deriving the same priority chain independently, duplicating logic:
- wasm-enabled?, wasm-url-override, wasm-url-override-ref
- enabled-by-flags?, enabled-without-migration?
This change removes all duplicated helpers and simplifies the
remaining functions to rely exclusively on the pre-computed
:features set:
- active-feature? — now just checks (contains? (:features state)
feature) without special-casing render-wasm/v1
- use-feature — uses the reactive features-ref for all features
- initialize/recompute-features effects — use the local features
binding directly
Since :features is rebuilt by setup-wasm-features on every
initialization and recompute, this preserves correctness while
eliminating ~50 lines of duplicated code.
Rename the icon file and fix the icon ID from "elipse" (single "l")
to "ellipse" (double "l") across the codebase.
The root cause was a mismatch: the icon file/ID was named "elipse"
but get-shape-icon returns "ellipse" for circle shapes. Since the
icon* component validates icon-id against the auto-generated
icon-list set, the string "ellipse" failed validation.
Changes:
- Rename frontend/resources/images/icons/elipse.svg to ellipse.svg
- Fix icon def in icon.cljs: ^:icon-id elipse -> ^:icon-id ellipse
- Fix deprecated icon in icons.cljs: ^:icon elipse -> ^:icon ellipse
- Fix usage in top_toolbar.cljs: deprecated-icon/elipse -> ellipse
- Fix usage in history.cljs: deprecated-icon/elipse -> ellipse
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
The S3 storage backend uses DefaultCredentialsProvider which includes
WebIdentityTokenFileCredentialsProvider in its chain. However, that
provider requires software.amazon.awssdk/sts on the classpath to call
AssumeRoleWithWebIdentity. Without it, the provider silently fails and
credentials cannot be resolved when using IRSA on EKS.
Closes#9927
Signed-off-by: Joshua C <joshua.cullum@gmail.com>
Co-authored-by: Joshua C <joshua.c@data-edge.co.uk>
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
`cls/show-in-viewer` unconditionally dissoc'ed `:hide-in-viewer` on the
interaction destination, so every `add-interaction`, `add-new-interaction`,
and `update-interaction` call silently re-enabled the destination's
view-mode visibility — even when the user had just deliberately hidden
that frame. Reporter (#9049) hid a board, dragged a prototype arrow at
it, and watched the board reappear in View Mode.
Make `show-in-viewer` a no-op when the destination already has
`:hide-in-viewer true`. The auto-unhide still fires on destinations with
no explicit hide flag (the original ergonomic — new prototype targets
default to visible), but explicit user intent is now preserved across
interaction-add / interaction-update.
Behaviour change: dropping the auto-unhide on explicitly-hidden
destinations matches the reporter's expectation ("nothing would show up
in View Mode unless explicitly marked as such") and the surrounding
`:hide-in-viewer`-aware UI in `measures.cljs`, which already lets users
toggle the same property directly.
Closes#9049.
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
Fixes#9135.
The <link href="css/ui.css"> tag in
frontend/resources/templates/index.mustache references a CSS file that
the build pipeline never produces:
- compileStyles() in frontend/scripts/_helpers.js only writes main.css
(always) and debug.css (dev-only) — there is no write to ui.css
- compileStorybookStyles() writes ds.css (design system), not ui.css
- No ui.scss source exists anywhere in frontend/resources/styles/
The reference was added in 45d04942c ("✨ Add example ui
storybook") but no corresponding build step was added to emit the file.
Result: every page load issues a request for /css/ui.css that nginx
returns as 404. In self-hosted Penpot deployments behind a reverse
proxy, the SPA's CSS init promise rejects on the 404, the React root
never mounts, and the user sees a black screen.
This patch removes the dead reference. If a future change actually
emits ui.css (or another distinct UI bundle), the <link> can be
re-added at that time.
Co-authored-by: Admin <admin@Admins-MacBook-Pro.local>
* ♻️ Refactor font upload to process variants sequentially
Change the batch upload handler so fonts are uploaded one at a time
instead of all concurrently, preventing excessive simultaneous
upload requests.
Previously `on-upload-all` used `run!` which fired all font variant
uploads simultaneously. Now it uses `rx/from` combined with
`rx/mapcat` to process each font sequentially.
As part of this change, extract the upload logic into a standalone
`handle-font-upload` helper for reuse between single and batch
upload paths, and remove the separately memoized `on-upload*` hook.
Also fix error logging to use `js/console.error` instead of
`js/console.log` for consistency with project conventions.
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
* 📎 Add code comment
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
---------
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
The version preview banner in `enter-preview` derives its title from
`(:label snapshot)` directly. For system-created autosaves that
field is the internal snapshot label (e.g. `internal/snapshot/20`),
so the banner shows the raw internal string while the History sidebar
already renders the same autosave through `workspace.versions.autosaved.version`
plus a localized date. The mismatch makes it hard to be sure which
sidebar entry you're previewing, especially when several autosaves
sit close together (#9503).
Switch the label resolution to mirror the sidebar's `snapshot-entry*`:
- `:created-by "system"` snapshots format the label as
`(tr "workspace.versions.autosaved.version" (ct/format-inst ...
:localized-date))` — the exact same translation key + date format
the sidebar's autosave group already uses
- `:created-by "user"` (pinned) versions keep their custom `:label`
with the existing `unnamed` fallback
No behavior change for pinned/user-named versions or for the
restore/exit dialog buttons.
Closes#9503.
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
