<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 7851 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 201, Issue 13<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Serving Intranet from a subpath (Thomas Klausner)<br> 2. String Freeze Notice for 21.11.11 (Arthur)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Fri, 12 Aug 2022 12:54:59 +0200<br>From: Thomas Klausner <domm@plix.at><br>To: koha-devel@lists.koha-community.org<br>Subject: [Koha-devel] Serving Intranet from a subpath<br>Message-ID: <20220812105459.GR864217@plix.at><br>Content-Type: text/plain; charset=us-ascii<br><br>Hi!<br><br>(I'm sending this to koha-devel because I guess it's too technical for <br>the general list?)<br><br>We are running running the "Intranet" inside an actual intranet (i.e. <br>inside a VPN). But this Koha instance is also hosting a related Library <br>whose staff cannot access the VPN. For various reasons it is not <br>possible to mount Koha at it's own domain, so we must make it available <br>at a sub-path (something like "https://www.example.com/foo/koha")<br><br>For the OPAC, I already implemented a hacky Plack Middleware that does <br>some rather ugly rewriting or URLs and HTML (ughh..). While we could do <br>the same for Intranet, I first wanted to check if it is maybe already <br>possible to mount it under a subpath, i.e. have an Apache use something <br>like <br><br>ProxyPass /foo/koha/index.html ...<br>ProxyPass /foo/koha/cgi-bin/koha ...<br><br>Now, while this actually works, the pages returned do not, as all the <br>links they contain point to /cgi-bin/koha (i.e., they loose the mount <br>point and generate bad links).<br><br>The usual way to solve this is via something like<br>https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath<br><br>But for this work, two things (one small, one not) have to be changed:<br><br>* the plack app (i.e. Koha) needs to honor some HTTP Header ENV vars<br> (X_FORWARDED_SCRIPT_NAME, X_TRAVERSAL_PATH)<br>* and all links generated by the app need to also honor those vars.<br><br>The usual way for the latter is to *not* generate links by concatenating <br>path fragments or hardcoded them in templates (which seems to be what <br>Koha is doing), but to use a function/method to generate all links (to <br>html pages, static assets and endpoints)<br><br>So for example in a template like prog/en/modules/cataloguing/addbooks.tt<br>we find:<br> <a href="/cgi-bin/koha/mainpage.pl">Home</a><br><br>This would need to be changed to <br><br> <a href=uri_for("/cgi-bin/koha/mainpage.pl")>Home</a><br><br>and uri_for needs to take a look at the ENV and fix the link <br>accordingly.<br><br>(The ugly workaround I am using in an OPAC is to use a Middleware to <br>change the HTML after it's generated by Koha but before it is send to <br>the client. shudder...)<br><br>So on the one hand this seems to be a small change, but to work it needs <br>to touch ALL templates. (and it will be hard to automatically identify <br>all link-ish text in the templates (href, src, maybe sometimes the url <br>is generated in a template, ...)<br><br>Another approach would be to set the mount-point into <base <br>href="/foo/koha"><br>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base<br>But we would still need to change all the links to relative links, as <br>`base` will ignore absolute links, which is what Koha is using now.<br>though maybe the regex to replace the code is a bit easier <br>(s{/cgi-bin}{cgi-bin}) as it does have to fiddle with quotes etc.<br><br><br>Our customer is willing to do the work to implement this (probably also <br>in OPAC), but only if the change will be accepted upstream and be usable <br>by the end of this year (i.e. 22.11).<br><br>Shall we try to tackle this? Or will this massive change never be <br>accepted? If there is interest, I guess the next step is to open a <br>bug...<br><br><br>Greetings,<br>domm<br><br><br><br>-- <br>#!/usr/bin/perl https://domm.plix.at<br>for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}<br><br><br>------------------------------<br><br>Message: 2<br>Date: Fri, 12 Aug 2022 13:23:48 +0200<br>From: Arthur <arthur.suzuki@biblibre.com><br>To: koha-devel@lists.koha-community.org<br>Subject: [Koha-devel] String Freeze Notice for 21.11.11<br>Message-ID: <297b439c-f789-daf1-eddb-804d6e495456@biblibre.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Hello folks,<br><br>String freeze will go into effect as of today for 21.11.11 release.<br><br>Maintenance release scheduled for the 22 of this month (not next monday <br>but the one after).<br><br>Best,<br><br>Arthur Suzuki<br><br>Developer @BibLibre, Old-stable branch maintainer.<br><br><br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 201, Issue 13<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>