[keycloak-dev] Need to remove built-in themes from standalone/configuration/themes

Tue Feb 16 10:40:52 EST 2016

We've had chats with folks that know about the patching tools now and it
turns out that by simply moving the themes from
standalone/configuration/themes they can be patched. If someone has changed
the built-in themes they will get a warning and be asked if they want to
cancel the patching or overwrite the file.

So problem solved by simply moving themes from
standalone/configuration/themes to standalone/themes.

On 15 February 2016 at 16:15, Marko Strukelj <mstrukel at redhat.com> wrote:

> I'm thinking of a workflow I would find useful, and I think it would
> be something like this:
>
> There is a directory with extracted theme files which I don't touch -
> $KEYCLOAK_HOME/standalone/configuration/themes/expanded. Keycloak
> automatically extracts files into it upon startup. I as a developer do
> a 'git init && git add * && git commit -a -m "Keycloak 1.9.0.CR1"' in
> it to turn it into a git repo.
>
> My theme development repo is somewhere else on the disk, outside the
> KEYCLOAK_HOME, let's say in ~/kc-theme.
>
> In there a have a .git repo with:
> git init
> git remote add kcinstall
> file://$KEYCLOAK_HOME/standalone/configuration/themes/expanded
>
> Now I can do:
> git fetch kcinstall
> git reset --hard remotes/kcinstall/master
>
> I have my inital custom theme. I make changes and work on it.
>
> When patching is performed on keycloak install it would result in
> either complete rewrite of standalone/configuration/themes/expanded or
> in only some files changing. If it is the former then I can simply
> reinit git repo there as the first time, it it's the latter I just do
> 'git add * && git commit -a -m "Keycloak 1.9.0.Final"'. Then in my
> working dir I say:
>
> git fetch kcinstall
> git rebase remotes/kcinstall/master
>
> Now I fix any merge conflicts ...
>
> The effective theme dir for my Keycloak instance can be under
> standalone/configuration/themes/public, and in that directory I can
> expand my theme copy. Or for development I can configure in
> keycloak-server.json to use my working directory ~/ks-theme.
>
>
>
> On Mon, Feb 15, 2016 at 3:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> > On 2/15/2016 9:03 AM, Bill Burke wrote:
> >
> > Users will be editing and playing with our existing themes to figure how
> to
> > extend things.  I'll go as far to say that *EVERY* user will do this.  It
> > needs to be really easy to do and is just as important as playing nicely
> > with the patch mechanism.
> >
> > I agree on making it really easy.
> >
> > IMO, the real solution is to make themes fully manageable from the admin
> > console.  You should be able to upload and download themes.  Then, you
> could
> > download the default themes and copy them but not allow overwrite.
> >
> > This also solves the openshift problem as you would be able to upload
> themes
> > to an openshift-based Keycloak instance.  And, we wouldn't have to do
> > anything special to account for the patch tool as the default themes
> would
> > just be read from the module and never modified unless patched.
> >
> > Obviously, that's more of a long-term solution though.  It would take a
> fair
> > amount of work to implement.
> >
> >
> >
> > On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
> >
> > Keeping it as is isn't an option IMO. There's a pretty big chance that we
> > will need to patch themes. There's several issues with that as it stands:
> >
> > * Users need to deal with two separate patching mechanisms and we also
> need
> > to create tools, patches, documentation separately
> > * What if users change the built-in themes, rather than extending. We
> tell
> > users not to, but if they can they will. If a built-in theme has been
> > changed patches probably won't work
> > * EAP supports roll-back of patches, applies patches atomically. It's a
> > proper tool that helps users to do it right
> > * EAP supports domain mode
> >
> > What Stan is proposing might be worth considering. It doesn't solve the
> case
> > that users can modify the files though.
> >
> > I would actual prefer that built-in themes are always loaded from the
> > module, but we have the templates available in exames/themes/templates.
> >
> > Another relevant thing is what do we do when users have modified
> templates.
> > How can we help them apply the required changes to the custom template?
> >
> > On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com> wrote:
> >>
> >> BTW, how do you deal with theme changes on OpenShift?  Looks like a year
> >> ago the answer was, "fork the cartridge".  Is that still the only
> solution?
> >>
> >>
> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
> >>
> >> On 2/12/2016 12:46 PM, Bill Burke wrote:
> >>
> >> Keep it the way it is, IMO.  Write directions on how to handle a theme
> >> patch.
> >>
> >> On 2/12/2016 11:01 AM, Stan Silvert wrote:
> >>
> >> Another way to deal with this might be to unjar the files ourselves at
> >> startup.  The files could live in the same place they live today.
> >>
> >> We would just have keep track of versioning.  If a newer version of the
> >> theme is installed we overwrite the old version in
> >> standlone/configuration/themes.  Of course, if the theme has been
> modified
> >> by the user we wouldn't overwrite, but instead just unjar to another
> >> location.
> >>
> >> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
> >>
> >> Currently we include built-in themes in the themes jar as well as
> >> extracted to standalone/configuration/themes. We have to remove the
> >> extracted files.
> >>
> >> This is due to patching. The patching tools only supports patching
> >> modules, not files. If we need to patch the theme templates (quite
> likely we
> >> will) we can then only patch the jar. As the extracted themes override
> the
> >> jar it won't work unless we remove them.
> >>
> >> The main problem with removing the extracted files is that they are
> useful
> >> for someone that needs to modify the templates. I think the best would
> just
> >> be to give people instructions on how to extract these from the jar.
> It's
> >> just a zip after all.
> >>
> >> Thoughts??
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160216/369bcfb0/attachment-0001.html 