-BACKGROUND-
We are on v2.2.2 and in our site we use the browse page's search method by appending the search terms to the end of the following URL:
...omeka/items/browse?search=terms+appended+here
The reason why we do this is because we want only items returned and we use a plugin filter to limit results to a specific item type.
-PROBLEM-
For some reason, using the browse page's search in the way described above only does exact matching of search terms. Example, if we have a item record with "Jar of eyeballs" as its title and we search using the terms "eyeballs" and "jar" (...omeka/items/browse?search=eyeballs+jar), we don't get any results.
-QUESTION-
Does the browse page search method work differently in Omeka version 2.0 than it did in 1.5? If not, then is there anything that can explain/fix our problem above?
-COMMENT-
This used to work with Omeka version 1.5 which leads me to believe there is a loss of functionality with the browse page search method in v2.0. I know that there is a new search mechanism but I have already read at the following post that filtering to a specific item type record using the new search page is not easy/possible:
http://omeka.org/forums/topic/filtering-search-results-by-item-type#post-106116
Thank you in advance.
Yes, the Item search works differently in Omeka 2 vs. Omeka 1. The keyword search that used to be used specifically for Items was moved to the new sitewide search.
As part of Omeka 2's move to using the InnoDB storage engine, the items (actually, element texts) are no longer indexed with a MySQL "fulltext" index. The only remaining MyISAM table (a requirement, until much newer versions, to use fulltext indexing) is the sitewide search table.
The remaining "simple" search for items was rewritten to use a simple CONTAINS query instead. This has both drawbacks and benefits, since the old FULLTEXT search provided a more familiar keyword-type search, but came with a series of undesirable limitations that are difficult to change, like stopwords and minimum word length.
The major difference, as you note, is that the search string isn't broken into tokens and matched separately, but matched as one big term. This is baked in to Omeka; it can't be changed without an update to Omeka itself.
One possibility that comes to mind would be essentially reconnecting the new sitewide fulltext search table with the Item-specific search, so those keyword searches would work as they did in Omeka 1, but the rest of the system would essentially remain as-is.
Thanks for the explanation.
I was wondering what you meant by "reconnecting the new sitewide fulltext search table"?
I'm not sure if changing Omeka's core functionality is a direction we want to go in since it would complicate updates/upgrades, but depending on what you had in mind, we will consider it.
Lastly, do you think someday that there will be a way for us to filter out the new search page's results with a plugin?
Thanks again for your time.
You can, today, modify the results for the sitewide search with a plugin. Specifically, a search_texts_browse_sql filter will let you take extra GET parameters and alter the query Omeka performs to get the results.
In your case, you could use that to pass in an item type ID and filter the results that way.
That sounds great but the documentation is a little light. Could you briefly describe how I would add extra GET parameters in the filter? I hope that's not too much to ask.
Thanks again for the encouragement
The filter receives whatever GET parameters were used when accessing the page in the 'params' arg. You would likely add your parameter with an input on the search form, and then you'd use the filter to check for the presence of that parameter and modify the query as you need.