Symphony.

I don't understand what you're asking — could you explain in more detail please?

search result should be anchor tagged so that i can view that particular result

for eg if my search word is "nick" means and the search result would be

"my name is nick"

That's quite a broad question. Your XSLT that builds the search results HTML would need to build the anchor @href to the entry pages. The extension doesn't know the URLs of your entries, so can't give this information to you.

If you want to get the search phrase (keywords), these will be in the XML.

sorry am not getting u nick

any example code plz

You need to be more specific yourself, I still don't understand exactly what you are trying to achieve. Please explain as fully as possible.

can u post the code how to get the search result using xslt

Have you even read the README? Your XSLT will look similar to the code you already have for other data sources. Are you using single-section search with the Search Index field in a normal data source, or are you using the custom Search Index data source for searching multiple sections? It's not as simple as just giving you "the code" because the code changes depending on what you're trying to achieve — it's not black or white. For us to help you we need to understand your specific problem, which needs to be explained to us with care and detail.

yeah i read that readme

am using the custom Search Index data source for searching multiple sections and created my own datasource ,used {$ds-search} in my data source

and then,

i attached the custom search index data source to my search result page and the my data source with {ds-search} filter in my search result page

after that i gave

<xsl:apply-templates select="search/entry"/>

it just outputs the result with html tags

how to achieve the desired result for the above done process ?

jeeva, you can need to find and show your template you are applying for the xml for us to see. how can we show you da answer when you not show the full questions? show some more evidence. for example you says

<xsl:apply-templates select="search/entry"/>

but what template you using for apply-templates??

show the evidence

Found a bug! Line 424 of class.search_index.php refers to table sym_search_index_logs but sym_ should offcourse be: TBL_.

The same goes for line 453, 458, 463 and 468

edit: when i try to place the string "TBL(underscore)" in the forum (in lowercase) it gets replaced by 'sym(underscore)'. So I also detected a site bug! :-P

So I also detected a site bug! :-P

Nope, it's a Symphony "bug". In the MySQL class every occurrence of a lowercase TBL_ gets converted to the table prefix set in the preferences.

@klaftertief: hmmm... that doesn't sound like expected behaviour to me :-/

@nickdunn: I am having trouble with this extension when the user is searching with keywords of 3 characters (or less). This is because the default setting of MySQL does not search indexed text with keywords less than 4 characters. Since this is not adjustable with PHP, are there any thoughts on how to implement an alternative SQL-query for example?

@nickdunn: Something like this for example? in field.search_index.php:

if(strlen($data) >= 6)
{
    $where .= " AND MATCH(search_index.data) AGAINST ('{$data}' IN BOOLEAN MODE) ";
} else {
    $data = str_replace(array('+', '*'), '', $data);
    $where .= " AND `search_index`.`data` LIKE '%{$data}%' ";
}

hmmm... that doesn't sound like expected behaviour to me

Hence it is a bug ;-) Not an easy one to fix.

This is because the default setting of MySQL does not search indexed text with keywords less than 4 characters... any thoughts on how to implement an alternative

First you could try changing the ft_min_word_len server variable to less than three (see Fine-Tuning MySQL Full-Text Search). When I tried this locally it was fine, but on a production database server I ended up with tables crashing a lot, which broke other things, so wasn't a viable option.

You've got a few options. The most obvious is to iterate over each keyword and use a LIKE match, as in your search results extension. This works most of the time, but isn't particularly fast. You might notice performance degrades when you have many thousands of entries.

Another option is to use REGEXP. I used this recently, with a modification like this. Results are good and the client is pleased.

The drawback of not using boolean MATCH... AGAINST is that you cannot order the results by MySQL's own relevance score. The database calculates this for you based on the placement and frequency of keywords found, but LIKE and REGEXP do not have this benefit.

I hadn't considered merging the two methods into the same query. I don't know what impact that might have on performance, but my hunch is that you would lose the speed benefit of the fulltext index as the query will need to make several passes at the whole table. Don't forget that the relevance returned by MySQL will only factor in rows found using the fulltext index and not LIKE, so rows containing matching words less than three letters will still be weighted lowly.

We also changed the parameter on a production server and it also resulted in some tables crashing, so that wasn't quite what we were looking for. Plus, not all users have the possibility to do this on their hosting environment.

I fixed it now like I mentioned above, by doing a check if the search-query is shorter then 3 characters, so queries which are large enough still have the benefit of the fast search index, where smaller queries use a LIKE-query, so that at least some results are returned.

