Issues with Search Index and Plugin Records

I’ve noticed while working on my own plugin search functionality that my search index is doing something odd. Anytime I reindex, it only indexes the Items and Files. None of the other plugin records (including Simple Pages) get indexed unless I re-save them and they are removed from the previous results. Is this something that might be specific to my server/installation? Does anyone have ideas about what to check? Thanks!

PS: I figured this is different enough from my related post linked above that I should start a new thread. Hope that’s ok.

Are you saying that if you reindex it actually removes plugin records that had been added to the index by saves?

If so, my first guess would be that it sounds like for some reason in the reindex job those records aren’t getting recognized as being marked as searchable.

So as an example, my About page contains the word “twitter.” Until I go save that Simple Page, the query returns no results (I’ve verified that it is removed from the search_texts table). After I re-save it, it returns the one expected result. If at any point, I go change the search settings and re-index all records, we end up back at square one, where the “twitter” search is empty. Likewise, with Exhibit Builder exhibits and other plugin-based records. Items, Files, and Collections are not affected.

Below is the omeka_processes table. It appears that a re-index job has never actually completed?

An example process looks like this (note lack of options?):


In omeka_settings table, the search_record_types row is set to:


I’m not sure what’s going on with the apparent duplicates. Maybe that’s the problem?

Omeka 2.5
PHP 5.5.38 (cgi-fcgi)
OS Linux 2.6.32-642.13.1.el6.x86_64 x86_64
MySQL Server 5.5.54
MySQL Client mysqlnd 5.0.11

PHP Extensions
Regular bcmath, calendar, cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, imap, intl, ionCube Loader, json, ldap, libxml, mailparse, mbstring, mcrypt, memcache, mhash, mssql, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib
Zend the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured)

Ah, okay, all the jobs failing is a big clue.

So what must be happening is an error during the search/save processing for one of the plugins in the background. The first thing the reindex does is truncate the search table, so it’s getting through all the core records, starting one of the plugins and dying, leaving you with no plugin search records.

Edit: the error could actually be happening during the “regular” records, that would show the same symptoms.

If you can try a reindex and check your Omeka and PHP logs, there should be something useful there (since the jobs are saying “in progress,” it’s probably a PHP-level error, but you never know for sure). Enabling logging to a file for the PHP CLI in its php.ini (by setting error_log to a writable file path) generally makes error retrieval from background stuff easier.

A common culprit with this kind of thing (failure only in the background) is a plugin that hooks to a save hook and does something like assuming a Request will always exist, leading to a fatal error when a method gets called on null.

Ok, this was actually helpful. I deactivated all my plugins and reactivated one at a time and think I found the culprit – unsurprisingly, it seems to be one of my own custom plugins. You can close this post. I’m going to follow up on the original post, which might be more useful for others. Apologies for starting a new one. It seemed like a good idea at the time. :slight_smile: