<p dir="ltr"><br>
On Jul 12, 2016 11:47 PM, "David Cook" <<a href="mailto:dcook@prosentient.com.au">dcook@prosentient.com.au</a>> wrote:<br>
><br>
> In regards to XSLTs, I’d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown.<br>
><br>
>  <br>
><br>
> As for <a href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648">https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648</a>, I’m curious why we’d have XSLTs publicly accessible. If you’re referencing “cgi-bin/koha/xslt/OPACXSLTResultsDisplay.xslt”, then anyone can come along and read what you have in your XSLT. I suppose Koha is open source, so that’s not really the end of the world, but it just seems odd to be allowing public access to that asset when you’re using it on the server. Why fetch it via Apache when you already have it on your system? Unless you’re getting a XSLT from some other server… but then it’s a separate issue.</p>
<p dir="ltr">Hmm. I hadn't really considered that the XSLTs *should* be private -- my consideration is that there is a pain point of having XSLTs as files -- how do you make sure that custom XSLT files move with an instance  on server upgrade? Where should the files reside on an instance by instance basis?</p>
<p dir="ltr">Right now, the XSLT files are stored in  the main git repo, or are installed globally. Tracking customized xslt across tens or hundreds of instances is no fun, and xslt errors can be hard to trouble shoot (in the case of a mis versioneed xslt file) if you're not expecting them.</p>