Hiding Dublin Core element from simple search

Is there any way to hide or otherwise restrict an element from simple search results? I have a site that include bibliographic entries for items, and a simple search returns false leads based on these fields being indexed and searched.

I can't find any way to remove or hide these elements, whether it's via a custom function, creating new item types and/or elements, or altering the search form. Is there any way to do this that won't involve some terribly ill-advised manipulation of SQL queries or the like?


I haven't tried this out in code yet, but it looks like the search_element_texts filter would do the job.

In a small plugin you'd add that filter, loop through the array that's passed in and remove the element text based on its element id.

When that is in place, reindexing the site should get at what you need.

That's great to hear -- I guess an update to 2.3 is on my to-do list.


I've started work on this plugin, and I'm afraid I might need a little more help with the coding. Is there a similar plugin or chunk of code in core Omeka that I could look to for guidance?

You could probably start with this demo Hooks And Filters plugin I sometimes use in workshops and training, strip out the hooks stuff and switch the filter. See also this intro to plugin structure.

As for the code itself, it'd work something like this:

public function filterSearchElementTexts($elementTexts)

  foreach ($elementTexts as $index => $elementText) {

    $elementId = metadata($elementText, 'element_id');
    //check if the elementId is one of the ones
    //you want to clobber. Maybe get that directly from the table,
    //our use Omeka's functions to look them up
    $skipElementIds = array(50, 51); //dc title and type in my installation
    if (in_array($elementId, $skipElementIds)) {

That's only partially tested, but will hopefully get you on a right path.

Thanks, that puts me a few steps ahead of where I was floundering!

After a few days of trying to figure out why this wasn't working (and coming up with nothing more promising than a missing return at the end of the function), I realized that it's not the plugin code that's the problem, it's the index.

Editing a record and saving it seems to trigger an index of that record, and then the plugin works as expected, but clicking the "Index Records" button in the admin spawns a process that completes in just a few seconds, and doesn't seem to actually re-index anything.

hmmm.... if you have access to the database, could you check to see if the search_texts table gets emptied?

Uncheck all the search record types to index, and save the changes. Then, running the index should leave that table empty.

Then, re-check all the types you want to index, save changes again, and run the index. That all _should_ get you the empty table, then fill it up again. If not, something is going wrong with that process that we'll have to track down.

Okay, there's definitely an indexing issue. I unchecked all of the record types, saved, and re-indexed, and the table didn't change. I then checked them all, saved, and re-index, and it remains the same.

So it looks like there's an indexing problem somewhere.

Yep, definitely something odd with the indexing. My suspicion is that the underlying issue is something wrong with 'long running' jobs. The reindexing uses a background (cli) process to do the work. Maybe something is going amiss there.

To test that, it might be worth going into application/config.ini and seeing what happens if everything in synchronous

In that file, there will likely be lines like these:

jobs.dispatcher.default = "Omeka_Job_Dispatcher_Adapter_Synchronous"
jobs.dispatcher.longRunning = "Omeka_Job_Dispatcher_Adapter_BackgroundProcess"

Try making both of those Omeka_Job_Dispatcher_Adapter_Synchronous and follow the same procedure as above. It runs the risk of timeout, but might at least show some changes.

In rare cases that I don't understand, I've also seen reports that sometimes removing the quotation marks makes a difference, so that's another variation.

Hope that gets us closer.

Removing the quotes didn't work, but using the synchronous option for the long running jobs did the trick. Thanks!

Do you have to have a strong computer programming base in order to use OMEKA???

Excellent! The problem with long-running jobs might still be an issue that we've only side-stepped here, so it might be good to keep in mind down the road.