SuttaCentral Search Bugs 🪰

[Dana]

When I search for suttas your software quite often fails to find them, but I know they are there. For example, i entered “Discourse on the Ten Dhammas. Dasadhamma sutta”.

[REddison]

@Dana

For example, i entered “Discourse on the Ten Dhammas. Dasadhamma sutta”.

In monastic chanting books some suttas go by a different name from that which they have in the Tipiṭaka.

The AN’s Dasadhammasutta is one example. In the Tipiṭaka it’s called either the Pabbajitaabhiṇhasutta or the Abhiṇhapaccavekkhaṇadhammasutta.

[sujato]

@REddison

AN’s Dasadhammasutta is one example. In the Tipiṭaka it’s called either the Pabbajitaabhiṇhasutta or the Abhiṇhapaccavekkhaṇadhammasutta.

Indeed yes. What I’d like to do is assemble a list of aliasses so we can create appropriate search results, eg. for the Metta Sutta, another big one.

@Dana

i entered “Discourse on the Ten Dhammas. Dasadhamma sutta”.

In this case, a web search for dasadhammasutta returns Access to Insight, where this sutta is listed as AN 10.48. You can then enter that number on SuttaCentral.

[Snowbird]

@Dana

For example, i entered “Discourse on the Ten Dhammas. Dasadhamma sutta”.

In general, that’s too many words for a search. If you know the Pali, just search for that. In general. It wouldn’t have helped in this case. Words like “discourse” “ten” and “Dhammas” are too common to be useful when searching.

[Pasanna]

@sujato

What I’d like to do is assemble a list of aliasses so we can create appropriate search results, eg. for the Metta Sutta, another big one

I don’t know how I would go about this task, but I’m happy to have a discussion about it and take it from there.

[Jhanarato]

You would edit this file:

additional-info/alias.json

It is rather short at the moment!

[Pasanna]

I just did a wildcard search which took quite a while (the first time I did it)

aṇḍ*

While searching the orange context_toolbar displayed

SuttaCentral — Search results

then
0 search:resultsFor aṇḍ*

then
9265 results for aṇḍ*

Once some form of browser caching has happened, step 2 doesn’t happen. I first experienced this in Saf, but had to reproduce it by searching in FF.

The faults in step two are both the search:search in the (black) breadcrumb bar and the wonky-donk search:resultsFor in the context_toolbar

[Snowbird]

I’m not sure what is going on.

However I have long noticed that immediately the page displays 0 results and then later updates. This is wrong. If you are running a local version of the site maybe it’s not there long enough to matter. But it should not work like that.

Thoughts @agilgur5 ?

[Pasanna]

Also, wildcard searching doesn’t work (consistently)

[Snowbird]

Sorry, I missed that.

I don’t think we support wild card searching at all, do we? Probably that * is just getting ignored.

We do have the partial match toggle.

However for strings as small as the one you are searching for, it’s going to be really difficult. Especially if the diacritics are being ignored.

Personally I use the DPR for Pali searching.

[Pasanna]

@Snowbird

I don’t think we support wild card searching at all, do we? Probably that * is just getting ignored.

Even sadder. Especially in a language with so much declention.

@Snowbird

However for strings as small as the one you are searching for, it’s going to be really difficult.

I moved on to searching longer terms!

@Snowbird

Personally I use the DPR for Pali searching.

https://thebuddhaswords.net/ is still my go to for search. It’s just a tiny little .js file but it does a pretty good job, minus the diacritics.

[agilgur5]

@Pasanna

search:resultsFor

That appears to be the localization key, I think bugging out around this bit of code.
EDIT: I’m pretty sure it’s the extra whitespace causing that key to not be interpreted correctly, as the localize function doesn’t trim it
EDIT2: Nope, not quite. The problem is that the localization isn’t loading until after the search request finishes, and applies to the one below too. I suspect that may be due to the until directive, see some analysis in the PR where I refactored this (while attempting to fix it).

@Pasanna

search:search

probably ditto for this bit
EDIT: this one is weirder, it only appears in one place that seems to be correct and has an old bug report too
EDIT2: see “EDIT2” in the above section

@Snowbird

However I have long noticed that immediately the page displays 0 results and then later updates. This is wrong.

@Snowbird

Thoughts @agilgur5 ?

That seems like a simple case of the number being reset when the query starts. To not have confusing display, it should say something like “Searching…” instead, specifically when the request is in-flight

[Jhanarato]

@Pasanna

I just did a wildcard search which took quite a while (the first time I did it)

aṇḍ*

It’s quite possible that the search back end is stripping the diacritics, leaving the english word and.

[Pasanna]

The layout on the search page is extremely wonky-donk and somebody has gone and made it worse by hacking styles into the html of several key layout divs. Can you hear the devas sobbing?

It is particularly bad on mobile but not great on desktop.

So I did what any person who had too much caffeine would do and got stuck in to the css.

<div class="all-search-results" style="/*! flex-direction: row; */"> 

<section class="additional-search-results" style="/*! max-width: 40%; */">

Both of these need their hardcoded style removed.

All of the following classes need updating.
If SC actually used stylesheets in normal ways I would have been happy to provide a new stylesheet.

