Bug 4447 - Allow external URL/storage location for XSLT stylesheets
Summary: Allow external URL/storage location for XSLT stylesheets
Status: CLOSED DUPLICATE of bug 4032
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: PC All
: P5 - low enhancement (vote)
Assignee: Chris Cormack
QA Contact: Bugs List
URL:
Keywords:
Depends on: 4032
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-04 03:46 UTC by Jane Wagner
Modified: 2012-10-26 00:41 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:27:18 UTC


---- 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".

Comment 1 Jane Wagner 2011-03-28 13:25:20 UTC
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?
Comment 2 Stéphane Delaune 2012-02-06 10:07:22 UTC
this is the same tan 4032 (needs signoff), so I close it
Comment 3 Stéphane Delaune 2012-02-06 10:08:23 UTC

*** This bug has been marked as a duplicate of bug 4032 ***