Symphony.

Invalid search sections

Ah, I see. I assumed (making an ass...) that it defaulted to all sections. I'm confused then as to how it does it's if, else checks in the datasource... the default in config.php is sections. What does this reference? Do I always have to specify the sections I've indexed into the config.php file or can the extension not auto choose the ones indexed?

If I've set the get-param-prefix to param_pool, does that mean I have to also use a page param for sections?

This is really cool now I'm understanding it!

(as you can see, ignore

I assumed that it defaulted to all sections.

That could be dangerous! Do you think it should, though? Open to suggestions.

Do I always have to specify the sections I've indexed into the config.php file or can the extension not auto choose the ones indexed

If they are found as querystring params then they will be used:

/?sections=articles,comments

If not, it will look for the default-sections in the config. So you can set the defaults in the config, but override via the URL.

The get-param-sections value (sections) in the config is what you name the GET parameter. So if you were German and wanted a querystring parameter like:

?bereich=articles,comments

Then you would set in the config:

'get-param-sections' => 'bereich',

If I've set the get-param-prefix to param_pool, does that mean I have to also use a page param for sections?

I'm afraid so, yes. It becomes an all-or-nothing if you choose to use page URL params. I added this more as an afterthought, so in reality maybe this isn't very useful. Perhaps you should be able to use them together, for example:

/search/:sections/:keywords?page=2

Where sections and keywords are URL Parameters set on your page, but page is a querystring parameter. The extension doesn't allow this at the moment...

Thanks for all this, maybe I would have got it more if I'd slept this weekend.

I assumed that it defaulted to all sections.

What I meant to say was 'all indexed sections' but I agree, it could be dangerous. That would have been my next point if you'd have said 'yes' ;o)

I've stuck with the url-params method, as it's easier, but page params would be better in some cases, although it kind of mimics Symphony's default section filtering. Maybe some community discussion about that would yield some ideas.

As I've said, I'm using url-params, and I've got it working now. It's got me thinking about grouping though. Would it be possible to group by section in the output? I see the xml contains a node for sections, then individual entry nodes. Could this not be grouped by the section nodes? IMO it would make the xml and xslt processing more fluid, just a thought...

One last thing... (promise) The setup I have is that each searchable entry is in a subject and I would need to filter by this subject in my 'advanced' searching. Is this what the filters are for in the indexes?

The drawback with page URL params is that they are all required. GET params lets you leave them out and fall back to the default values (and in any order, too). I think perhaps a dual mode should work, so that you can use both in tandem: page URL params for required variables (sections, keywords) and GET params for optional (page, sort).

The XML output was intended to mimic normal data source output, with <section> and <entry> elements all direct children of the data source's root element. That felt more natural in my eyes, as I seldom want to print the name of the section beside each entry. But I see your point.

The setup I have is that each searchable entry is in a subject and I would need to filter by this subject in my 'advanced' searching. Is this what the filters are for in the indexes?

Kind of, ish. The filters in an index are for fully excluding entries from the index entirely. So if you had a "Published" checkbox on an entry and you only showed entries on the site which had this checkbox ticked, you'd want to add a filter in the index so that the extension only indexed published entries.

If you need to filter on a specific field in addition to full text keywords, then this isn't supported in the multi-section search, since the filterable field might not be present in all indexed sections. So if you have a section that you want to filter a Subject field and also have a keyword search on all other fields, you'd need to use a standard data source with the Search Index field (and not the multi-section search).

So basically, can I pass a GET param to the index filter or does it have to be a 'hard coded' word like 'published'?

That would have been my next question, but I've just tried it and it doesn't index anything, damn.

I think I need to go away and rethink some basic principles... Of my search functions.

So basically, can I pass a GET param to the index filter or does it have to be a 'hard coded' word like 'published'?

Hard coded, they are not dynamic. These filters aren't processed at runtime when someone searches — the search index is a pre-processed (cached) copy of your entry data. So the filters on your index prevent entries being added to the index when you don't want them (the indexed copy of an entry is updated every time you save an entry in the backend).

Ok, I understand now.

BTW, I have selected a few select box links to index on, and the excerpt is coming back as one long string of the options selected. Is this expected? Would it be possible to upgrade this to a list of items like a normal DS? Or would that be too complicated?

The index is the plain text contents of your entry XML. So if you have Select Box Link (or just a select box) with three values:

<item id="1">Coffee</item>
<item id="2">Tea</item>
<item id="3">Milk</item>

Then the indexed text would be:

Coffee Tea Milk

There's currently nothing preventing this — the plain text value of XML is used. The same goes for the HTML from a Markdown textarea:

<p>This is <em>some</em> text!</p>

Is indexed as:

This is some text!

If the excerpt isn't quite what you're after, then I suggest some data source chaining (or enable build-entries in the config if performance isn't critical and you don't have many fields in your section) and use the original value of the entry fields themselves rather than an excerpt.

Or alternatively don't index the values of the SBL fields, if you can get away with it!

Then the indexed text would be: Coffee Tea Milk

I think I have a bug then, as there are no spaces between the values of one SBL, but are between different fields, ie:

CoffeeTeaMilk CoffeeTeaMilk  -  Two separate SBLs

Bug! Two or more spaces in the excerpt are replaced presently by a blank string but should be a space (' ').

Search Index updated to version 0.8.2 on 23rd of May 2011

• fixes spacing issue above
• fixes problem with finding default sections when none are passed in URL
• added explanation of the keyword suggestion data source to the README

Nice. I'll leave you alone now.

Nick, an awesome addition would be (single section searching) to be able to add the Search Index field to the output of a DS which would show an excerpt.

Yes, I like this idea and definitely easy to add.

Nick, in my excerpts (from Markdown-enabled fields) I get HTML-encoded entities around the search keyword, like so:

Präsidiumssitzung der <strong>BayernSPD</strong> 2011 in Irsee

Is this by design?

Oh, and I sent you a pull request too (something else) ;o)

