April 2021 - Koha-devel - lists.koha-community.org

How to make self-referential URLs in Koha
by dcook＠prosentient.com.au 30 Jan '23

30 Jan '23

Hi all, With some recent code, I've been using creating self-referential URL in Koha using CGI->url(), and passing it as a value. With CGI, the URL is correct (ie starting with /cgi-bin/koha). With Plack, it's not, because the OPAC is mounted as "/opac". I worked around this by rewriting the self-referential URL in my code, but I was wondering if anyone else had any thoughts on this. I've noticed there are a few places in Koha where we use CGI->url() and I'm guessing we may have unexpected bugs in Plack-enabled Koha as a result. Of course, one workaround would be to have /opac and /intranet aliases or URL rewriting in Apache, so that the self-referential URLs created by Plack still end up resolving. I wonder if that's the easiest path forward. In the past, I have wondered if we could get rid of "/cgi-bin/koha" as a path prefix all together (especially as cgi-bin scares security tools), but it's so deeply embedded in Koha at this point that it seems a huge task to replace it. Anyway, just throwing that out there. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

6 8

String Freeze Notice
by Joy Nelson 12 Aug '22

12 Aug '22

Greetings! Just a quick note that string freeze will go into effect at the end of day 12/16/2019 for the maintenance branches. Maintenance releases scheduled for the 23rd. Translations can begin on the 17th. Thanks! -- Joy Nelson President, Koha Division ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

3 3

Z39.50 daemon with ElasticSearch
by Zeno Tajoli 24 Jun '21

24 Jun '21

Hi to, I'm trying to use ElasticSearch everywhere with Koha 20.11 I'm working on Debian 10, EleasticSearch 6.8.13, Java openjdk 11 (Debian package) The search on Opac and Intranet is OK. Problems are on z39.50 server. With bug 13937 a z39.50/SRU server is ready also with ES as search back-end. But now the demonization of the script doesn't work. If i do: sudo koha-z3950-responder --start lib and I do a check with: yaz-client Z> open 127.0.0.1:2100/biblios Connecting...OK. Sent initrequest. Target closed connection Z> The result is 'closed connection', ZOOM error: 1004 But if do: sudo koha-z3950-responder --stop lib sudo koha-shell lib /usr/bin/perl /usr/share/koha/bin/z3950_responder.pl -c /etc/koha/sites/lib/z3950 -l /var/log/koha/lib/z3950.log koha@deb:~$ yaz-client Z> open 127.0.0.1:2100/biblios Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Koha/GFS/YAZ Version: 20.11.00.000/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3 Options: search present triggerResourceCtrl namedResultSets Elapsed: 0.012131 Z> f css3 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1, setno 1 records returned: 0 Elapsed: 0.915224 Z> show 1 Sent presentRequest (1+1). Records: 1 []Record type: USmarc 00357nam a22001217a 4500 005 20201208204443.0 008 201208b ||||| |||| 00| 0 eng d 040 $c IFLA 100 $a Tajoli, Zeno 245 $a Node.js e CSS3 ... So the script 'z3950_responder.pl' is working, the transformation into daemon not. Do you have any suggestion/check to fix this situation ? Cheers Zeno Tajoli -- Zeno Tajoli System Librarian

3 4

Why is config ($KOHA_CONF) stored in memcached ?
by Julian Maurice 04 May '21

04 May '21

