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> 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. But yeah. I like the idea of a registry… where you could choose XSLTs for the Z39.50 filtering, MARCXML->HTML display, exports, etc. I’m doing OAI-PMH imports right now and I want to filter using XSLT, but it’s painful for library users to define these XSLT filepaths. There should be a simple option for users who aren’t developers/sysadmins. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Barton Chittenden Sent: Wednesday, 15 June 2016 12:20 AM To: Owen Leonard <oleonard@myacpl.org> Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Using the file upload feature for more customization Owen, I've been wrestling with the issue of CSS and XSLT as well, my proposed solution is Add Content system preferences for all CSS and XSLT sysprefs that accept a URL. ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16648 ) that should be relatively easy to implement, simply because we can re-use code from sysprefs like intranetuserjs. I do like the idea of a flexible file uploader though; it's definitely more flexible... On Tue, Jun 14, 2016 at 9:31 AM, Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org> > wrote: Now that there is a generic file upload tool, could that be used to offer more customization options in areas where file selections are used? I'm imagining a system where you define upload categories: CSS, image, audio file, XSLT. Then wherever a setting allows you to select a file in that category Koha would list your uploaded files as options. Currently it's a problem for libraries who want to define their own set of item type icons or load a separate CSS file: Where does the file go? I just wanted to throw that idea out there in case it sounded interesting to someone. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

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.