feat: add ThemeFontControl component for managing homepage fonts#1169
Open
manaskumar3003 wants to merge 4 commits intoHiEventsDev:developfrom
Open
feat: add ThemeFontControl component for managing homepage fonts#1169manaskumar3003 wants to merge 4 commits intoHiEventsDev:developfrom
manaskumar3003 wants to merge 4 commits intoHiEventsDev:developfrom
Conversation
- Created ThemeFontControl component to allow users to select and preview fonts. - Added styles for font options in ThemeFontControl.module.scss. - Introduced constants for homepage fonts in homepageFonts.ts, including font properties and stacks. - Implemented font loading utility in fontLoader.ts to ensure selected fonts are loaded dynamically.
Author
|
I have read the CLA Document and I hereby sign the CLA |
Contributor
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
recheck |
Contributor
|
Great addition, thank you! One suggestion would be to automatically use the organiser's font when creating an event. That way there's consistency between the organiser page and the event pages. Other than that, everything looks good. |
Extend the existing homepage_theme_settings snapshot in CreateEventService::createEventSettings() to also copy the organizer's font_family. Previously only accent, background, mode, and background_type were inherited, so new events always rendered in the default Outfit font even when the organizer had picked a different typeface for their own page. New behaviour: a new event's homepage_theme_settings.font_family is initialised from organizer.homepage_theme_settings.font_family at creation time. When the organizer has no font set, the key is omitted and the frontend falls back to the default. Subsequent changes to the organizer font do not propagate to already-created events — this matches the snapshot semantics of the other theme keys. Adds two unit tests in CreateEventServiceTest: - testCreateEventInheritsOrganizerFontFamily: asserts the key is written when the organizer has a font set - testCreateEventOmitsFontFamilyWhenOrganizerHasNone: asserts the default path stays clean when the organizer has no font
Author
|
@daveearley i have made changes but due to changes in main repo now we have merge conflicts |
…icts Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
|
Thanks @manaskumar3003! I've fixed the conflicts |
Author
|
When will it get merged btw? |
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
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.
What changes I've made
Added a font-family selector to the event and organizer homepage designers so organizers can pick a font for their public homepage and live-preview it before saving.
HomepageFontFamilyenum (backend/app/DomainObjects/Enums/HomepageFontFamily.php) defining the curated set of supported fonts.homepage_theme_settings.font_familyadded toUpdateEventSettingsRequestandPartialUpdateOrganizerSettingsRequest, restricted to enum values.HomepageFontFamilyTestcovering the enum.ThemeFontControlcomponent used by bothHomepageDesignerandOrganizerHomepageDesignerfor selecting/previewing a font.constants/homepageFonts.ts— single source of truth on the frontend (Bunny Fonts family slugs, weights, and CSS fallback stacks). Kept in sync with the backend enum.utilites/fontLoader.ts— dynamically injects the Bunny Fonts stylesheet for the chosen family when rendering the homepage or the designer preview, so only selected fonts are downloaded.themeUtils.tsapplies the selected font stack to the homepage theme;EventHomepage,OrganizerHomepage, and their SCSS were updated to consume it.types.tsextended with thefont_familyfield on homepage theme settings.en,de,es,fr,hu,it,nl,pl,pt,pt-br,ru,se,tr,vi,zh-cn,zh-hk).Why I've made these changes
The homepage designer previously only let organizers customize colors and background — the typography was locked to a single default, which made self-hosted instances feel same-y and limited branding options. Adding a curated font picker gives organizers a cheap, high-impact way to personalize their event and organizer pages without allowing arbitrary font URLs (which would be a security and performance risk). The font list is deliberately curated and kept in sync between the backend enum and the frontend constant so that invalid values can't reach the database and so the designer only shows fonts we actually know how to load.
How I've tested these changes
HomepageFontFamilyTest):docker compose -f docker-compose.dev.yml exec backend php artisan test --testsuite=Unit— all pass.npx tsc --noEmitin the frontend — no new type errors introduced by this change.font_familyvalue toPATCH /event-settings/ the organizer settings endpoint returns a 422 with the "selected font is not supported" message.Checklist