Hi all, Maybe it's a dumb question, but I don't understand why the config is stored in memcached as: - memcached server address is in this config, so we need to read $KOHA_CONF file first in order to connect to memcached server - config is kept in memory forever ($C4::Context::context), so we shouldn't need the cache once starman has started. If you add a warning in Koha::Config::read_from_file, you'll see that the file is read 3 times per worker, even when the config already exist in cache (it's read 4 times when the cache is empty). It's read each time we call Koha::Cache->new (+ in C4::Context->new if the cache is empty) Shouldn't we read the file only in C4::Context->new (without using cache), and make Koha::Cache use C4::Context->config instead ? -- Julian Maurice BibLibre

3 5

Elasticsearch vs OpenSearch
by dcook＠prosentient.com.au 03 May '21

03 May '21

Because I'm good at stirring up trouble. https://www.techrepublic.com/google-amp/article/opensearch-aws-rolls-out-its -open-source-elasticsearch-fork/ As you may know, AWS have forked the last FOSS Elasticsearch (7.10 I think). They've announced that they're calling it OpenSearch. It's still only in alpha stage and they won't have a production-ready release for months yet, but it is interesting to keep notes on. Elastic are responsible for the vast majority of commits in Elasticsearch, so I'm somewhat skeptical about a fork, but I think there is a lot of anger at Elastic and a lot of support for OpenSearch, so who knows. I don't think there's anything to do at this stage, but just wanted to share the information for people David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Koha Community Newsletter: April 2021
by Koha Newsletter 01 May '21

01 May '21

The Koha Community Newsletter for April 2021 is here: * https://koha-community.org/koha-community-newsletter-april-2021/ Many thanks to everyone who submitted articles and news to last month's newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter

1 0

Optimizing Starman startup
by dcook＠prosentient.com.au 30 Apr '21

30 Apr '21

Hi all, Do you despair when you see the following periodically in "top" when a starman worker is recreated ? PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9529 my-koha 20 0 460108 197212 17172 R 100.0 0.4 0:03.41 /usr/share/koha/api/v1/app.pl Or the following in top when you install koha-common package or restart the koha-common service? 11101 1-koha 20 0 447232 193320 16076 R 10.6 0.4 0:09.09 /usr/share/koha/api/v1/app.pl 11168 1-koha 20 0 447240 193264 16056 R 10.6 0.4 0:08.72 /usr/share/koha/api/v1/app.pl 11306 2-koha 20 0 447220 193148 16000 R 10.6 0.4 0:08.07 /usr/share/koha/api/v1/app.pl 11543 2-koha 20 0 447232 193036 15828 R 10.6 0.4 0:07.07 /usr/share/koha/api/v1/app.pl 11784 3-koha 20 0 441536 189664 16172 R 10.6 0.4 0:06.04 /usr/share/koha/api/v1/app.pl 11830 3-koha 20 0 439548 187212 15748 R 10.6 0.4 0:05.82 /usr/share/koha/api/v1/app.pl 11831 4-koha 20 0 438620 186344 15748 R 10.6 0.4 0:05.81 /usr/share/koha/api/v1/app.pl 11853 4-koha 20 0 437680 185672 16000 R 10.6 0.4 0:05.79 /usr/share/koha/api/v1/app.pl Well, I still have a lot of investigation left to do, but I notice 1 place that a lot of time taken is here (per worker): my $validator = JSON::Validator::OpenAPI::Mojolicious->new; $validator->load_and_validate_schema( $self->home->rel_file("api/v1/swagger/swagger.json"), { allow_invalid_ref => 1, } ); push @{$self->routes->namespaces}, 'Koha::Plugin'; my $spec = $validator->schema->data; $self->plugin( 'Koha::REST::Plugin::PluginRoutes' => { spec => $spec, validator => $validator } ); $self->plugin( OpenAPI => { spec => $spec, route => $self->routes->under('/api/v1')->to('Auth#under'), allow_invalid_ref => 1, # required by our spec because $ref directly under # Paths-, Parameters-, Definitions- & Info-object # is not allowed by the OpenAPI specification. } ); Anyone have ideas for improving this? Do we have to validate the schema every time? Can we move the schema validation into a different module and preload it into Starman using the -M flag so that it's done 1 time per Starman master instance rather than 1 time per Starman worker instance? I find "/usr/share/koha/api/v1/app.pl" to be the bane of deployments, as it puts a massive load on a server, when you have multiple Koha instances on the server. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

5 24

git trick for compiled CSS
by Fridolin SOMERS 29 Apr '21

29 Apr '21

Hi, I'd like to share a trick. When generating compiled CSS files, no way to check the git diff since all is on one line. I've managed to find a trick : git show --word-diff shows chucks deleted/added so with some regexp : git show --word-diff $SHA1 | egrep '(\[\-)|(\{\+)' | sed -r 's/^.*(\[\-.*\-\]\{\+.*\+\}).*$/\1/g' For example : aebd3f6a53 Bug 27566: Compiled CSS [-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} [-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} [-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} [-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} This is very usefull to check that compilation worked and did not broke the 90% of the file XD Best regards :D -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

3 2

Template::Toolkit and Translations
by dcook＠prosentient.com.au 28 Apr '21

28 Apr '21

Hi all, While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently Ive been looking at the Languages dropdown in the OPAC advanced search. In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead? Consider the following: [% BLOCK en %]Anglais[% END %] [% BLOCK fr %]Français[% END %] [% langs.en = INCLUDE en %] [% langs.fr = INCLUDE fr %] I suppose its not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML. As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017) we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since were not producing HTML, we could flexibly reuse this language data in various different contexts. Whether its the Languages dropdown in the OPAC advanced search, the language selector, or whatever. We could probably use this concept in other places as well where we need translations but we dont want to be bound to HTML. What do people think? Im not wedded to the idea, but its something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=120 17&attachment=40285> &bug=12017&attachment=40285. (To that end, I would also suggest a theme-independent Template::Toolkit include directory, but thats another story) David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 4

Koha 19.11.17 released
by Victor Grousset/tuxayo 26 Apr '21

26 Apr '21

Hello! The Koha Community is happy to announce the release of Koha 19.11.17 The full release notes can be found at: https://koha-community.org/koha-19-11-17-released/ Debian packages should be available shortly. Thanks to everyone involved :) Cheers, -- Victor Grousset/tuxayo

1 0