Hi, I have the following configuration:
- Drupal 7
- ApacheSolr
- Aegir
- DS
- Taxonomy
- Ubercart

If I add to the search display "Add to cart" option but DS is turned off and I index products and then turn on DS, I can see taxonomy terms on the products on the search results page. But if I first turn on DS and then index, then I get a lot of warnings that I am passing array instead objects:

Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1322 of /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
Warning: Invalid argument supplied for foreach() in _uc_attribute_alter_form() (line 1322 of /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).

So I did a backtrace and noticed that on setup with warnings I have zs_entity loaded with some information (according to http://drupalcontrib.org/api/drupal/contributions!ds!modules!ds_search!d... thats a hidden field where nodes are kept to avoid node_load later). But I still couldnt figure out why I am getting arrays instead objects, so I was suspecting on zs_entity.

I tried to play with some DS settings and in the end when I turned on DS' Multisite support option, problem disappeared. Now, I checked out this option and it seems to be an integration with ApacheSolr MultiSite Search module which I dont use.
Also it appears that ApacheSolr Multisite Search allows shared indexing which DS' Multisite support option implies too.

"Enable this in case multiple sites share one index. Note that sometimes you need to make sure that your formatters are creating absolute paths for links or images. Implementing hook_url_outbound_alter() is a good option in which you can set $options['absolute'] to TRUE."

The only reason I could come up with why this option fixes those errors / warnings, seems to be, because I am using Aegir. Therefore my webiste is not in /sites/default, but in sites/enter_website_domain_here. I couldnt find in any DS documentation or in README about multisite option so I would like if someone can confirm this.

Based on the all above, this seems to be a bug or a feature which didn't cover this option. Yes, I can have in Aegir multiple sites that share the same Drupal (aka platform) but I do not share search index as they live standalone. So will DS' Multisite option work as expected by not turning objects into arrays (warnings mentioned above) while preserving separate search indexes (because I dont use AS Multisite Search) or will it impact somehow?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

milovan’s picture

So here is an update regarding this problem. Multisite is actually not working correctly, and it breaks some stuff like addint product into Ubercart, which works everywhere as expected (so it is not Ubercart issue!).

Because of that, I went further in debugging who and why in DS is turning objects into array and managed to find it. I discovered the problem lies in zs_entity. In ds_search.module, line 630 which looks like:

$json = @drupal_json_encode($entity);

DS takes entity and packs it in JSON through Drupal wrapper function drupal_json_encode and stores in a new field called zs_entity during Apachesolr indexing.
But then in line 674 in ds_search.module, function ds_search_process_results($results) you are assigning $entity to be what was in zs_entity field, by extracting its content through Drupal wrapper function drupal_json_decode. If you take a look into definition of drupal_json_decode ( http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_jso... ), you will notice that it calls PHP's json_decode with fixed second parameter set to TRUE. By json_decode description ( http://www.php.net/manual/en/function.json-encode.php ) it says when TRUE, returned objects will be converted into associative arrays. And that is what is happening and is a problem with DS!
Before you pack entity in JSON, it looks like this (I took as example attributes in entity):

attributes before JSON

Pay attention on red circle: it is "attributes" dump in entity and it says it is ARRAY with OBJECT in it. Now, DS packs this into zs_entity and then decodes it later and this is what I get then:

attributes after JSON

Pay attention on red circle: attribute is an array which has ARRAY instead OBJECT in itself. Not only "attributes"; EVERY object that existed before zs_entity packed entity into JSON, was converted into array because of drupal_json_decode which uses second parameter fixed to TRUE.

So ok, I tried then to replace drupal_json_decode with PHP's json_decode and FALSE parameter. And what I get back is actually everything turned into objects. Here is a picture how attribute in $entity looked like:

attributes after PHP JSON

As you can see in the red circle, "attributes" became an object too.

So, long story short, drupal_json_encode and decode, even if they have some faulty work here (though they work correctly in many other modules), the main problem is DS and its zs_entity "caching" feature. Because of that, you are directly corrupting $entity structure which then impacts on other modules who are expecting for example object and they receive array. For example, uc_attributes expects object in attributes, but it gets an array. And a couple more seem to suffer for this corruption DS is unconciously doing when taking results from ApachSolr on search or facet usage.

Also another problem I noticed, function drupal_json_encode mentioned above, is generating a lot of warning messages "Warning: json_encode() [function.json-encode]: recursion detected in drupal_json_encode()" during Solr indexing, thus spamming "Recent log entries" so much. A quick workaround was to supress messages with "@" in front, like you did with drupal_json_decode, but I am not really fan of such solution. It can potentially hamper debugging in future by hiding those and other messages, etc. Error message, even if it is a just a notice, should be always visible to let you know there is something wrong going on, no matter how small issue could be.
So I researched a bit and found that it seems PHP's implmentation of json_encode and decode is not so fortunate, aka a lot of bugs arised. Many were fixed in PHP 5.3.(0+) (I am using PHP 5.3.3-7+squeeze15 on Debian 6.0.7) so all I can suggest is, in case you would like to keep zs_entity system as is, maybe to look for alternative better JSON library that provides encode/decode feature and implement it in DS? I was told that one of the best libraries can be found on http://json.org/ so I am just throwing it as a suggestion / yet another option.

But for now, this problem with DS exists and there is not a unique fix for all. For example, I needed to cast array, that DS made, back into an object in uc_attributes which I shouldnt do because:
1. uc_attributes works as expected
2. I am "patching it" because other module corrupted entity structure
3. "Fix" I applied is not a fix. It is a dirty hack which doesnt guarantee that problem is solved, as the same problem can arise on any other place or module because I am just dancing around the main issue in DS.

DS is a great module and I really want to use it, that is why I set and hunted a problem. But with this bug, it is making a lot of problems.
I will be happy to provide any more details or do tests for you. But you can also reproduce it by yourself. Below is my test configuration where I minimized amount of installed modules as much as possible to decrease possibility of any other module making additional mess and confusion during debugging.

Configuration:

  • DS 7.x-2.2
  • Ubercart 7.x-3.4
  • Apachesolr 7.x-1.1
  • Drupal 7.21
  • Aegir hosting system 6.x-1.9, 1 website only in platform

Steps to reproduce:

  1. install apachesolr (list of solr modules + solr 3 on server java tomcat)
  2. page/block_configuration set to override taxonomy pages
  3. create taxonomy vocabulary
  4. create ubercart product and attach vocabulary as a field
  5. create attribute with a couple of options for that product
  6. enable search result display suite template for that product type and enable add to cart form in that template
  7. enable apachesolr indexing for that product content type
  8. perform (re)indexing
  9. go to appropriate taxonomy page
  10. you can see that product is listed but add to cart form is broken (they will become input fields instead radio buttons) and a lot of PHP warnings are listed:
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1288 of /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1322 of /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Warning: Invalid argument supplied for foreach() in _uc_attribute_alter_form() (line 1322 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1376 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1408 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1418 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_get_name() (line 1486 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_get_name() (line 1490 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1429 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
    Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1430 of  /path/to/drupal/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).
milovan’s picture

Title: DS turning objects into arrays thus generating a lot of warnings » DS turning objects into arrays by mistake as well as generating a lot of warnings
milovan’s picture

Okay, this issue seems to be pretty serious yet no answers still. Just to sum up the problem, zs_entity packs entity and then unpacks it as an array, thus loosing all kind of parts of entity which were objects. As other modules expected to receive those parts as objects but now receive arrays, error messages pop up, some modules and functionalities become broken etc.

I was thinking about this issue and the only idea is to somehow examine entity before json_encode and store in the entity as some variable / array about which entity parts were objects so it can be used after json_decode to recover them. Does it sound possible and ok solution?

swentel’s picture

I'm actually thinking to remove the that whole json encode en decode actually, been having to hack it myself too many times as well. So if you have patch that just removes this stuff, please do :)

I'll work on this after dublin dev days.

milovan’s picture

Sorry for delay.
Here is a patch that should remove zs_entity. I quick tested it and looks to work as expected.

In case someone also made an issue regarding a lot of watchdog warnings:

Warning: json_encode() [function.json-encode]: recursion detected in drupal_json_encode() (line 4997 of /proj/www/aegir/platforms/iew2/includes/common.inc).

this removal also fixed it. :-)

Let me know if you need anything else.

Anandyrh’s picture

I feel I have the same problem....

I am using DS with Apache solr search and I get below error.

Notice: Trying to get property of non-object in _uc_attribute_alter_form() (line 1375 of [root]/sites/all/modules/ubercart/uc_attribute/uc_attribute.module).

I thought this was problem with ubercart, but while searching in the forum another post confirms that the error was due to DS.

It would be great if the patch is released with a version...

Regards,
Anand

Anandyrh’s picture

Also once when the 'Apache solr views' module is disabled the below error occurs:

Notice: Undefined index: keyword in views_handler_filter->accept_exposed_input() (line 1260 of [root]/sites/all/modules/views/handlers/views_handler_filter.inc).

milovan’s picture

Poke! Any news regarding testing for zs_entity removal patch I provided few posts above?

@Anandyrh: yup, it affects uc_attribute.module. I needed to patch it on a couple of places in module file. I can provide you a temporary workaround patch but would be much better if zs_entity removal patch gets tested and accepted.

swentel’s picture

I'll look at this very soon, also linked : #2003790: Compatibility with Apache Solr Search Attachments - there might be others in the queue that affect solr integration and need to be cleaned up soon.

netsensei’s picture

I'm also working on a Solr integration (quite some custom coding)

I was looking for ds_entity_view_fallback but it seems to be ripped out meanwhile ("7.x-1.8") No matter. What I did notice is that the zs_entity field has been replaced with a tm_entity field and around line 669 in apachesolr_search_ds_search_execute() I see this:

    // Unserialize tm_node field.
    $node = @unserialize(urldecode($item['fields']['tm_node'][0]));
    if (!isset($node->nid)) {
      $node = node_load($item['node']->entity_id);
    }

Feels like half the story to me as this is node specific, instead of entity type agnostic. Following this topic as this seems an important part of ds_search.

swentel’s picture

Version: 7.x-2.2 » 8.x-2.x-dev
Status: Active » Patch (to be ported)

Removed the zs_entity entry in 7.x-2.x branch - moving to 8.x-2.x.

swentel’s picture

Status: Patch (to be ported) » Closed (fixed)

Actually solr support is gone atm in 8.x - will come back later at some point.

swentel’s picture

Issue summary: View changes

Removed some unecessary paths