%feature in a menu item will trigger eventually search_api_get_service_info during bootstrap prior to 'init', meaning the alter isn't called on those pages and won't be till cache is cleared (because of how module_implements is cached).

Patch moves it to top, which isn't the best, but should work for both search modules.

CommentFileSizeAuthor
#5 2177793-hooks-not-in-time.patch1.43 KBjanusman
#1 2177793-acquia_search_multi_subs-includes-1.patch1.2 KBhefox
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hefox’s picture

hefox CreditAttribution: hefox commented
Status: Active » Needs review
FileSize
2177793-acquia_search_multi_subs-includes-1.patch1.2 KB
Nick_vh’s picture

Nick_vh
he/him
Location Ghent
CreditAttribution: Nick_vh commented

Can you please explain this in more detail and show me how to replicate this behavior. There might be other ways around this?

hefox’s picture

hefox CreditAttribution: hefox commented

If you expert acquia solr server information to a feature, and visit one of the pages that has the feature name in the url ( /diff for example), it calls feature_load that eventually calls search_api_get_service_info before hook_init, so the alter hook is never called. There may be others, but that'll likely mean either 1) patching features 2) moving around a lot of cold to not include based on what module exists, but instead check if module exists inside the alter/etc.

janusman’s picture

janusman CreditAttribution: janusman commented
Status: Needs review » Needs work

The patch is calling module_exists() early in the bootstrap process; I think that could be a problem.

janusman’s picture

janusman CreditAttribution: janusman at Acquia commented
Category: Feature request » Bug report
Status: Needs work » Needs review
FileSize
2177793-hooks-not-in-time.patch1.43 KB

Working with @NickVh we actually tracked this down to the acquia_search_multi_subs_search_api_service_info_alter() hook being outside the main .module file.

New patch.

On a site where this failed, these were the steps to reproduce:

Before the patch:

  • Enable acquia_search_multi_subs along with Search API Solr, et al.
  • Set up a Search API Server solr server connection with the "Automatically Switch" checkbox enabled.
  • Go to a view, edit whatever part and save... this breaks the Search API Server form in that the "Configure Acquia Search" part does not show. (weird, eh?)
  • You can fix this now issuing drush cc all

Adding the patch seems to fix things.

janusman’s picture

janusman CreditAttribution: janusman at Acquia commented
Status: Needs review » Reviewed & tested by the community

Marking as RBTC:

I tested the patch with another broken site (which also breaks under the same circumstances) and can plainly see the patch fixes the problem.

Stepping thru code with XDebug seems to show these events are happening in an unpatched site:

* Saving a view triggers a menu rebuild
* During the menu rebuild, search_api_facetapi_facetapi_searcher_info() is triggered
* This in turn triggers search_api_get_service_info() which would need the acquia_search_multi_subs_search_api_service_info_alter() function already available in order for acquia_search_multi_subs to correctly override things.
* HOWEVER that function is located inside a file that was not loaded until acquia_search_multi_subs_init() is called later on... by then it's already too late.

So, the patch moves acquia_search_multi_subs_search_api_service_info_alter() from that later-included file into the main .module file, which is always available :)

janusman’s picture

janusman CreditAttribution: janusman at Acquia commented
Priority: Normal » Major

Upping to major.

janusman’s picture

janusman CreditAttribution: janusman at Acquia commented
Status: Reviewed & tested by the community » Fixed

Committed to 7.x-1.x-dev

  • hefox authored 4c47dcb on 7.x-1.x 
    Issue #2177793 by janusman, hefox: Includes not included in time to...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.