[Bug 26890] New: opac-detail plugin like intranet/cgi-bin/catalogue/detail.pl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Bug ID: 26890 Summary: opac-detail plugin like intranet/cgi-bin/catalogue/detail.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: koha@trust-box.at QA Contact: testopia@bugs.koha-community.org enable opac-detail to use the same/similar plugin infrastructure as in intranet/cgi-bin/catalogue/detail.pl 68 my @plugins = Koha::Plugins->new()->GetPlugins({ 69 method => 'intranet_catalog_biblio_enhancements_toolbar_button' 70 }); 71 72 my @tab_plugins = Koha::Plugins->new()->GetPlugins({ 73 method => 'intranet_catalog_biblio_tab', 74 }); 75 my @tabs; 76 foreach my $tab_plugin (@tab_plugins) { 77 my @biblio_tabs; 78 to add a new tab in opac-detail.pl result page -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |koha-bugs@lists.koha-commun | |ity.org Component|OPAC |Plugin architecture -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@libriotech.no -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #1 from Mark Hofstetter <koha@trust-box.at> --- see https://github.com/HKS3/koha-plugin-subordinate-items for a prove of concept implementation/why this makes sense for us -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- I'm not familiar with the plugin use on intranet/cgi-bin/catalogue/detail.pl, but would an alternative be to implement the plugin as an API route and then inject some Javascript into OpacUserJS to insert the tab? I suppose the annoying part of doing that is injecting the Javascript though... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki@biblibre.com, | |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #3 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- (In reply to David Cook from comment #2)
I'm not familiar with the plugin use on intranet/cgi-bin/catalogue/detail.pl, but would an alternative be to implement the plugin as an API route and then inject some Javascript into OpacUserJS to insert the tab?
I suppose the annoying part of doing that is injecting the Javascript though...
No need to inject, there is a plugin hook opac_js : https://github.com/bywatersolutions/dev-koha-plugin-kitchen-sink/blob/450b14... And hook opac_head for CSS -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #4 from Mark Hofstetter <koha@trust-box.at> --- OK I really like the idea to expose the data via an API route so would you change the opac-detail.tt file, or add the whole tab via the js? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Fridolin SOMERS from comment #3)
No need to inject, there is a plugin hook opac_js : https://github.com/bywatersolutions/dev-koha-plugin-kitchen-sink/blob/ 450b145a09c358b0dc3eaa0ee97151643c1bbda6/Koha/Plugin/Com/ByWaterSolutions/ KitchenSink.pm#L252
And hook opac_head for CSS
That's what I meant by inject, but thanks for providing those hooks. I was too lazy to look them up 😅. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #4)
OK I really like the idea to expose the data via an API route
so would you change the opac-detail.tt file, or add the whole tab via the js?
I would just add the whole tab via the JS. That way, you don't have to modify Koha at all, and all of your functionality is self-contained in the Koha Plugin. (I did send an email out yesterday that suggested the Koha Community modify opac-detail.pl (or an underlying library function) to allow Koha Plugins to modify the $template variable.) (Alternatively, it would be interesting to modify opac-detail.pl and opac-detail.tt to build the tabs using Javascript instead of Perl-generated HTML. But that's a separate development all together.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #7 from Mark Hofstetter <koha@trust-box.at> --- thanks so far, the idea seems to work but some minor and one major notes/questions_ + compared to a normal perl script which returns JSON (eg opac-ratings-ajax.pl) the API calls are extremly slow + using sub opac_js plugin hook puts the js on every page ... one major gotcha remains how do I access local script/template variables (like biblionumber) in the plugin hook modifying opac-details.tt directly I'm able to write $.ajax({ url: '/api/v1/contrib/subordinateitems/biblionumber/[% biblio.biblionumber | uri %]', but how to handle this in the opac_js thx Mark -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #8 from Mark Hofstetter <koha@trust-box.at> --- this solution is "fragile", is there any defined place where to find/extract the biblionumber var biblionumber = document. getElementsByClassName("unapi-id")[0]. getAttribute("title").split(':')[2]; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #7)
+ compared to a normal perl script which returns JSON (eg opac-ratings-ajax.pl) the API calls are extremly slow
Are you using CGI or PSGI/Plack for Koha? The REST API used by the plugins uses the Mojolicious framework; it should be fast for PSGI/Plack, but it would be extremely slow with CGI, as it would have to load and start code which expects to be in a persistent process.
+ using sub opac_js plugin hook puts the js on every page ...
Yeah, it's a bit suboptimal, but you can be smart with your Javascript to minimize the functional impact of that. For instance, only run the Javascript you want to run if a very page-specific condition is met. There is probably a body tag or class for the page you want which should make this easy.
one major gotcha remains
how do I access local script/template variables (like biblionumber) in the plugin hook
You don't. The plugin hook doesn't take any arguments. It's just used for fetching data from plugins and then printing it out on the template. That's an interesting idea though... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #7)
modifying opac-details.tt directly I'm able to write
$.ajax({ url: '/api/v1/contrib/subordinateitems/biblionumber/[% biblio.biblionumber | uri %]',
but how to handle this in the opac_js
(In reply to Mark Hofstetter from comment #8)
this solution is "fragile", is there any defined place where to find/extract the biblionumber
var biblionumber = document. getElementsByClassName("unapi-id")[0]. getAttribute("title").split(':')[2];
I think that the unapi-id that you found it probably your best bet, but that's a good point about there not being a great source of biblionumber on the detail page. I think there's an argument to be made for adding a data- attribute containing the biblionumber to the body on the detail page, or creating some kind of Javascript object via a template that provides access to the biblionumber. Or we could build on the RDFa data that we already have in the HTML and add an identifier (https://schema.org/identifier). I know that doesn't help you right now, but that would be a change that would be easy to make, get pushed, and backport. I'll open a Bugzilla issue report for it. I'd be curious to hear what Owen Leonard thinks is the best idea... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=27029 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- I think you could use the unapi-id for now, but if you want to test and sign off Bug 27029, it might be helpful to you in the long-run. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #12 from Mark Hofstetter <koha@trust-box.at> --- ok everything works now without touching koha-core, plz see https://github.com/HKS3/koha-plugin-subordinate-items/ thanks for the help, maybe close this bug, but a little more "plugability" would be great. I really do like the wordpress hook system - just pondering -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #12)
thanks for the help, maybe close this bug
Can do.
, but a little more "plugability" would be great. I really do like the wordpress hook system - just pondering
I'm not very familiar with the Wordpress hook system, but I think that's what originally inspired Kyle Hall to add Koha's plugin system. Feel free to suggest improvements to how Koha works. Even if you don't work on something, it might inspire someone else. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #12)
maybe close this bug
Actually, I think that I'll keep this bug open, as I think that it's a valid request. I just made my earlier comments as they provided a way of getting something working sooner rather than later. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #15 from Mark Hofstetter <koha@trust-box.at> --- just slept over it, and maybe I'm getting an idea about what feels wrong. The system is very explicit now, meaning you need a lot of code in specific places to use a plugin excactly "there" I think a plugin system needs to be more implicit eg all cgi scripts should use the same plugin hook(s) (with the name of the script as a config parameter whether the plugin should actually run) eg: plugin parameter rewrite add a parameter to all queries, or whenever a ISBN appears do a transformation + maybe could be doable by simply subclassing CGI + or better an more generalised, derive all cgi scripts from a common base class, wrap the code in a sub run {} and everthing becomes possible, this may sound huge but should be in fact only a few lines per script as I've said just thinking loud(ly) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #15)
The system is very explicit now, meaning you need a lot of code in specific places to use a plugin excactly "there"
I think a plugin system needs to be more implicit eg all cgi scripts should use the same plugin hook(s) (with the name of the script as a config parameter whether the plugin should actually run)
eg: plugin parameter rewrite add a parameter to all queries, or whenever a ISBN appears do a transformation
+ maybe could be doable by simply subclassing CGI
+ or better an more generalised, derive all cgi scripts from a common base class, wrap the code in a sub run {} and everthing becomes possible, this may sound huge but should be in fact only a few lines per script
With the Plack-enabled Koha, all the CGI scripts actually are loaded and wrapped, but I'm not sure how that would make everything possible. It would let you play with input/output, but that could be a bit fragile. There are some plugin hooks that are run for all CGI scripts, but I think that we could use a few more. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=27120, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=27114 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- After looking at Bug 27114 and Bug 27120, I reckon that it would be a good idea to get an "opac_catalog_biblio_tab" enhancement done. In fact, I just did a local customization recently which I could've done as a plugin instead, if an OPAC equivalent of those above bugs was completed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #18 from Mark Hofstetter <koha@trust-box.at> --- I still think plugabiltiy would be a good idea (even if it would be just for the sake of concistency) but thanks to all your advice I was able to to todo it in a plugin (https://github.com/HKS3/koha-plugin-subordinate-items) just create the tab with js -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to Mark Hofstetter from comment #18)
I still think plugabiltiy would be a good idea (even if it would be just for the sake of concistency)
but thanks to all your advice I was able to to todo it in a plugin (https://github.com/HKS3/koha-plugin-subordinate-items) just create the tab with js
I'm glad that I was able to help! While I used to be worried about UIs built with Javascript, I think a lot of accessibility tools have advanced to the point where it is OK now. And as a result I think that we should actually be moving more work client-side. (One of the advantages of moving things client-side is also that we can make more robust reusable APIs and make calls to the same API from different places in the system or even from other systems. Koha is a big system so I'd love to see less replication and more reuse.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber@kit.edu -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|opac-detail plugin like |Add opac_biblio_tab and |intranet/cgi-bin/catalogue/ |opac_biblio_enhancements_to |detail.pl |olbar_button hooks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #20 from Magnus Enger <magnus@libriotech.no> --- I have been thinking a bit about adding "things" to the OPAC in a flexible way. The idea I ended up with was something like this: Some JavaScript that can fetch "content" asynchronously from the REST API or some custom API/endpoint, so rendering the basic page is not slowed down by e.g. external APIs/datasources used for generating the extra content. The JS-call would tell the API what sort of page it is coming from: frontpage, results list, detail etc. The API/endpoint would call relevant plugins, gather data and return it. The returned data could identify different locations where it wants to be displayed, like "mainuserblock" for the front page, "tab" or "below the print/hold/etc links on the right side of the page" for detail view etc. Not sure if that makes sense. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 --- Comment #21 from Magnus Enger <magnus@libriotech.no> --- (In reply to Magnus Enger from comment #20)
I have been thinking a bit about adding "things" to the OPAC in a flexible way. The idea I ended up with was something like this:
Some JavaScript that can fetch "content" asynchronously from the REST API or some custom API/endpoint, so rendering the basic page is not slowed down by e.g. external APIs/datasources used for generating the extra content.
The JS-call would tell the API what sort of page it is coming from: frontpage, results list, detail etc.
The API/endpoint would call relevant plugins, gather data and return it.
The returned data could identify different locations where it wants to be displayed, like "mainuserblock" for the front page, "tab" or "below the print/hold/etc links on the right side of the page" for detail view etc.
Not sure if that makes sense.
A bit quick, there. I was thinking HTML would be generated server side and returned from the API/endpoint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org