fix: page background default now reflects actual branding value - EXO-88511 - #540
Open
srenault-meeds wants to merge 8 commits into
Open
Conversation
Switching the page width from full window back to custom collapsed the value to 0 because the customWidth computed property fell back to 0 when width was '100%', which the number-input then clamped to its min (300). Introduce a defaultWidth data property (1320) used as the fallback everywhere the previous default value was hardcoded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extend the shared BackgroundInput.vue component (used both from site "branding options" and the per-page "Edit Page Properties" drawer for page/site/application backgrounds) with 3 gradient types instead of the single implicit top-to-bottom linear gradient: - Linear Gradient: Top to Bottom (default, matches previous behavior) or Left to Right. - Radial Gradient: From color at the center, To color on the outside. - Angular Gradient: conic gradient anchored at one of the 4 corners (Top Left / Top Right / Bottom Right / Bottom Left), From color used as the start of the angle. backgroundEffect stays an opaque CSS background-image string end to end (no backend/DTO changes needed), so existing persisted values (plain `linear-gradient(from, to)`) keep parsing correctly as "Linear / Top to Bottom". Note: the angle mapping used for the angular/conic gradient per corner is a best-effort CSS implementation (I could not access the linked Adobe XD mockup); please visually confirm against the design before merging. EXO-88418 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Since the corner only shows a 90deg slice of the full 360deg conic gradient, the 2-color transition needs explicit 0deg/90deg stops so it completes within that visible slice instead of barely starting before the box edge cuts it off. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two independent bugs prevented alpha transparency from actually showing on gradient backgrounds (page, section and application): - BackgroundInput.vue: switching the background type radio to a gradient (linear/radial/angular) triggered two watchers reacting to the same change. The backgroundColorChoice watcher correctly set the container's backgroundColor to the fully-transparent #FFFFFF00 marker, but the choice() watcher ran right after and unconditionally reset it back to the opaque defaultBackgroundColor. That opaque white then became the CSS backdrop painted behind the gradient's background-image, so any alpha in the From/To colors blended against solid white instead of true transparency. The reset is now scoped to the "color" choice only. - ColorPicker.vue: the From/To color swatches painted their color directly on the drawer's panel background, so a semi-transparent color (e.g. #FFFFFF41) looked identical to a fully opaque one, making it impossible to visually confirm transparency was applied. Added a checkerboard backdrop behind the swatch (in editor.less, since this module's webpack config has no loader for Vue SFC <style> blocks) so alpha is now visible in the picker itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
(#532) Editable portlets (Text Block, Links List, News List, etc.) can hold custom content added by admins, so removing them from a page now asks for confirmation instead of deleting immediately.
…P-88511 The page-properties drawer read a CSS var (--allPagesLightGrey) that is never actually set by the branding admin page. The real value the admin configures is exposed as --allPagesBackgroundColor, so non-customized pages silently ignored the branding default. Also normalize the read value to an 8-digit hex so the color picker keeps its alpha/transparency support when the branding value has no alpha channel.
… - EXIP-88511 The small page-preview thumbnail in the page-properties drawer computed its style straight from pageContainer.backgroundColor, which is null when not customized, so the preview fell back to Vuetify's default card color instead of the branding default - only becoming correct once the user toggled "Global Page Background" on (which writes the default into storage). Fall back to defaultBackgroundColor for the preview only, without touching the stored value.
|
ahamdi
approved these changes
Jul 29, 2026
exo-swf
force-pushed
the
feature/ai-contribution
branch
from
August 1, 2026 01:39
e40e216 to
c9e9ec7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The page-properties drawer read a CSS var (--allPagesLightGrey) that is never actually set by the branding admin page. The real value the admin configures is exposed as --allPagesBackgroundColor, so non-customized pages silently ignored the branding default. Also normalize the read value to an 8-digit hex so the color picker keeps its alpha/transparency support when the branding value has no alpha channel.