@media (max-width: 780px) {
  .all-search-results {
    flex-direction: column-reverse;
    gap: var(--sc-size-xl);
  }
  .primary-search-results {
    max-width: 100%;
    width: 100%;
  }
  .additional-search-results {
    max-width: 100%;
    width: 100%;
  }
}

@media (max-width: 600px) {
  .sutta-info {
    display: flex;
    flex-direction: column;
  }
  .sutta-title {
    flex-direction: column;
  }
  dictionary + .suttaplex {
  margin-top: var(--sc-size-xs);
}
}

.search-results-main {
  max-width: 1440px;
  margin: 0px auto;
  padding-bottom: 64px;
  width: 90vw;
}


.all-search-results {
  display: flex;
  flex-direction: row;
  gap: var(--sc-size-xl);
}
  .additional-search-results {
    max-width: 40%;
  }


.search-result-head, .primary-search-results {
  display: flex;
  flex-direction: column;
  max-width: 720px;
  min-width: 40%;
  flex-grow: 2;
}
.search-result-item {
  border-bottom: var(--sc-border);
  display:flex;
  flex-direction:column;
}
.item-head {
  display: flex;
  justify-content: space-between;
  flex-direction: row;
  max-width:100%;
}
.primary {
  display: flex;
  flex-flow: nowrap;
  justify-content: space-between;
  align-items: center;
  min-height: 32px;
}
.sutta-info{
  width:calc(100% - 70px);
  flex-direction:column;
  display:flex;
}

.search-result-action-items {
  display: flex;
  align-items: center;
  flex-direction: row;
  width: 40px;
}

.search-result-title {
  font-family: var(--sc-serif-font);
  font-weight: 400;
  font-size: var(--sc-font-size-xl);
  margin: 0px;
  color: var(--sc-primary-color);
  display: flex;
  align-items: center;
}

.badges {
  display: flex;
  margin-left: 0.3em;
  margin-bottom: 0.5em;
  width:150px;
}

[agilgur5]

@Pasanna

The layout on the search page is extremely wonky-donk

I agree, it can overlap weirdly on different screen sizes.
Multi-column also feels a bit unintuitive to me as search pages are mostly single column these days.

@Pasanna

Both of these need their hardcoded style removed.

They appear to be set in JavaScript conditionally in this function. Could have JS set conditional CSS classes instead

@Pasanna

If SC actually used stylesheets in normal ways I would have been happy to provide a new stylesheet.

Bhante Sujato likes to follow web standards and features. Shadow DOM is a browser feature for encapsulation so that things like styles don’t leak across components. Web Components typically use it.
I’ve used React components since the early days of ~2014 and still like CSS modules, but those all have hashes and such, so not so easy to edit either. Pros and cons of different approaches and such.

Anyway, the search styles are mostly in this file

[Pasanna]

@agilgur5

They appear to be set in JavaScript conditionally in this function. Could have JS set conditional CSS classes instead

Thanks for highlighting this. Now I understand the thinking, though I don’t agree with it (more on that later).

More importantly, I found a bug

searching title: rahula returns

Search format error

filter "title:" Missing Values

Whereas title:rahula works.

Can we strip any space that comes between the colon and the first character?

[Pasanna]

@agilgur5

I agree, it can overlap weirdly on different screen sizes.
Multi-column also feels a bit unintuitive to me as search pages are mostly single column these days.

I totally agree with this. I think it’s fine to serve multi column search results for medium and large screens but we need to make some decisions about how to handle things on xs and s devices (phone sized).

There are definite issues in the .search-results-item regardless of single or multi column layouts which I will look at in github, but shall we start a new conversation about search multi-column layout so as to not derail the bug thread?

[Pasanna]

I’m not sure if this is a bug or not. Maybe I don’t understand what ‘match partial’ does.

If I search rahula with match partial on. The orange bar tells me that there are 502 results.

In the primary-search-results column I see one lonely result.

Chapter Three
Root language: Pāli aligned
AN 1.209–218 Tatiyavagga — English — Bhikkhu Sujato

Then a ‘load more’ button. Which doesn’t do anything.

Followed by a whole lot of white space

Then in the additional-search-results column I have Rahula’s dictionary entry (which is quite long) and way down scrolling-scrolling there are 18 suttaplex cards,

By my maths that’s 19 results plus a dictionary entry.

---

When I search un-partially(?)

I get 116 results

The additional-search-results column contains the same dictionary entry plus 18 suttaplex cards.

The primary-search-results column leads with the same AN1 Chapter 3 entry and then is followed by another 19 Suttas,

Then a ‘load more’ button, which gives me 20 or so more suttas and the option to load another 20 or so.

All these entries have the entire word Rāhula in them, some more than once.

It seems like I am getting less ‘clickable’ results from a partial search than an un-partial one.

Is this right?

(I’m just searching Rahula as a test, because it (should) returm a whole lot of results).

[Pasanna]

I have moved discussion about search layout to a new thread

Discussion on search page layout/design

As discussed in the search bugs thread, the search layout is wonky and confusing. The problem A lot of the wonkiness comes from there being no boundaries on the search-results-item section. I’m about to submit some fixes on this area to help contain the results in their column. In the process of figuring out how everything existed I drew a wireframe. It’s SVG. Do with it as you like! Everything in this component appears in both desktop and handheld This is just a close-up of the search-resul…