Beta15+ problems with i18n and entity_translation [#1418834]

Comment	File	Size	Author
#34	apachesolr-hook_info_fix-1418834-1.patch	701 bytes	levialliance

Comment #1

drewmacphee commented 27 January 2012 at 15:22

I downgraded back to beta9 and the "old" enabled facets UI
admin/config/search/apachesolr/facets

And everything is working. I'd like to upgrade so I can rewrite my custom facets and such.

Log in or register to post comments

Comment #2

nick_vh

he/him

Ghent

commented 27 January 2012 at 15:42

Project:	Apache Solr Search	» Facet API
Version:	7.x-1.0-beta15	» 7.x-1.x-dev
Status:	Active	» Postponed (maintainer needs more info)

I'd recommend you to go back to beta9 and remove it.
Then check your database and variables to verify if no facetapi stuff was left behind and reinstall it.
Did you run all the update.php scripts?

Moving it to the facetapi queue but please report back with more info

Log in or register to post comments

Comment #3

cpliakas commented 27 January 2012 at 16:22

Priority:

Major

» Normal

So what combinations of the modules are being used here?

Log in or register to post comments

Comment #4

drewmacphee commented 27 January 2012 at 16:33

Priority:

Normal

» Major

Disabled beta9 then uninstalled.
Disabled facet 1.0rc1 then installed.
Checked variable, found nothing.
Checked most of the db for apachesolr or facet api..
There was a entity translation for facetapi in the DB so I removed that.
Deleted the apachesolr folder.
Reinstalled apachesolr beta15 and facetapi 1.0rc1

Same result

Log in or register to post comments

Comment #5

drewmacphee commented 27 January 2012 at 16:45

So I created a new solr environment (mysite_search) and deleted the default one and at first the facet link (button) led no where then when I flush cache the error showed again.
Then I hit back and I was suddenly on the page..

admin/config/search/apachesolr/settings/mysite_search/facets

You'll note it's not admin/config/search/apachesolr/settings/solr/facets

Must be something with the default solr environment that's setup on install??

Log in or register to post comments

Comment #6

cpliakas commented 27 January 2012 at 16:56

Project:	Facet API	» Apache Solr Search
Priority:	Major	» Normal

Bumping back to Apache Solr Search Integration, because if you track the code back you will see that the apachesolr_enabled_facets_page() is the wrapper function for the page callback, so we should determine what the $realm_name variable is and why the one it is passing to facetapi_realm_settings_form() is invalid.

drewmacphee, I need you to help debug here. Could you please provide the value of the $realm_name variable in apachesolr_enabled_facets_page()? If we determine that the Apache Solr menu is correctly passing the variables to Facet API, then we can bump it back here and continue debugging.

Thanks,
Chris

Log in or register to post comments

Comment #7

drewmacphee commented 27 January 2012 at 17:15

Since I deleted the solr environment (the default one that was there on install) and created a new one the problem has gone away.

Now I can't seems to recreate the same problem.

So 2 questions:

1) Does it actually create a default solr env on install (It's been a few months since I first set one up)
2) Where does it store the solr env info? Maybe I overlooked it when I was cleaning everything out.

