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

[Stan Silvert]

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  <mailto:keycloak-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     keycloak-dev mailing list
>>>>     keycloak-dev at lists.jboss.org  <mailto: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  <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160215/d417b4a0/attachment-0001.html