Hi Barton, You’re referring to your local Bywater practice, yes? By default, users would be using the XSLTs installed with their Koha (Deb packages or source install), so the default XSLTs would be registered using the filepath on the local server, I reckon. I suppose if you were to use HTTP, you could specify that in the registry as well, so I wouldn’t imagine it being a problem. The registry would just give you a user friendly name instead of a file or HTTP URL, and allow you to address it easily from anywhere in Koha. As for my local practice, we don’t maintain customized XSLTs much. We either use the default one packaged with Koha, or use a single customized one that we maintain per Koha version (rather than per client), and we use Local system preferences for the really specific stuff. But that’s just a different commercial practice. The registry should be able to handle either scenario : ). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: Barton Chittenden [mailto:barton@bywatersolutions.com] Sent: Wednesday, 13 July 2016 3:18 PM To: David Cook <dcook@prosentient.com.au> Cc: Koha-devel <koha-devel@lists.koha-community.org>; Tomas Cohen Arazi <tomascohen@gmail.com>; Owen Leonard <oleonard@myacpl.org> Subject: RE: [Koha-devel] Using the file upload feature for more customization On Jul 12, 2016 11:47 PM, "David Cook" <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote:
In regards to XSLTs, I’d love some sort of registry where you could add XSLTs and then reference them elsewhere from a dropdown.
As for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648, 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.
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? 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.