---- Reported by jwagner@ptfs.com 2010-05-04 15:46:39 ---- I'd like some feedback on this before proceeding. One of the most frequent customization requests I get is to display this or that MARC field or subfield in the OPAC. Usually this would have to be done by customizing the relevant XSLT stylesheet (MARC21slim2OPACResults.xsl and MARC21slim2OPACDetail.xsl are the two I usually work with. However, for sites where access to the server level is restricted or where local customizations are not allowed, this won't work. I'm thinking of creating a syspref to allow a site to specify a remote server location for the XSLT stylesheets. That way, sites could maintain and modify a file with local customizations, without requiring any server access. Trying to analyze the code in XSLT.pm, it looks like I could only allow specifying a path, not a filename. Both details and results files would have to be in place on the remote server, and retain the identical filenames as currently used. Right now, I'm only looking at OPAC XSLT, but the same logic could be extended to staff XSLT files as well. I think they would have to be stored in the same location as the OPAC ones, so maybe only one syspref should be created for both. Discussion? Potential problems? ---- Additional Comments From jwagner@ptfs.com 2010-05-04 16:06:23 ---- From discussion on the IRC, Henri-Damien Laurent has already done something similar related to http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3042. Details at http://www.mail-archive.com/koha-patches@lists.koha.org/msg04447.html http://markmail.org/message/lhz34uen3ljxd6za Does his approach take care of everything, or is any further work needed? --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:27 UTC --- This bug was previously known as _bug_ 4447 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4447 Unknown operating system Windows 2000. Setting to default OS "All". Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was jwagner@ptfs.com. The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, chris@bigballofwax.co.nz. Previous assignee was jwagner@ptfs.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Bug reassigned, setting status to "NEW". Previous status was "ASSIGNED".
Revisiting this issue. Henri-Damien's work in the referred-to message has not been finished. It's a promising approach (allowing for inclusion of a URL in the existing staff and OPAC XSLT sysprefs): + my $style_doc; + if ($xslfilename=~/http:/){ + my $xsltstring=GetURI($xslfilename); + $style_doc = $parser->parse_string($xsltstring); However, current code seems to have moved past the point at which the patch was written. The current code building the name of the relevant XSLT file now includes a language directory. For example: $xslfile = C4::Context->config('opachtdocs') . '/' . C4::Context->preference("opacthemes") . '/' . C4::Output::_current_language() . '/xslt/' . C4::Context->preference('marcflavour') . "slim2OPAC$xsl_suffix.xsl"; To prevent problems with translations, should the syspref only take a URL that goes to a directory level? Then, on the remote server, replicate the directory structure so that there is an en/MARC21slim2OPACDetail.xsl, fr/MARC21slim2OPACDetail.xsl, es/MARC21slim2OPACDetail.xsl etc. etc.? Also note the check for the themes directory in the above, which was hardcoded to "prog" in the earlier code. Should the remote directory structure be further amplified to be prog/en/MARC21slim2OPACDetail.xsl etc.? What would be the most flexible setup that would still allow for translations and (whenever it's implemented) different themes?
this is the same tan 4032 (needs signoff), so I close it
*** This bug has been marked as a duplicate of bug 4032 ***