Unify Page/search arguments across all viewers + Mirador Search and Canvas ID redirect

[DiegoPino]

What?

Right now for the internal Page/book searches we are doing this

<h5>
{% set query = drupal_token('current-page:query:page_text')|trim %}
{% if query is not empty and query != '[current-page:query:page_text]' %}
<a href="{{ path('entity.node.canonical', {'node': parent_id}) }}#page/{{ sequence_id_int }}/mode/2up /search/{{ query }}">{{ sbf_label }}</a>
{% else %}
<a href="{{ path('entity.node.canonical', {'node': parent_id}) }}#page/{{ sequence_id_int }}/mode/2up ">{{ sbf_label }}</a>
{% endif %}
</h5>

But only IABookreader understands page/{{ sequence_id_int }}/mode/2up
What we want is that all search across any viewer in Archipelago uses the same URL Arguments
page?
seach?
and then each Viewer JS implementation transforms it internally into its own needed format

This also connects with @alliomeria suggestion of using store.dispatch in mirador:

see:
https://stackoverflow.com/questions/62752053/mirador-3-jump-to-page-set-page-set-canvas
and
https://github.com/ProjectMirador/mirador/wiki/M3---Mirador-3-Frequently-Asked-Questions#q-how-do-i-programmatically-set-the-canvas

There are a few issues here we need to address:

• For Mirador search to work we need to finish the IIIF V3 Search API endpoint, see ISSUE-248: backend (metadata display) driven Search for OCR #252
• When we have multiple hits, we don't know if they did match Metadata OR OCR. That is the (reason why I did not build this before) the issue I have with bringing OCR back into the parent nodes. So what I could do is:
  • IF there is hit, then do again a search (double search, slower) against all OCR pages for that ADO (means we know it will contain it but we don't know yet where) and we show a BLOCK with all hits per page inside the results for an ADO. Basically what we already do on the Page/Book search but inside an ADO (gosh)
  • OR we blindly redirect to the Object not with the Page that hit (also we don't know how many pages hit right?) but with the search string and hope for the best?

@alliomeria @aksm @giancarlobi ideas?

@MarthaTenney, @cristydanford, @elanaalt and @mkrkelj1 bc your repo will have to deal with the incognito question of Metadata v/s OCR when calling the highlight!

[DiegoPino]

Tagging @MarthaTenney, @cristydanford, @elanaalt and @mkrkelj1 because this drives some of the needs. Specially attention to the fact that because of the new aggregation feature when there is a hit, discerning if the hit was on the metadata or OCR or both and if OCR which pages its was is very hard to distinguish. But we can still do mixed approaches (as explained) or pass the search query itself into the link and let the ADO itself deal with the highlight once it gets the Search URL argument

[DiegoPino]

Yet another feature that might come from this:

• Since we don't know where the hit was (and it might be on both sides/OCR and Metadata) on each ADO we can also run something like this

// Retrieve and explode URL
var urlParts = window.location.href.split("?");
if (urlParts.length == 2)
{
    $("p:contains('" + urlParts[1] + "')").each(function(index, pElement) {

        var PElementJQ = $(pElement);
        PElementJQ.html(PElementJQ.html().replace(urlParts[1], '<span class="highlight">' + urlParts[1] + '</span>'));

    });
}