<p dir="ltr">Keeping it as is isn&#39;t an option IMO. There&#39;s a pretty big chance that we will need to patch themes. There&#39;s several issues with that as it stands:</p>
<p dir="ltr">* Users need to deal with two separate patching mechanisms and we also need to create tools, patches, documentation separately<br>
* 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&#39;t work<br>
* EAP supports roll-back of patches, applies patches atomically. It&#39;s a proper tool that helps users to do it right<br>
* EAP supports domain mode</p>
<p dir="ltr">What Stan is proposing might be worth considering. It doesn&#39;t solve the case that users can modify the files though.</p>
<p dir="ltr">I would actual prefer that built-in themes are always loaded from the module, but we have the templates available in exames/themes/templates.</p>
<p dir="ltr">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?</p>
<div class="gmail_quote">On 12 Feb 2016 19:32, &quot;Stan Silvert&quot; &lt;<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>BTW, how do you deal with theme changes
      on OpenShift?  Looks like a year ago the answer was, &quot;fork the
      cartridge&quot;.  Is that still the only solution?<br>
      <br>
<a href="http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html" target="_blank">http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html</a><br>
      <br>
      On 2/12/2016 12:46 PM, Bill Burke wrote:<br>
    </div>
    <blockquote type="cite">
      
      Keep it the way it is, IMO.  Write directions on how to handle a
      theme patch.<br>
      <br>
      <div>On 2/12/2016 11:01 AM, Stan Silvert
        wrote:<br>
      </div>
      <blockquote type="cite">
        
        <div>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.  <br>
          <br>
          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&#39;t overwrite, but
          instead just unjar to another location.<br>
          <br>
          On 2/12/2016 9:44 AM, Stian Thorgersen wrote:<br>
        </div>
        <blockquote type="cite">
          <p dir="ltr">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.</p>
          <p dir="ltr">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&#39;t work unless we remove them.</p>
          <p dir="ltr">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&#39;s just a zip after all.</p>
          <p dir="ltr">Thoughts??</p>
          <br>
          <fieldset></fieldset>
          <br>
          <pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
        </blockquote>
        <br>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
      </blockquote>
      <br>
      <pre cols="72">-- 
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div>