Able to retrieve properties of a search result object

[TSP]

Hi, 

Could you let us be able to retrieve the values of the Search result object? I'm thinking about system/Content/Search/Results.php (I think)

I'm currently writing a very simple endpoint (outside of the API) to be able to return some search results with json. This is so another page we have can then use this "API" to query for some search results to display in their own manner.

Currently I have a hacky workaround:

<?php
/* Initialize IPS 4 framework */
require_once('../init.php');
$disp = \IPS\Dispatcher\Front::i();

/* Do we have anything to search for? */
if( ! isset( \IPS\Request::i()->q ) and ! isset( \IPS\Request::i()->tags ) )
{
    echo "Please supply both a term and tag to search for";
    exit;
}

/* Search for content matching term and tags */
$query = \IPS\Content\Search\Query::init();
$query->setOrder( \IPS\Content\Search\Query::ORDER_RELEVANCY );
$flags = \IPS\Content\Search\Query::TERM_AND_TAGS;
$timers[] = array('start' => microtime( true ), 'desc' => 'Before search query and processing topic results');

$results = $query->search(
    isset( \IPS\Request::i()->q ) ? ( \IPS\Request::i()->q ) : NULL,
    isset( \IPS\Request::i()->tags ) ? explode( ',', \IPS\Request::i()->tags ) : NULL,
    $flags + \IPS\Content\Search\Query::TAGS_MATCH_ITEMS_ONLY
);

$topics = array();

foreach( $results as $result )
{
    /* I seem unable to retrieve the topic ID in a sensible manner :( (Unless I make a plugin which I can't be bothered to do) */
    $array = (array) $result;
    $prefix = chr(0).'*'.chr(0);
    $indexData = $array[$prefix . 'indexData'];
    $topics[ $indexData['index_item_id'] ] = \IPS\forums\Topic::load( $indexData['index_item_id'] );
}
# ... more code further below not included in snippet, 
# it uses the topic ids it gathers in some additional queries below 
# where it searches for forum posts posted by members in a specific group in those topics

Basically I'm not able to do for example: $result->index_item_id. 

Do you see my dirty hack? 

I technically *could* write a plugin probably to overwrite this method and create some method myself, but I personally find that it should just be available for us to do. Thus why I'm creating this suggestion. 

Or am I missing some obvious way in which I'm able to retrieve these values from the result object normally? I looked in the templates, but in the templates it simply does: {$result->html()|raw} Which is not something I can work with, unless I want to parse the HTML returned to look for the topic id...

[bfarber]

Personally for right now, I recommend simply creating the plugin. This isn't something we have a direct need for or that I think would open up the system greatly to other authors at this time.

All you would need to do is override system/Content/Search/Result/Content.php and make all of the properties public instead of protected, at which point you could just access the properties of each result directly. Or add a method to the class to return the value stored in the protected property. It would only be a few lines of code.

[TSP]

51 minutes ago, bfarber said:

Personally for right now, I recommend simply creating the plugin. This isn't something we have a direct need for or that I think would open up the system greatly to other authors at this time.

I have spoken with other third-party developers that support this suggestion. One of them even said he mentioned it before. If you're only going to make changes that are useful for yourself, then why even ask for suggestions like this?

I'll just keep my dirty work-around then. 

51 minutes ago, bfarber said:

All you would need to do is override system/Content/Search/Result/Content.php and make all of the properties public instead of protected, at which point you could just access the properties of each result directly. Or add a method to the class to return the value stored in the protected property.

I know how I would do it. But having to make a plugin for something like this feels obnoxious and takes me more time to do for a method that feels it would natural for me to be able to access. 

51 minutes ago, bfarber said:

It would only be a few lines of code.

In comparison, all I'm asking of you is to change a word. To make this kind of thing easier for both myself and other third-party developers in the future. 

[bfarber]

I apologize if I have offended - I was simply trying to let you know my current recommendations. I have raised this internally for discussions, but in the mean time I do recommend using a plugin to achieve what you need.

[Flitterkill]

Slight related bump.

Throwing a search term at the REST API and getting the first five results or something like that returned.

Yes. Please.

[bfarber]

So you are requesting an API endpoint to perform searches over REST, essentially. Is that right?

[Flitterkill]

On 10/31/2016 at 8:54 AM, bfarber said:

So you are requesting an API endpoint to perform searches over REST, essentially. Is that right?

Oh yes. Please Please Please.

Use case: Slack/RocketChat/Discord bots. With that search api enabled we can get some seriously fun interaction going on. My specific use case is searching a Pages db while in RocketChat.

- Hey, remember that question about the boat on an english river?
- No, let's find it quick.
- !bot search questions english river
<api gets hit, returns links to the first (let's have this set in the api to determine how many get thrown back - that is the api REST request can send alongside the search term and content type - all, forums, pages db, gallery, etc. the number of requests it wants back, 1 to 5 should do it) hits>
<results pushed back into the chat, formatted as embeds or however I want them to look, linked of course>
- Yeah, that's the one...

and so on...

Related: Are we getting fields beyond Title and Content flagged fields in Pages db's searchable anytime soon? Just put a toggle on the page db text fields for searchable/not searchable and append the text from them if toggled on into the search db entry for the record. It's all the same pile anyways.

[bfarber]

I've raised your suggestion internally for further discussion, thanks.

I can't make any promises on pages fields being searchable.

[Tres]

On 2016. 10. 3. at 7:36 PM, bfarber said:

Personally for right now, I recommend simply creating the plugin. This isn't something we have a direct need for or that I think would open up the system greatly to other authors at this time.

All you would need to do is override system/Content/Search/Result/Content.php and make all of the properties public instead of protected, at which point you could just access the properties of each result directly. Or add a method to the class to return the value stored in the protected property. It would only be a few lines of code.

If there's a REST API for that it will be really useful!

I'm currently looking for workarounds like FlitterKill.

I really need this function in the API.

[BomAle]

consider to search also for specific filters 

on default when call init() the query add all enabled app to where clause...

[bfarber]

https://invisionpower.com/release-notes/

Quote

\IPS\Content\Search\Result\Content now has an asArray() method, which will return search index data as an array

I believe this is what you were after?

[TSP]

6 hours ago, bfarber said:

https://invisionpower.com/release-notes/

I believe this is what you were after?

Yeah I'm aware, sounds like it. Thanks. 

I'm not following the IPS platform very closely nowadays, so I haven't looked into the code or been working on upgrades.