Replies: 5 comments 4 replies
-
|
Managing custom Keycloak themes has always been a challenge. Projects like Keycloakify tries to address this issue, they don't fully overcome the mentioned shortcomings and introduce another potential point of failure to the stack. Zitadel adopts an API-first approach, which is the direction Keycloak has been taking since version 19, when it introduced a React Admin Console. As one contributor noted in a discussion about theme versioning (#10946):
|
Beta Was this translation helpful? Give feedback.
-
We're also on the way to migrate our account page from v2 to v3 and we're having the same concerns.
We added a new react component and imported it to all of our pages instead of modifying the index.ftl file in v2, I think that should work in v3 too. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the structure of the new ui, I can vaguely understand the reasoning behind it (the use of mvn to package js modules, the separation and reuse of admin and account components, etc.), which is to solidify the build process and facilitate reusable components across admin and account pages. But it also makes it harder to customize locally AND keeping track with the upstream changes. Our current strategy to customize the v3 theme is cloning the Also, is v3 a stable ui of Keycloak in a foreseeable future (say at least 5 or 10 major versions from now)? Is there any v4 ui in development that could deprecate the v3 ui just as fast as how v3 replaces v2? It'd be great if some core members could take time to help us shed some light on this. |
Beta Was this translation helpful? Give feedback.
-
|
We are currently not working on a v3 and we have heard you @tu-pm and others from the community. Initially we just wanted to make the account ui just a lot better and then later focus on how to make the customization better. And you are right our dissensions in how our build has been setup makes things less flexible, but we are going to publish the account ui as an npm package under |
Beta Was this translation helpful? Give feedback.
-
|
@edewit I found the https://www.npmjs.com/package/@keycloak/keycloak-account-ui, is there anything done or ongoing related to "later focus on how to make the customization better.". I am mostly referring to documentation or guides on how to customize keycloak-account-ui |
Beta Was this translation helpful? Give feedback.
-
|
Sry for adding grief. This is probably the most involved theme upgrade I have laid hands on. Going from a customized Account v2, to the new Account v3. I have downloaded the extend-account-console quickstart and started there. Right now I am stuck on how the messages_en.properties are used. Take 'accountManagementWelcomeMessage' as example, grepping through the quickstart, it is not used anywhere, should I assume that it is inherited from its parent which is keycloak.v3. Going to the Keycloak code and grepping through the code also just show it used at themes directory (? woot), nothing in the js directory. Does this mean there are some other connection between js and themes or what am I missing. |
Beta Was this translation helpful? Give feedback.
-
|
A lot of the localization happens in the base theme https://github.com/keycloak/keycloak/blob/main/themes/src/main/resources/theme/base/account/messages/messages_en.properties or the corresponding community translations https://github.com/keycloak/keycloak/tree/main/themes/src/main/resources-community/theme/base |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I am aware of themes and inheritance between them, I just need to wrap my head around how the js uses those. Eventually it will become obvious. |
Beta Was this translation helpful? Give feedback.
-
We are going to upgrade everything to the same version of patternfly and then all variable names to override would be the same |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Good evening,
I have a bit of feedback on the user experience of porting my customizations from account.v2 to account.v3.
For context, these customizations largely consist of a custom colour scheme, by overriding the patternfly variables and adding a footer for legal links.
Porting the colour scheme was fairly straightforward and basically the same as before and by now a trained process.
Two minor sidenotes:
Now adding the footer. Previously we just added it to the index.ftl and were done. Now the index.ftl is no longer part of the repository, but apparently happens some time during the build phase of an entirely different module, making the structuring of the source code less obvious.
However, there are these two imports, changing, whenever something in the source changes.
The update process thus becomes a lot more tedious as this needed to be updated with every new release.
The migration guide does say to always diff these customizations, but so far the only ways i'm aware of or can think of to obtain these files are building the "new" js module yourself or dig through the jar file.
This is a rather tedious process and i wonder whether I'm approaching it in the wrong way or there are ways to improve it.
And maybe adding a little hint that the account console is no longer located with the other themes?
Beta Was this translation helpful? Give feedback.
All reactions