Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In api_init there is code to add opensearch autodiscovery links to the HTML head. Here's a sample of the HTML output for the development version of drupalcontrib.org https://gist.github.com/psynaptic/5690532
As can be seen in the paste above, generating opensearch autodiscovery links for every branch and project combination doesn't scale well. Furthermore, I think in general users want to search by Drupal core major version and then navigate to different versions via the UI after the initial search.
api_opensearch (api/opensearch/%/%)
I think we should change this to search Drupal major versions (core compatibility field) using the preferred branch field in api_branch to help decide which object to return when there are duplicate identifiers. The user would still have the ability to navigate to different versions of the item in the UI.
api_suggest (api/suggest/%/%/%menu_tail)
This would need to change to support the changes to opensearch. It currently requires a project and branch combination to be specified but should probably just take core compatibility and filter on preferred branch.
Comments
Comment #1
jhodgdonThis is probably a good idea, but the URL api/opensearch/[compatibility] would then be printing out a very very very very large amount of output, so I'm not so sure it's really a good idea. How is this being used out there in the real world? Do we have an alternative to generating a really huge XML file containing everything in all projects for 7.x compatibility? I just don't know much about opensearch...
Comment #2
jhodgdonAlso, are we sure that people don't want to search within a particular project?
I totally agree that we shouldn't be putting auto-discovery links to each and every project/branch, as it doesn't scale. But maybe the right solution is to have a checkbox on the branch saying "Output this in opensearch autodiscovery" (default to FALSE), so as to limit which ones are out there, rather than to merge it all together.
The reason I think this is that I believe this opensearch stuff is used to make autocompletes (for instance in browser search, but maybe I am wrong). I don't think it's probably really all that useful to have an autocomplete that does absolutely everything across all 7.x projects if you have all of contrib there. Most of the time, wouldn't you know what project you want to search in anyway?
Comment #3
psynaptic CreditAttribution: psynaptic commentedThe way autodiscovery links work is that you have to add them for each link provided. So you'd have a huge list of options for each project and branch combination e.g. http://i.fs.io/1/Firefox-20130615-010734.png
Comment #4
ekes CreditAttribution: ekes commentedI've had api.drupal.org (and drupalcontrib) search added to my firefox search for ages. So one users take on this. Search per major drupal version makes the most sense to me. It's great for quick api lookups. 'd7 search_string' or 'd8 search_string' etc. (where d7 is my 'keyword' shortcut to the search). I can't see value in adding individual module versions to my search bar, it would take more time than making a search - not sure if there is a useful plug-in for such fine-grained multiple searches either; for anything more complicated I'd go to the code, or a craft a search.
Comment #5
jhodgdonOK, I'm convinced. :)
Comment #6
jhodgdonI took a look at doing this today.
The way OpenSearch works is basically this:
a) The site puts OpenSearch discovery links in the HTML header.
b) If someone requests one of those URLs, it should return a short name, description, search URL, and suggestions URL in a standard XML format.
c) Both search and suggestions URLs have placeholders for putting in the keywords for searching.
So, in order to make this work, we will first need to have a URL where you can search an entire core compatibility. We don't have that currently.
The suggestions URL is already defined in api.module, and since that is specific to OpenSearch, that can easily be modified to be across core compatibilities, instead of per-project/branch as it is now.
Comment #7
jhodgdonProbably we can use #1788240: Advanced search to do the search, so I'll postpone this issue on that one.
Comment #8
jhodgdonActually, since I just fixed #2008540: Make the apis/% callback search more branches so that it effectively searches the entire site, I think maybe the best thing to do here would be to just have the OpenSearch links return one overall discovery link, which would search the entire site using the apis/(search term) path.
Thoughts?
Comment #9
psynaptic CreditAttribution: psynaptic commentedThat sounds great. It saves people having to switch versions in their search box.
Comment #10
jhodgdonOK, if both of us like it, it's probably a good idea. :) No reason to postpone in that case.
Comment #11
jhodgdonWorking on this one.
Comment #12
jhodgdonCommitted a fix for this to 7.x-dev.
Changes: only 1 OpenSearch discovery link is put into the HTML header. The search URL is now apis/(term) and suggestions URL no longer has the branch/project in the URL.