Description
Katrin Fischer
2014-03-25 12:09:27 UTC
The URL to the favicon could be taken from Koha's system preferences as well: <Image height="16" width="16" type="image/x-icon">http://example.com/favicon.ico</Image> This feature was working in Koha a long time ago, and the basic building blocks are still there. Updating the bug title to reflect that this will be a bug fix. Created attachment 103866 [details] [review] Bug 11994: Fix OpenSearch discovery in the OPAC This patch corrects the markup for the OpenSearchDescription XML document and adds (back) the link in the OPAC header which points to it. This will enable compatible browsers to offer the addition of the OPAC's keyword search as a search engine option. I've found documentation suggesting this feature is available (or at least was at one time) in Chrome and Safari, but in my test it only works in Firefox. To test, apply the patch and make sure the OPACBaseURL preference is set correctly. - Open the OPAC in Firefox (these instructions assume the latest version, currently v.75). - On the right side of the address bar you should see ". . ." Click it to trigger the menu. - You should see an "Add search engine" entry with your OPAC's icon. - Click to add the search engine. - Type a keyword to search in the address bar - A box should pop up below the address bar showing icons at the bottom for performing a search in various search engines. One of these icons should be the icon for your Koha OPAC. - Click the Koha OPAC icon and confirm that it triggers a keyword search in your OPAC. Created attachment 103873 [details]
Screenshot showing menu for adding search engine in Firefox
Created attachment 103874 [details]
Screenshot showing option to search in Koha (Firefox)
Hi Owen. I've had a couple of attempts at testing this, but get this message when trying to add: Firefox could not download the search plugin from: http://kohadev.mydnsname.org:8080/cgi-bin/koha/opac-search.pl?format=opensearchdescription OPACBaseURL is set to http://kohadev.mydnsname.org:8080 - I think this is correct. Here is the XML delivered when I look at the source for the URL in the error message above: <?xml version='1.0' encoding='utf-8' ?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"> <ShortName></ShortName> <Description>Search the Koha library catalog</Description> <InputEncoding>UTF-8</InputEncoding> <Image width="16" height="16" type="image/x-icon"> http://kohadev.myDNSname.org:8080/opac-tmpl/bootstrap/images/favicon.ico </Image> <Url method="get" type="text/html" template="http://kohadev.myDNSname.org:8080/cgi-bin/koha/opac-search.pl?q={searchTerms}" /> <Query role="example" searchTerms="cat" /> </OpenSearchDescription> The OpacBaseURl like this never works for me - I always have to change it to localhost:8080 (kohadevbox) Thanks Katrin! Unfortunately, the error still happens after making that change 8-( I have the same issue as David, maybe opensearchdescription is not declared? I couldn't spot where this is set. Maybe a change missing from the patch set? Trying to figure out where the issue could be: ShortName A short name for the search engine. It must be 16 or fewer characters of plain text, with no HTML or other markup. => We might have a longer library name easily, maybe we need to shorten it automatically if longer? Or have a default fallback text. Or it could be this: Your server should serve OpenSearch plugins using Content-Type: application/opensearchdescription+xml. ? Created attachment 104132 [details] [review] Bug 11994: Attempt to fix Content-Type Not working yet... Glad it just wasn't me. Found this resource useful, and it mentions the error as well: https://developer.mozilla.org/en-US/docs/Web/OpenSearch Created attachment 104133 [details] [review] Bug 11994: Fix OpenSearch discovery in the OPAC This patch corrects the markup for the OpenSearchDescription XML document and adds (back) the link in the OPAC header which points to it. This will enable compatible browsers to offer the addition of the OPAC's keyword search as a search engine option. I've found documentation suggesting this feature is available (or at least was at one time) in Chrome and Safari, but in my test it only works in Firefox. To test, apply the patch and make sure the OPACBaseURL preference is set correctly. - Open the OPAC in Firefox (these instructions assume the latest version, currently v.75). - On the right side of the address bar you should see ". . ." Click it to trigger the menu. - You should see an "Add search engine" entry with your OPAC's icon. - Click to add the search engine. - Type a keyword to search in the address bar - A box should pop up below the address bar showing icons at the bottom for performing a search in various search engines. One of these icons should be the icon for your Koha OPAC. - Click the Koha OPAC icon and confirm that it triggers a keyword search in your OPAC. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 104134 [details] [review] Bug 11994: OpenSearch plugins needs to be delivered with Content-Type application/opensearchdescription+xml https://developer.mozilla.org/en-US/docs/Web/OpenSearch Your server should serve OpenSearch plugins using Content-Type: application/opensearchdescription+xml. To test: - Verify the Content-Type the file is delivered with is correct, for example using wget http://127.0.0.1:8080/cgi-bin/koha/opac-search.pl?format=opensearchdescription Created attachment 104135 [details] [review] Bug 11994: (follow-up) Make things work when LibraryName is empty When LibraryName system preference was not set, the installation of the plugin would fail with: Firefox could not download the search plugin from: ... Now if the pref is empty, the description 'Library catalog' will be used instead. To test: - Empty your LibraryName pref - Verify the search plugin can still be installed (see first patch for further instructions) I couldn't let this go... and I finally figured it out! ... It would fial when LibraryName is not set. I also cleaned up the patch for Content-Type. While it seems to work without, I think we would be on the safer side to do it correctly. That's awesome Katrin, thank you for your perseverance! I'm getting something weird when applying the patch and trying to sign off. There are four patches listed in the bug, bit git log only shows three. Does that mean patch 104132 - Bug 11994: Attempt to fix Content-Type can be obsoleted? This is what I get when applying the patch: root@b23fad95e500:koha(master)$ git bz apply 11994 Bug 11994 - Fix OpenSearch discovery in the OPAC 104132 - Bug 11994: Attempt to fix Content-Type 104133 - Bug 11994: Fix OpenSearch discovery in the OPAC 104134 - Bug 11994: OpenSearch plugins needs to be delivered with Content-Type application/opensearchdescription+xml 104135 - Bug 11994: (follow-up) Make things work when LibraryName is empty Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 11994: Attempt to fix Content-Type Applying: Bug 11994: Fix OpenSearch discovery in the OPAC Applying: Bug 11994: OpenSearch plugins needs to be delivered with Content-Type application/opensearchdescription+xml Using index info to reconstruct a base tree... M C4/Output.pm M opac/opac-search.pl Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: Bug 11994: (follow-up) Make things work when LibraryName is empty Sorry, yes, one patch was obsolete, fixed now! Created attachment 104138 [details] [review] Bug 11994: Fix OpenSearch discovery in the OPAC This patch corrects the markup for the OpenSearchDescription XML document and adds (back) the link in the OPAC header which points to it. This will enable compatible browsers to offer the addition of the OPAC's keyword search as a search engine option. I've found documentation suggesting this feature is available (or at least was at one time) in Chrome and Safari, but in my test it only works in Firefox. To test, apply the patch and make sure the OPACBaseURL preference is set correctly. - Open the OPAC in Firefox (these instructions assume the latest version, currently v.75). - On the right side of the address bar you should see ". . ." Click it to trigger the menu. - You should see an "Add search engine" entry with your OPAC's icon. - Click to add the search engine. - Type a keyword to search in the address bar - A box should pop up below the address bar showing icons at the bottom for performing a search in various search engines. One of these icons should be the icon for your Koha OPAC. - Click the Koha OPAC icon and confirm that it triggers a keyword search in your OPAC. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: David Nind <david@davidnind.com> Created attachment 104139 [details] [review] Bug 11994: OpenSearch plugins needs to be delivered with Content-Type application/opensearchdescription+xml https://developer.mozilla.org/en-US/docs/Web/OpenSearch Your server should serve OpenSearch plugins using Content-Type: application/opensearchdescription+xml. To test: - Verify the Content-Type the file is delivered with is correct, for example using wget http://127.0.0.1:8080/cgi-bin/koha/opac-search.pl?format=opensearchdescription Signed-off-by: David Nind <david@davidnind.com> Created attachment 104140 [details] [review] Bug 11994: (follow-up) Make things work when LibraryName is empty When LibraryName system preference was not set, the installation of the plugin would fail with: Firefox could not download the search plugin from: ... Now if the pref is empty, the description 'Library catalog' will be used instead. To test: - Empty your LibraryName pref - Verify the search plugin can still be installed (see first patch for further instructions) Signed-off-by: David Nind <david@davidnind.com> Created attachment 106092 [details] [review] Bug 11994: Fix OpenSearch discovery in the OPAC This patch corrects the markup for the OpenSearchDescription XML document and adds (back) the link in the OPAC header which points to it. This will enable compatible browsers to offer the addition of the OPAC's keyword search as a search engine option. I've found documentation suggesting this feature is available (or at least was at one time) in Chrome and Safari, but in my test it only works in Firefox. To test, apply the patch and make sure the OPACBaseURL preference is set correctly. - Open the OPAC in Firefox (these instructions assume the latest version, currently v.75). - On the right side of the address bar you should see ". . ." Click it to trigger the menu. - You should see an "Add search engine" entry with your OPAC's icon. - Click to add the search engine. - Type a keyword to search in the address bar - A box should pop up below the address bar showing icons at the bottom for performing a search in various search engines. One of these icons should be the icon for your Koha OPAC. - Click the Koha OPAC icon and confirm that it triggers a keyword search in your OPAC. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 106093 [details] [review] Bug 11994: OpenSearch plugins needs to be delivered with Content-Type application/opensearchdescription+xml https://developer.mozilla.org/en-US/docs/Web/OpenSearch Your server should serve OpenSearch plugins using Content-Type: application/opensearchdescription+xml. To test: - Verify the Content-Type the file is delivered with is correct, for example using wget http://127.0.0.1:8080/cgi-bin/koha/opac-search.pl?format=opensearchdescription Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 106094 [details] [review] Bug 11994: (follow-up) Make things work when LibraryName is empty When LibraryName system preference was not set, the installation of the plugin would fail with: Firefox could not download the search plugin from: ... Now if the pref is empty, the description 'Library catalog' will be used instead. To test: - Empty your LibraryName pref - Verify the search plugin can still be installed (see first patch for further instructions) Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Works as expected, no regressions.. Passing QA Pushed to master for 20.11, thanks to everybody involved! backported to 20.05.x for 20.05.02 backported to 19.11.x for 19.11.08 Backported to 19.05.x branch for 19.05.14 |