(If needed I'll take the time to remove what I have and try to reinstall to recreate the error)

Log in or register to post comments

Comment #8

nick_vh

he/him

Ghent

commented 27 January 2012 at 17:20

Would you be able to test this upgrade path?

Install Beta9 + facetapi
Mess around with the environment
Install Beta15 + facetapi latest

See if this reproduces the bug, if it does we all have something to look at.

Log in or register to post comments

Comment #9

drewmacphee commented 27 January 2012 at 17:39

Didn't even need to do that.

Disable / Uninstalled beta15
Installed beta15

go to admin/config/search/apachesolr/settings
clicked on Facets ( which goes to http://beta.codet.com/admin/config/search/apachesolr/settings/solr/facet... )

Recoverable fatal error: Argument 2 passed to FacetapiAdapter::getFacetSettings() must be an array, boolean given, called in /var/www/mysite/sites/all/modules/facetapi/facetapi.admin.inc on line 66 and defined in FacetapiAdapter->getFacetSettings() (line 532 of /var/www/mysite/sites/all/modules/facetapi/plugins/facetapi/adapter.inc).

Log in or register to post comments

Comment #10

drewmacphee commented 27 January 2012 at 17:42

From apachesolr_enabled_facets_page()

$realm_name is block

Log in or register to post comments

Comment #11

drewmacphee commented 27 January 2012 at 18:05

So again to fix the problem I create a new solr environment, made it default, flush cache.
This time I didn't delete the default solr install. Now when I go to it's facets page, it works too.

Log in or register to post comments

Comment #12

cpliakas commented 27 January 2012 at 18:22

I took the steps illustrated in #9 and couldn't reproduce. I completely uninstalled the Apache Solr Search Integration module, re-installed it, and I was able to navigate to admin/config/search/apachesolr/settings/solr/facets?destination=admin/config/search/apachesolr/settings without any problems. If this cannot be reproduced on a fresh install of Drupal then we are probably going to have to close this as "cannot reproduce.". Are there any other modules or custom code that you have installed which could be causing the conflict?

Log in or register to post comments

Comment #13

drewmacphee commented 27 January 2012 at 18:42

Quite a few, domain, entity translation, ubercart...
I have a work around now so I'm happy.
When I'm feel ambitious I'll try it on a fresh install but feel free to close it.
If it happens on a fresh install I'll reopen.

Thanks for your prompt reapplies, much appreciated.

Log in or register to post comments

Comment #14

cpliakas commented 27 January 2012 at 18:54

Status:

Postponed (maintainer needs more info)

» Closed (cannot reproduce)

NP, and thanks for your debugging on this. Look forward to any additional info you can provide as time permits.

Thanks,
Chris

Log in or register to post comments

Comment #15

drewmacphee commented 27 January 2012 at 20:45

The next time I flushed my cache the error came back.
I did manage to enable from facet blocks and they showed.. but as soon as the error is back, It also won't show the enabled facet blocks

Log in or register to post comments

Comment #16

drewmacphee commented 27 January 2012 at 20:48

Status:

Closed (cannot reproduce)

» Active

I tried a virgin install and it works fine.

I've disabled almost all the modules.. leaving ubercart 3.0rc4 as it's the products being indexed
There are 3 vocabs being used as facets

Log in or register to post comments

Comment #17

drewmacphee commented 27 January 2012 at 21:00

Before when I printed
From apachesolr_enabled_facets_page() $realm_name is block

but from facetapi_realm_settings_form on line 66 is passing $realm which is nothing

It looks like

function facetapi_realm_load($realm_name) {
$realm_info = facetapi_get_realm_info();
return (isset($realm_info[$realm_name])) ? $realm_info[$realm_name] : FALSE;
}

is doing something wrong

Log in or register to post comments

Comment #18

cpliakas commented 27 January 2012 at 21:11

Project:

Apache Solr Search

» Facet API

Weird. Can you confirm that "block" is being passed to facetapi_realm_load()? This is pretty simple function that invokes all hook_facetapi_realm_info() implementations and check if the array key exists. If this is failing then we have some big issues as the core Facet API module's hooks aren't getting invoked. Playing project ping-pong again since we are back in Facet API's court.

Log in or register to post comments

Comment #19

drewmacphee commented 27 January 2012 at 21:36

Project:

Facet API

» Apache Solr Search

I was adding debugging info to facetapi_get_realm_info(); and it makes it work again until I flush the cache
(I'm flushing the cache using the admin menu flush all caches)

As far as I can tell $realm isn't getting set which is causing my problem

Log in or register to post comments

Comment #20

drewmacphee commented 28 January 2012 at 16:10

Status:

Active

» Closed (cannot reproduce)

I don't get it.. this morning everything is working.

Log in or register to post comments

Comment #21

drewmacphee commented 28 January 2012 at 18:54

Status:

Closed (cannot reproduce)

» Active

I finally narrowed it down to the entity_translation module.

Log in or register to post comments

Comment #22

cpliakas commented 30 January 2012 at 13:05

Status:

Needs work

» Active

I finally narrowed it down to the entity_translation module.

Great! Any specifics, or should we move it to Entity Translation?

Log in or register to post comments

Comment #23

nick_vh

he/him

Ghent

commented 30 January 2012 at 11:40

Status:

Active

» Needs work

Log in or register to post comments

Comment #24

ruudmeesters commented 30 January 2012 at 12:51

It is probably somewhere in the entity_translation_upgrade part of it which provides permanent redirects for unavailable node translation. I switched that off and the facets are back as well as a working facets link in the apachesolr settings tab.

Log in or register to post comments

Comment #25

nick_vh

he/him

Ghent

commented 30 January 2012 at 13:09

Title:	Can't enable facets	» Facet API problems with node translation in combination with entity_translation
Project:	Apache Solr Search	» Entity Translation
Status:	Active	» Needs work

Moving it to the Entity translation module

Log in or register to post comments

Comment #26

drewmacphee commented 30 January 2012 at 14:55

Hmm.. I haven't had entity_translation_upgrade enabled.
I have been having issues with entity_translation and title working together.
When they are both enabled I can't view any content (or go to the content page) with a title_field

EntityMetadataWrapperException: Unknown data property title_field. in EntityStructureWrapper->getPropertyInfo() (line 339 of /var/www/mysite/sites/all/modules/entity/includes/entity.wrapper.inc).

Also I've been getting the following when entity_translation is enabled and cron is run:

Warning: Invalid argument supplied for foreach() in RulesAbstractPlugin->rebuildCache() (line 1523 of /var/www/mysite/sites/all/modules/rules/includes/rules.core.inc).
Warning: Invalid argument supplied for foreach() in RulesAbstractPlugin->rebuildCache() (line 1523 of /var/www/mysite/sites/all/modules/rules/includes/rules.core.inc).
Warning: Invalid argument supplied for foreach() in RulesEventSet->rebuildCache() (line 695 of /var/www/mysite/sites/all/modules/rules/includes/rules.plugins.inc).

I'm sure this is all related.

Log in or register to post comments

Comment #27

drewmacphee commented 31 January 2012 at 20:08

Title:	Facet API problems with node translation in combination with entity_translation	» Facet API problems with i18n or entity_translation
Project:	Entity Translation	» Apache Solr Search

Well I've completely done a fresh version of the site and it seems that there are problems with i18n and entity_translation when apache solr beta15 is enabled.

When it's active:
When translation sets are active, there are errors whenever you hit any translate tab (for example on a block, or menu) (Something about get_string, is seems $strings in the translation object comes back blank)
When translation sets are off you can have block translation working, but you need translation sets for menus, paths and taxonomy translation.

When entity translation is installed it throws an error when loading any content with translation set to entity-translation. Even the on the admin/content page.

And the facet setting page is missing or throws my original error and all facets are missing.
If you turn off entity_translation you can get to the facet page and set active facets and they are there.

I went back to beta9 where everything is working together nicely.. however I need the results to return 9 items (for a nice 3 x 3 grid) and the blocks to appear on other pages, so I'd like to help get this solved.

I put this back on apache solr as it's the one piece in this puzzle that changed and caused issues with two other modules.

I'm going to press on and try to move up the betas to see where it breaks (I went back to beta9 as it was the last one I was using before this problem started.)

Log in or register to post comments

Comment #28

drewmacphee commented 1 February 2012 at 14:11

Everything is fine in beta13 as well.. and I see beta14 and 15 are similar and the upgrade path is to skip 14.. so I'd have to assume this is only with the major changes in 14/15

Log in or register to post comments

Comment #29

drewmacphee commented 1 February 2012 at 14:12

Title:

Facet API problems with i18n or entity_translation

» Beta15+ problems with i18n and entity_translation

Log in or register to post comments

Comment #30

nick_vh

he/him

Ghent

commented 2 February 2012 at 14:06

I assume this has something to do with entity_info? or even the entity_info_alter?
Could you please try and get more specific details to which function this entails?

Thanks!

Log in or register to post comments

Comment #31

levialliance commented 10 February 2012 at 08:09

Wild stabs in the dark after a half hour of investigation, but is module_hook_info() supposed to be reentrant?

If you clear the cache and trace what happens, you get something like this:

module_implements():674
  $hook_info = module_hook_info();

module_hook_info:738
  $result = $function();

apachesolr_hook_info():2147
  foreach (entity_get_info() as $entity_type => $info) {
     
entity_get_info():7417
  $entity_info = module_invoke_all('entity_info');

module_invoke_all():816
  foreach (module_implements($hook) as $module) {

module_implements('entity_info'):674
  $hook_info = module_hook_info();

module_hook_info():
  This time $hook_info is set [although the first module_hook_info() has not actually finished] so takes the fast exit path.

module_implements('entity_info') call still seems to return the correct data, and presumably when it goes back up the call stack it finishes the rest of the hook_info().

Whatever the exact cause, the net result is that hook_hook_info() for modules after apachesolr (ie facetapi) get skipped and so hooks in a group are not visible.

My hacky temporary workaround:

update system set weight=999 where type='module' and name='apachesolr';

Since the apachesolr_hook_info() call is now last (or close to it) the rest of the hook_info()s are called correctly.

Edit: That was with D7.12 and apachesolr 1.0-beta16+3-dev

Log in or register to post comments

Comment #32

levialliance commented 13 February 2012 at 22:42

This is actually the same issue as:

http://drupal.org/node/1415278
http://drupal.org/node/1410256 (this one not exactly the same but caused by the limitation in core)

The 'proper' solution is to fix hook_hook_info in core to be properly reentrant. A better workaround than changing apachesolr's weight is to move the entity_get_info() into a hook_hook_info_alter():

Index: apachesolr.module
===================================================================
--- apachesolr.module   (revision 9469)
+++ apachesolr.module   (working copy)
@@ -2145,12 +2145,19 @@
   $hooks['apachesolr_index_document_build'] = array(
     'group' => 'apachesolr',
   );
+  return $hooks;
+}
+
+/**
+ * Implements hook_hook_info_alter().
+ */
+function apachesolr_hook_info_alter(&$hooks) {
+  // we can't do this in apachesolr_hook_info() until http://drupal.org/node/1415278 is fixed
   foreach (entity_get_info() as $entity_type => $info) {
     $hooks['apachesolr_index_document_build_' . $entity_type] = array(
         'group' => 'apachesolr',
       );
     }
-  return $hooks;
 }

 /**

Log in or register to post comments

Comment #33

nick_vh

he/him

Ghent

commented 13 February 2012 at 23:22

@levialliance Can you make a proper patch for this? Easier to apply :-)

Log in or register to post comments

Comment #34

levialliance commented 14 February 2012 at 03:35

Status	File	Size
new	apachesolr-hook_info_fix-1418834-1.patch	701 bytes

Patch against git 7.x-1.x branch attached

Log in or register to post comments

Comment #35

nick_vh

he/him

Ghent

commented 14 February 2012 at 16:43

Status:

Needs work

» Needs review

Go testingbot, go!

Log in or register to post comments

Comment #36

nick_vh

he/him

Ghent

commented 17 February 2012 at 12:03

Can someone tell us if this patch works as expected?

Log in or register to post comments

Comment #37

cspitzlay

German

🇩🇪🇪🇺

commented 27 February 2012 at 17:05

The patch works for me. I don't get the error

EntityMetadataWrapperException: Unknown data property title_field. in EntityStructureWrapper->getPropertyInfo()"

any more.

No ill effects so far.

Log in or register to post comments

Comment #38

cspitzlay

German

🇩🇪🇪🇺

commented 1 March 2012 at 13:27

Status:

Needs review

» Reviewed & tested by the community

I'm not sure what level of tests and or experience is required to
promote an issue to "reviewed and tested by the community"
but the explanation makes sense to me and the
patch solved my problem which was Exceptions being thrown on all pages
when both title and apachesolr were active...