Michael, I have pushed some fixes for your funky characters.

John, this commit adds the excerpt functionality to the Search Index Field. After adding the field to a section you'll have to go through and save every entry in that section, so Symphony recognises it as a field in the entry. You can then select the field in data sources and the value will be the highlighted excerpt.

Unknown column 'score' in 'order clause'
An error occurred while attempting to execute the following query

SELECT SQL_CACHE `keywords`.`keyword`, SUM(`entry_keywords`.`frequency`) AS `frequency` FROM `sym_search_index_keywords` AS `keywords` INNER JOIN `sym_search_index_entry_keywords` AS `entry_keywords` ON (`keywords`.`id` = `entry_keywords`.`keyword_id`) WHERE `keywords`.`keyword` LIKE 'newscafe%' GROUP BY `keywords`.`keyword` ORDER BY score-recency LIMIT 0, 50

Backtrace

* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/toolkit/class.mysql.php:458] MySQL->__error();
* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/toolkit/class.mysql.php:604] MySQL->query();
* [/home/terras/domains/terraschecker.nl/public_html/extensions/search_index/data-sources/data.search_suggestions.php:84] MySQL->fetch();
* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/toolkit/class.frontendpage.php:809] datasourcesearch_suggestions->grab();
* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/toolkit/class.frontendpage.php:389] FrontendPage->processDatasources();
* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/toolkit/class.frontendpage.php:190] FrontendPage->__buildPage();
* [/home/terras/domains/terraschecker.nl/public_html/symphony/lib/core/class.frontend.php:110] FrontendPage->generate();
* [/home/terras/domains/terraschecker.nl/public_html/index.php:27] Frontend->display();

I'm using this form:

<form action="/zoeken/" method="get">
                        <input type="text" name="keywords" title="zoeken"/>
                        <input type="hidden" name="sort" value="score-recency"/>
                        <input type="hidden" name="per-page" value="10"/>
                        <input type="hidden" name="sections" value="terras,reacties"/>
                        <input class="zoekbutton" type="submit" name="submit" value="Zoek"/>
                    </form>

You should not attach the Search Index Suggestions data source to the same page as your search results page. The Search Index Suggestion data source is intended for making an AJAX autocomplete search. If you need to attach them to the same page then I'll need to do some tweaking.

Thanks a lot, that was not totally clear for me..