Hi all,
I was running Koha Plack on OpenSuse (using CPANed libraries), and I noticed
that creating a new authority would take me to
/cgi-bin/koha/authorities/detail.pl?authid=1, which then spat out an error
in my logs of "Subroutine build_tabs redefined at
/path/to/koha/intranet/cgi-bin/authori
Latest commit is from April 8th. I belive it is in maintenance mode only.
We deprecated it, though. So focus is on ES integration.
El mié., 2 sept. 2020 a las 21:54, escribió:
> Hi all,
>
>
>
> I just noticed that Indexdata doesn’t provide Zebra packages past Debian
> Stretch: http://ftp.indexda
Hi Tomas, I don't think that's correct - there was never an official
decision on deprecating Zebra.
On 03.09.20 14:27, Tomas Cohen Arazi wrote:
Latest commit is from April 8th. I belive it is in maintenance mode only.
We deprecated it, though. So focus is on ES integration.
El mié., 2 sept. 202
I would say it's time to start thinking about alternatives/further
encourage the adoption of elastic search and clean up the search code in
general.
I still have a, perhaps misguided, fondness for zebra. I'm not sure Koha
has always used it to its strengths and it certainly has its own issues..
bu
Hi all,
Martin and Chris said it much better than me - thx for chiming in.
Katrin
On 03.09.20 21:47, Chris Cormack wrote:
Hi all
I agree, we do need to work on a lightweight alternative, and until we
have one support zebra.
The vast majority of Koha libraries will not have the budget to be
ab
Hi all
I agree, we do need to work on a lightweight alternative, and until we have one
support zebra.
The vast majority of Koha libraries will not have the budget to be able to run
an elastic search cluster.
So while elastic search is definitely great and we should continue to improve
our usage
Oh that’s interesting! I see references to Debian Buster in the commit log
(https://github.com/indexdata/idzebra/commits/master). I might shoot off an
email about getting some updated packages/releases.
Can we really call Zebra usage deprecated if it’s still the default stable
option for ne
I answered this because on some bug (which one I don't remember) I was told
we shouldn't 'add features' to Zebra code. But I need to dig a bit to
remember.
It might have been a communication issue, but we haven't been adding
features to Zebra code
On Thu, Sep 3, 2020, 14:02 Katrin Fischer wrote:
Hi all,
While troubleshooting Apache TimeOut for Plack vs CGI
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26128), I
discovered that Apache seems to respect TimeOut when measuring a timeout
proxying requests to Plack. However, it actually *doubles* the time when
running CGI script
Note I've opened an ASF Bugzilla bug report about this mod_cgi TimeOut
handling: https://bz.apache.org/bugzilla/show_bug.cgi?id=64709
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-d
That does sound familiar, although I wonder what sort of features were in mind…
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel On Behalf Of
Tomas Cohen Arazi
Sent: Friday, 4
I know what you mean, and I totally agree about Koha not using Zebra to its
strengths.
That said, Zebra does have some annoying limitations, although I have thought
how some of those could be worked around by wrapping Zebra with another program
(or even writing features and upstreaming them.
Hi all,
I just wanted to share how I've used Template::Toolkit WRAPPER in a Koha
plugin.
All the details are available at
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381, but
basically it boils down to creating 1 wrapper template, and then invoking
that using the WRAPPER di
13 matches
Mail list logo
