Answered

Adding fields to searchindex.results or improving search in metafilter search

(0) Share

Report

Posted on by Community Power Pla... Microsoft Employee

Hi all,

I'm trying to improve the view for our organisation in the portal search results, but am running into some problems.

It appears that I can't add entity fields in the handlebars of faceted search due to the evaluation of the {%raw%} tags (various discussions online) and I'm reluctant to use a script solution that will be making multiple calls onload.

I tried building a new results page using liquid only based on the text at https://community.adxstudio.com/products/adxstudio-portals/documentation/configuration-guide/liquid-templates/objects/searchindex/

Unfortunately this doesn't work as it doesn't even pull back the {{ result.fragment }} text. Therefore, everything else I've tried to do maybe my error, but maybe something underlying.

I can create a page that looks right using metafilter search but the search:params.search will only work on single word search strings (even when the words are a connected string in the field).

From a visual point of view, improving the metafilter search would be best, but I'm not sure that's possible.

Any help gratefully received

Thanks

Ralph

Categories:

Power Apps portals

I have the same question (0)

All responses (6)

Answers (1)

justinburch Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Hi @Anonymous,
I went through a similar deep-dive a few years ago into all of the handlebars formatting, custom search result nonsense, including digging into the community released source code (which explicitly states in comments there that no additional fields will be used in faceted search, but I've heard they're looking to improve faceted search - maybe they have already, it's been awhile?).
One recommendation is to use the Microsoft Docs over Adoxio ones (they've been updated well the past few years), where you'll find they mention the fragment will be null for "fuzzy"/wildcard searches. Are you using these at all?
I don't think the {%raw%} tag is your issue - you could always end it where you need to switch between handlebars and Liquid, as Liquid will always be processed server-side and handlerbars client-side - e.g. {%raw%} {{ /*handlebars code here {%endraw%}{% comment %}mixed with Liquid{% endcomment %}{% raw%} */ }} {% endraw %}
Instead, I think the issue is in the strict control of the source code that sends very specific data (via the API endpoint the handlebars format off of).
Use Liquid objects for a portal - Power Apps | Microsoft Docs

I hope this helps!

Was this reply helpful? Yes No
Community Power Pla... Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Thanks @justinburch
I think you may be right on the handlebars (and it definitely hasn't extended in faceted search). You're also right about using MS docs over Adoxio (I was being lazy) but the same script is here: https://docs.microsoft.com/en-us/powerapps/maker/portals/liquid/liquid-objects#searchindex
You're also right (three in a row) about the fuzzy/wild but the same search criteria using the same search function, just redirecting the page, brings back a fragment in faceted search, so there must be something going wrong here. The only thing I can think of is the CSS (ours replaced the Bootstrap - I know this is bad and I advised against it and it causes no end of problems), but there's nothing obvious I can see there either. If I could get the fragment, I would be confident that any other issues were my own.

Thanks though - means I can rule out some of the issues if not all...

Ralph

Was this reply helpful? Yes No
justinburch Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

No worries @Anonymous, happy to provide some reassurance at least. The good news is that I believe improving the faceted search is on the roadmap - but now I may be confusing that with search in general, which was previously/currently? super limited on which entities could be searched.. 🤐
I don't think the CSS of the bootstrap would play much of a role (outside of potentially breaking your formatting/fluidity if not still using some form of bootstrap to control screensizing), so don't worry too much about that!
I think it's likely (if I'm understanding correctly) that liquid versions of searchindex.fragment are limited, but the Portal built-in searching (which, again, uses server-side code) can handle the fuzzy/wildcard searches.
My suggestion to be sure would be to revert to a super-simple search/lucerne setup, and test your custom searchindex.fragment with that. If that also doesn't work, it might be best to open a support ticket.

I hope this also helps some. It's been some time since I've worked with customizing search, so some of the other users here might be able to provide more direction/workarounds when they check out the post.

Was this reply helpful? Yes No
Bill Ramz 2 on at

Like (0)

Report
Copy link

Link copied!

The below code does not return any fragments...How can I return fragments?

{% searchindex query: 'support', page: params.page, page_size: 10 %} {% if searchindex.results.size > 0 %} <p>Found about {{ searchindex.approximate_total_hits }} matches:</p> <ul> {% for result in searchindex.results %} <li> <h3><a href={{ result.url | escape }}>{{ result.title | escape }}</a></h3> <p>{{ result.fragment }}</p> </li> {% endfor %} </ul> {% else %} <p>Your query returned no results.</p> {% endif %} {% endsearchindex %}

Thank you,

Bill

Was this reply helpful? Yes No
Community Power Pla... Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

Sorry @BillRamz I've not got that example working yet. However, @justinburch I've moved on slightly by mixing the search function with entity view to render results that are more functional for us (no fragments but we can live with that). There remains one small problem:
The url query path generated from the search function is "/?q=term1+term2" but in the rendered list that only brings back results as "term1 term2" not "term1" OR "term2".

Manually changing the plus (+) for ampersand (&) in the url - "/?q=term1&term2" - works absolutely fine.

I'm sure there's something obvious but I can't find an obvious way to change the operator generated in the url, or to render the results from a query using plus(+).

Sorry to throw this out there again, but any ideas? I'm so close, and yet without this final step it still doesn't work...

Cheers
Ralph

Was this reply helpful? Yes No
Verified answer

justinburch Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!

Hi @Anonymous,
Changing the URL with an ampersand should actually create a new parameter - turning "/q=term1+term2" into "/q=term1&term2=(null)", if that makes sense. This should theoretically mean the search is only looking for term1, so I'm curious why it's working. For the actual Lucene search, you can use "AND" (q=term1+AND+term2) and "OR" (q=term1+OR+term2), but I think I would need to understand how you set up your search query to help more (some places "+" and "&" are AND - but + is also "space" in the URL directly, with | as OR, but global search isn't supposed to support these characters).
poc&profilepoc AND profilepoc OR profile

Was this reply helpful? Yes No