We've set up an Omeka site for a class. Today, we had a demo, and a user entered a term in the simple search bar that occurs in at least one item title, but the search returned no results. I found it curious and dug a little further, and here's what I observed.
We have an item here:
The title (DC) is "Snapshot of a dog". In the regular search bar, if I search for dog, I get no results. The query URL is:
However, if I search for 'snapshot', I get the item back. The query URL is:
The text "Teddy", which occurs in the DC description, also returns a result from the basic search.
It gets interesting when I add advanced search to the mix. If I do a fielded search for titles containing the word 'dog', my item comes back in the results! The URL is:
Has anyone seen behavior like this? I had experimentally verified that terms in the title were searchable before we loaded our data. I'm not sure what could have changed.
The behavior you're seeing seems strange, but it's happening because of a few different things about the MySQL search that Omeka uses.
The keyword or "simple" search is a MySQL fulltext search; it function somewhat similar to a Google search, but it has some restrictions. In your particular situation, the important restriction is that, by default, the search will not match any words that are fewer than 4 characters. So, this explains why "dog" doesn't give you any results in the regular search bar, but "Teddy" does.
While this didn't affect your specific search, there's also a list of "stopwords", search terms which MySQL simply ignores because they are too common. The MySQL website has a list of default stopwords.
Now, the "by specific field" search uses a different kind of searching, it will return results that are even parts of words, and it doesn't carry the restrictions that apply to simple search. So, the search for "dog" works the way you'd expect in the "by specific field" search, but not the "simple" search.
If you're interested, the MySQL website also has instructions for altering these restrictions, but you'll need to be able to edit your MySQL server configuration to follow them.
I had already checked MySQL's list of stopwords, but I hadn't seen anything about the length of the search terms, but your explanation is consistent with the problem. I'll have to decide whether we want to try to modify our MySQL server, switch to our Solr index, or leave things as they are.
Mark, I just went to your website. How did you fix your problem? I am having the same issue
I am having problems in simple searches. I have a site that has dozens of collections concerning Abraham Lincoln and the Civil War. If you do a simple search for "Lincoln" you get "0" results. However, if you search for "Lincoln" under "Search Items" you get plenty of results. Likewise, if you search for "Civil War" in simple you get "0" but plenty of results in search items. Also, if you search for "Springfield" in simple you only get three items, when there should be dozens. Does anyone have any suggestions?
First thing to double-check is under Settings->Search to make sure that all the record types you want searched are checked. and, you might need to reindex the records
I already had all the search boxes checked under Settings. When I click to reindex Ige an error message that says see Omeka Codex on retrieving error messages. I looked at that. I guess I will have to alter code to read the message?
Yes, just the .htaccess file and maybe config.ini
I changed the bit in htaccess so I can read error messages. When I tried to re-index I am getting the following error message: RuntimeException The configured PHP path ()is not valid. What do I need to do to correct this?
Do you have the CLI version of PHP installed (a command-line binary)? You might have to check with your host if you're not sure.
The re-index requires PHP CLI, and Omeka needs to know what path to find that program at. Right now, it looks like it has no idea where to look for the CLI binary (that's what those empty parentheses mean, the path is blank).
If you do have the binary installed, you can explicitly tell Omeka where to find it by editing application/config/config.ini, the
OK. Thank you. I will check with my host.
OK. I am in my control panel's file manager and see that under background.php.path it reads "Path to PHP-CLI for running background processes.
default: " "
Do I put in the "=" to edit?
I checked with my host and they confirmed that I have the CLI version of PHP. Under Background scripts I put in "CLI" but it said that path was invalid. What do I need to do to resolve this error. I'm sorry, but I don't have any programming background.
I'm sorry, I should have been more clear.
The default line you want to change looks like this:
background.php.path = ""
You want to change the
"" part. What you want to put in there is the path to the PHP binary on your server. You can ask your host what this should be; it'll be something like "/usr/bin/php"
I am still trying to resolve the error message I posted about two weeks ago. Everything I put into the PHP path to resolve the error is not working. Two weeks ago, I was told to change the default path from "" to the PHP binary on my server. There is no default line that reads """". I contacted my host and they said the line would be /usr/local/lib/php.ini I tried that but still getting the same invalid path error.
I really need to resolve this issue. I am not able to re-index my items because of the error message. I need to re-index in order to carry out valid searches.
Any other suggestions? I am willing to send you any information that you need to resolve this. Is it possible for me to speak with someone?
Can you show the line that you changed in applicaton/config/config.ini?
It would start
background.php.path, and there should only be one line that starts that way in the file. Lines starting with semicolons are just comments.
Under "Background Scripts" on line 152: background.php.path = "" I put in "/usr/local/lib/php.ini" The host said he installed a php.ini file under my domain folder. I asked him what the path is. He said /usr/local/lib/php.ini
I am willing to let you into the c-panel to see. I appreciate your help.
You want the path to be to the PHP binary, not a php.ini file.
You might want to check with your host again and make sure they know you need the path to the PHP binary, not a PHP config file (which is what php.ini is).
OK. Thanks. I contacted th ehost again, and they said the binary is /usr/bin/php I put that in after background.php.path = I am still getting the same error message:
The configured PHP path (/usr/bin/php) does not point to a PHP-CLI binary.
I already ascertained that they have the CLI version of php.
I attached -cli to php at the end and that worked!
Thanks you for your help.