This is the first step of the plan defined in Bug 10891 : storing facets configuration in YAML block. Next step : allowing librarians to edit this YAML bloc, either directly in a syspref, or in a specific page (still to be discussed).
Created attachment 21141 [details] [review] [PATCH] Bug 10892 : Make facets customizable - step 1 store configuration in YAML block This is the first of a group of patches whose goal is to make facets configurable. This patch stores facet configuration in a YAML block, within Koha.pm file. Next steps will be to use an external YAML file. No functional changes are expected, except for UNIMARC : I took the occasion for fixing location facets, which were broken (wrongly build on 995$c instead of 995$e). To test : 1. make some searches, use facets 2. apply 3. make the same searches, use facets the same way. No differences should be visible 4. in a UNIMARC Koha, check location facets are visible after applying the patch
Note : I have also made a separated bug for fixing UNIMARC location facets (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10893) This is because I am not sure my way for storing facets in YAML will be accepted, and maybe it will be only applied to version 3.14 of Koha and not to previous ones. So, the bug 10893 need to be signed off to. M. Saby
In fact, creating a new sql table for facets is maybe a more logical solution than using YAML. M. Saby
Translation alert: Facet labels are found in three locations: 1. facet definition 2. OPAC template opac-tmpl/prog/en/includes/opac-facets.inc 3. Intra template intranet-tmpl/prog/en/includes/facets.inc 2&3 are here to make facet labels translatable. In brief, adding a new facet implies now the following steps: - Edit facet data structure in Koha.pm - Add a new Zebra index if it not already exists - Edit both facet label definition templates
Yes, I know that. That's why I want to add some "standard" facet, based on existing zebra conf, which could be activated or not. It implies changing the 2 templates and the definition currently stored in Koha.pm. Once the configuration will be in YAML separate file, as libraries would be able to edit the YAML file (to change facet orders or fields used to build them), I suppose writing a patch for adding new facets could not be done cleanly just by git. I think we will need to run a little script that will read the existing YAML into perl data structure (array of hashes or hash of hashes), add new facet in this structure, and dump it into YAML file again. (The equivalent of operations made by updatedatabase for sql database) For "local use" facets defined by the library itself : - templates files won't know the name of these new facets - it won't work if it does not match zebra record.abs (we will need a warning for avoiding librarians to do mistakes) But this can be circumvented if YAML data for local use facets are not structured like the standard ones. For ex, something like : customfacet1: type: 'customfacet' idx: 'customindex' labels: en: 'Custom facet 1' fr-FR: 'Facette spéciale 1' tags: -210$b sep: ' - ' order:5 and code like that: - in facet configuration page : if (type = customfacet) { get all the list of the languages available in OPAC and Staff interface ask the librarian to define a label for each of these languages (for ex, "en" and "fr-FR") store it in labels->{en} and labels->{fr-FR} } - in template displaying facets in OPAC and Staff interface if (type = customfacet) { display labels->{current_language} } Do you think it will work? Mathieu
Patch applied cleanly, go forth and signoff
No need to consider this bug. I will use JSON for storing configuration of facets. M. Saby