If search_api is included in a custom install profile, it breaks in search_api_enable(), when calling search_api_index_load_multiple().

PHP Fatal error: Class 'SearchApiIndex' not found in /var/www/nextgen/sites/all/modules/contrib/search_api/search_api.module on line 1827

If you then add an explicit require_once for the file containing that class, it will go on to break in another, more subtle way. Either way, the install profile is broken.

CommentFileSizeAuthor
#9 1647622-class-not-found.patch335 bytessocialnicheguru
#6 patch-to-module_enable-for-profile-installation.patch2.28 KBexratione
#3 1647622--skip_hook_enable_on_install-3.patch1008 bytesdrunken monkey

Comments

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

That would only be possible (unless I'm mistaken) if there already were some indexes before the module got activated. I guess this would be possible if you're using Features, but then the feature module should depend on the Search API, and thus be enabled afterwards.

Can you explain your detailed setup? (I know of people who're including Search API in their installation profiles, so this can't be broken per se.)

exratione’s picture

exratione commented

We are using Features, very extensively. The breakage happened prior to creating any search_api specific featurized content, however. Essentially as soon as I added it to the profile, it exploded.

Our installation profile is nearing 300 modules. Explaining that in detail is somewhat outside the scope of a bug post. We are not doing anything particularly novel beyond using a lot of featurized settings.

We are using dev branch ctools, though that hasn't caused us any other major issues.

We are also patching module_enable() more or less as described in http://drupal.org/node/1311828#comment-5365170

That should also not have any effect here.

Ultimately the only thing that was feasible for us under the circumstances (time is at a premium...) was to remove the hook_enable() implementation entirely. That seems to work fine in conjunction with our setup - if I'm reading it right, site_api_enable() really isn't doing anything that would matter for a completely fresh install of a site.

We are now using featurized search indexes and sources and that works fine, so long as search_api_enable() is disabled.

So I might argue that site_api_enable() could look like this, so as not to fire during an install profile, and it probably wouldn't cause anyone any issues:

/**
 * Implements hook_enable().
 *
 * Mark all items as "dirty", since we can't know whether they are.
 */
function search_api_enable() {
  if (variable_get('install_task') == 'done') {
    $types = array();
    foreach (search_api_index_load_multiple(FALSE) as $index) {
      if ($index->enabled) {
        $types[$index->item_type][] = $index;
      }
    }
    foreach ($types as $type => $indexes) {
      $controller = search_api_get_datasource_controller($type);
      $controller->startTracking($indexes);
    }
  }
}
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Active » Needs review
StatusFileSize
new 1647622--skip_hook_enable_on_install-3.patch1008 bytes

I'm still not sure why this should break for you (maybe an older PHP version?), but if it helps I'd gladly make that change. I also couldn't think of any cases in which this might cause troubles – when installing Search API for the first time during the Drupal install, there shouldn't be any chance of indexes being already present.

Please test the attached patch (reviews of others, whether this really is save, would also be appreciated)!

exratione’s picture

exratione commented

We're on PHP 5.3.5.

The patch looks fine, but you should of course solicit other opinions.

damien tournoud’s picture

damien tournoud commented
Status: Needs review » Closed (works as designed)

Your problem is definitely the patch you applied for #1311828-27: Installation fails with SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database.media_type' doesn't exist. That patch is totally bogus: both hook_install() and hook_enable() are meant to be run in a clean state, after the module list, registry and schema has been rebuilt.

At the minimum it is a CTools bug: CTools should not trigger side effects in a hook_registry_files_alter() that is itself *not* guaranteed to run in a clean state. That said, I never seen that being an issue in practice, so it might have been fixed in CTools along the way.

exratione’s picture

exratione commented
StatusFileSize
new patch-to-module_enable-for-profile-installation.patch2.28 KB

For context, the patch I referenced is a way to work around a fair number of ctools-dependent modules doing things that break install profiles. The ideal world solution is for the authors to fix their modules - but that isn't going to happen in time, and especially given that ctools is involved. No-one really cares about install profile functionality, sadly.

If this issue is caused by that patch - and I have my doubts - then it will be the first such issue we've seen. The patch we actually use in place of the earlier version referenced is attached as an FYI.

damien tournoud’s picture

damien tournoud commented

We have developed and are maintaining a fair number of installation profiles (including Commerce Kickstart) and I have to say we never bumped into the issue you mention.

Do not touch what you don't understand. hook_install() and hook_enable() are designed to run in a clean state where code is loaded, API is available, database tables have been created, etc. Search API is not doing anything wrong here.

JayKayAu’s picture

JayKayAu commented

Hi all,

I've just encountered this error while installing Commerce Kickstart:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_testdb.search_api_index' doesn't exist

So I gave "drush dl search_api" a shot, and it gave me this error:

WD search_api_views: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_testdb.search_api_index' doesn't exist: SELECT base.id AS id, base.name AS name, [error]
base.machine_name AS machine_name, base.description AS description, base.server AS server, base.item_type AS item_type, base.options AS options, base.enabled AS enabled, base.read_only AS
read_only, base.status AS status, base.module AS module
FROM
{search_api_index} base; Array
(
)
in EntityAPIController->query() (line 152 of /srv/www/testsite/profiles/commerce_kickstart/modules/contrib/entity/includes/entity.controller.inc).

Does that help anyone pinpoint the problem?

socialnicheguru’s picture

socialnicheguru commented
Issue summary: View changes
Status: Closed (works as designed) » Needs review
StatusFileSize
new 1647622-class-not-found.patch335 bytes

for some reason, class files are not always loaded on install.
See this comment/issue for background
https://www.drupal.org/node/542202#comment-6065048

This patch is a different approach to the others.
This patch has worked for me.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs review » Closed (works as designed)

No-one has complained about this in almost four years, so I'm pretty sure we're good as-is. (The comment also seems wrong – I just tried it out, to make sure, but as expected, autoloading also works when using static properties or methods. Also, I don't see the connection to this issue.)

guypaddock’s picture

guypaddock commented
Status: Closed (works as designed) » Needs work

I can confirm this is still an issue for us in 7.x-1.22 with the same repro steps. The patch provided does not work; we get this error:

Fatal error: Class 'Entity' not found in modules/contrib/search/search_api/includes/index_entity.inc on line 11

guypaddock’s picture

guypaddock commented

I can confirm that downgrading from 7.x-1.22 to 7.x-1.20 seems to fix / work around the issue.

guypaddock’s picture

guypaddock commented

I take it back. I'm still seeing the issue sporadically in 7.x-1.20 as well.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

I know plenty of people who have this module in their install profile – there's even several popular distributions that include it.
Whatever is happening has to be very specific to your setup, and nothing that's generally broken.
If you can find a simple enough solution that works for you, I'd still consider committing it to be on the safe side, but I can't really help you debug.

benstallings’s picture

benstallings commented
Status: Needs work » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.