It was a quick mockup so I indeed have no ideas what my quick fix emplies for other functionality such as the relevance for example, but I do believe that an alternate option should be implemented in the extension (like you regexp for example) in case the query is not long enough. After all, it's better to be slow and get something than be fast and get nothing ;-)

What are your thoughts on this?

I haven't looked at the under workings yet, but would it make sense to build upon this extension for sections in Symphony's admin interface?

how to do this

"Use XSLT to iterate over the elements above, and cross-reference with the matching entries from the Articles and Comments data sources."? (readme file)

[Lewis] I haven't looked at the under workings yet, but would it make sense to build upon this extension for sections in Symphony's admin interface?

What sort of thing are you after, Lewis? Do you mean implementing backend search? This is something I have considered and may do in due course... but I need to get the frontend search working better first, as the character limitation of boolean search is tripping people up. I'm hoping to refactor this extension so that there's a search class that will accept parameters and return an array of entry IDs. Presently this is buried in a data source. Once this class exists, the search can be used in other custom data sources, as well as integrated into the backend too.

[jeeva] how to do this "Use XSLT to iterate over the elements above, and cross-reference with the matching entries from the Articles and Comments data sources."? (readme file)

I'll assume you're using the Search Index data source, which returns XML like this:

<search keywords="foo+bar" sort="score" direction="desc">
    <pagination total-entries="5" total-pages="1" entries-per-page="20" current-page="1" />
    <sections>
        <section id="1" handle="articles">Articles</section>
        <section id="2" handle="comments">Comments</section>
    </sections>
    <entry id="3" section="comments" />
    <entry id="5" section="articles" />
    <entry id="2" section="articles" />
    <entry id="1" section="comments" />
    <entry id="6" section="comments" />
</search>

In the example above you're searching two sections, articles and comments. To be able to flesh out the search results with content from both of these sections, you will need two additional data sources; one for each section. Create a new data source from the Articles section, name is "Search Results - Articles", filtering System ID by {$ds-search:0}. $ds-search is the output parameter of the Search Index data source, which is a list of the found entry IDs. Include fields from the Articles section that you need to show in the search results (maybe title, date and author?). Repeat for comments, and any other sections you are searching.

Attach the data sources to your search results page. When the Search Index data source runs it will pass the matched entry IDs into these extra data sources, and they will return the extra fields for each entry. The :0 part in the filter is there because if $ds-search is empty, it will be ignored. So the colon syntax means "if $ds-search has no value, use 0 instead. Since no entry IDs are 0, the data sources will correctly return nothing.

The final task is to show the search results in your page. Start by applying a template to the <entry> elements from the Search Results data source:

<ul>
    <xsl:apply-templates select="/data/search/entry" />
</ul>

The template that matches this would be:

<xsl:template match="search/entry">
    <li>
        ...
    </li>
</xsl:template>

This will just create an <li> for each matched entry. Not very useful. So the next thing is to look at the name of the section of each entry, and apply a template on the <entry> that has the same ID, but in another data source (the articles or comments data source.

<xsl:template match="search/entry">
    <li class="{@section}" id="entry-{@id}">
        <xsl:choose>
            <xsl:when test="@section='articles'">
                <xsl:apply-templates select="/data/search-results-articles/entry[@id=current()/@id]" />
            </xsl:when>
            <xsl:when test="@section='comments'">
                <xsl:apply-templates select="/data/search-results-comments/entry[@id=current()/@id]" />
            </xsl:when>
        </xsl:choose>
    </li>
</xsl:template>

Then add a template for each of the above matches:

<xsl:template match="search-results-articles/entry">
    <p>This is an article.</p>
</xsl:template>

<xsl:template match="search-results-comments/entry">
    <p>This is a comment.</p>
</xsl:template>

Given the initial XML for this example, you would end up with HTML like:

<ul>
    <li class="comments" id="entry-3">
        <p>This is a comment</p>
    </li>
    <li class="articles" id="entry-5">
        <p>This is an article</p>
    </li>
    <li class="articles" id="entry-2">
        <p>This is an article</p>
    </li>
    <li class="comments" id="entry-1">
        <p>This is a comment</p>
    </li>
    <li class="comments" id="entry-6">
        <p>This is a comment</p>
    </li>
</ul>

You'll need to adapt this code for your own needs — copying and pasting will not work — but this is enough to demonstrate the concepts you need to apply.