I am running an apache solr search index for users that also have profile2 profiles.
[EDIT] It has also been reported with a normal database index.

When I output results using a view and add fields from the attached profile2 profiles I get the following error in my view's live preview:

ResponseText: EntityMalformedException: Missing bundle property on entity of type profile2. in entity_extract_ids() (line 7389 of /var/www/mirp/includes/common.inc).

So far it seems to only affect the live preview and the actual view doesn't throw errors.

There is an issue relating to this in the profile2 queue but I don't think the problem lies in that module -

#1283996: EntityMalformedException


lucascaro’s picture

Well, for the record, I'm having the same problem using database search index, and from what I could research, the problem lies between profile2 and search_api.. if anyone has a clue on where to start looking to solve this error, it would be greatly appreciated.


rooby’s picture

Thanks, I have added to the main post that it also affects database indexes.

lucascaro’s picture

rooby, updating entity api to the latest dev fixed the issue for me. Have you tried that?

jsacksick’s picture

Category: bug » task
Status: Active » Closed (cannot reproduce)

Tried with latest version of Entity and it worked. Tagging this as closed.

kevinquillen’s picture

Status: Closed (cannot reproduce) » Active

I am getting this error too, but not on profile2, on a custom entity. It was working a month ago, but now configuring a view results in that error every single time, even with the patch from before. Not sure where to go with this. Thoughts?

rooby’s picture

I have recently updated my search api modules and am about to update my entity/profile2 modules to latest (I have a lot of custom & patched stuff in development so it isn't a straightforward process and requires alot of testing).

When I do that I'll report whether or not it fixes my problem as per #4.

Although if it fixes it it doesn't really help you as you aren't using profile2.

kevinquillen’s picture

I don't see how profile2 is the problem? Earlier posts point to Entity/Entity API. The original patch to common.inc fixed this for me before, but not this time.

The error says the entity has no bundle info, but if you call hook_entity_info against the entity in question, it has 5 bundles attached. However, its under 'bundles' and not 'bundle' which is what common.inc is checking for... not sure if that matters. My entity looks just like profile2 when I examine both with entity_get_info.

kevinquillen’s picture

Getting this issue again.

I dumped out the line in common.inc just before it throws this exception, and the result from Search API (hooked to Solr) is a NULL $entity object, which will definitely cause this function to blow to hell (entity_extract_ids()).

Is there any better way of tracking down how this originates and how to clear it out?

rooby, just curious, but with SearchAPI Solr, when an entity is deleted, does it have to notify SearchAPI Solr at all so that its index item is purged?

rooby’s picture

There is a function in search_api_solr/service.inc deleteItems() that does the job of deleting items from the solr index.

The main search api module is responsible for telling it what to delete. see search_api_entity_delete() in search_api.module.

I need to get this resolved too so hopefully I can spend some time soon investigating it more thoroughly.

kevinquillen’s picture

Here is a debug_backtrace() when I select a search filter on the view, then submit:


Now, picking other filters, the view works. When I select a certain one, it fails, throwing this. Something makes me think it is pulling an entity id from the index that no longer exists (can't be loaded therefore not passed to this function?) - note that func_get_args() shows my entity type, but there was no entity object passed to this function.

I am not exactly sure if this is SearchAPI or goes up the chain to EntityAPI to Entity (core)- I've had a hard time narrowing this down.

It doesn't always happen, and sometimes seems to correct itself. Only happens inside of Views results hooked to SearchAPI/Solr.

rooby’s picture

From memory I believe it can also happen with Search API pages so isn't necessarily search api views related.

I could be mis-remembering though.

kevinquillen’s picture

The combination used here is Views/SearchAPI Views/SearchAPI Solr.. never heard of SearchAPI Page.

Here is the exposed form and view:


You can see it works fine, until you select 'Lewes' under 'Select a town'. Fatal PHP error page, entity malformed error in the logs.

kevinquillen’s picture

Here is where it hit me a while back, and how I ultimately got around it:


Note: I am certain about the XML files- but clearing the index and reindexing brought it back. I am going to try that again (minus moving config).

kevinquillen’s picture

Clearing out that index and reindexing them all with drush did in fact fix this error. Now the task is pinpointing where/why this is happening. As I suspect, one of the properties was deleted in a hourly update (removed from market) but for whatever reason, not removed from the Solr index, thus causing a cascade of errors.

kevinquillen’s picture

If this helps, here is the delete method in our entity controller:

  public function delete() {
    field_attach_delete_bundle('drealty_listing', $this->type);

Is search_api_entity_delete() not picking up on when a custom entity is deleted or am I missing some code?

rooby’s picture

So coming back to this I cannot reproduce the problem I was having.

However, I am currently on a different development environment so it may be related to that.

I will have a look tomorrow on my normal one.
If it doesn't pop up again there isn't much I can do in terms of debugging until it does.

kevinquillen’s picture

You wouldn't happen to have Memcache+Redis on the old environment would you?

rooby’s picture

Nope. Both are dev environments, currently with no special caching.

Usual environment is Ubuntu server 10.04 with multisite solr running on a separate server.

Current environment is Linux Mint 11 (not a fan) with multisite solr running on localhost.

kevinquillen’s picture

Weird. I've only seen this occur about five times, all on the Barracuda server distro for Drupal, with Solr, Memcache, and Redis running.

We have since moved to Acquia hosting, and I have not seen that error since.

rooby’s picture

Once my site is out of dev it will also be on Acquia so I'm hoping there will be no issues.

I'm back on my usual environment now and I still don't see the problem.

Will just have to keep an eye on it for now I guess.

allabakash.g’s picture

Status: Active » Fixed

we were getting same exception...

we were joining commerce table's with profile2 table's to get the contributors information, it was throwing EntityMalformedException, which is due to, trying to get a user profile information, whose user account was deleted,

Later on added a condition to check, user exist or not, then it got solved.

Hope this is helpful for someone.


Status: Fixed » Closed (fixed)

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

littledynamo’s picture

Deleting the index and then re-building worked for us (we're using Solr). Steps used to fix:

- Go to admin/config/search/apachesolr
- Click 'Delete the search and Solr index'
- Click 'Queue all content for re-indexing'

The content will then be indexed via cron runs. If you want it to rebuild immediately then
click 'Index all queued content'

littledynamo’s picture

Issue summary: View changes

Adding some more information about types of indexes affected.

HeathN’s picture

Issue summary: View changes

I am getting this issue. I tried #23 and it did not work. This happens when searching many terms. Any ideas?

leistiko_texvet’s picture

For future information-seekers:

#23 ( https://drupal.org/comment/7978149#comment-7978149 ) worked great for me. Woot!

james.nt@ameexusa.com’s picture

#23 worked for me.

andyg5000’s picture

I was having this error because search_api_entity_update() was checking isset on $entity->original and that value was false. Looks like they already changed this to !empty in the dev branch http://cgit.drupalcode.org/search_api/tree/search_api.module#n886 which fixes the issue