Fixing bad node that makes search not index, but completes cron

Question

Upon updating to the latest version of Drupal 7, the following errors presented themselves in the site:

• Warning: Creating default object from empty value in node_build_content() (line 1398 of /var/www/html/modules/node/node.module).
• EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7881 of /var/www/html/includes/common.inc).

These errors don't seem to interfere with much on my site, however, they do seem to stop cron from indexing the website. I've been sitting at 0% of 456 pages with a 500 page max for a week or two now since my first noticing.

I've done a lot of digging trying to resolve this issue and the following link is the closest thing I can find in resolving this issue: http://tappetyclick.com/blog/2013/01/14/how-find-bad-node-makes-search-indexing-cause-drupal-cron-fail#.Vuw1KhIrJTY

The difference between the link above and my issue is that my cron successfully submits, even though right before the success message in the report log, it produces the EntityMalformedException: Missing bundle property listed in the bullets above. Outside of that, its relatively the same story. I've gone through the step-by-step in that link and many others like it without any resolution.

I've also additionally run this through devel_debug and a few other options to better troubleshoot but no other errors produce. Devel_debug actually doesn't list any errors at all in its log.

At this point I'm up for suggestions as I'm running low on ideas of how to remedy what seems to be a relatively multi-possible bug. Any thoughts the community may have or links to previously helpful posts would be appreciated.

Thank you in advanced!

Answer 1

After some additional alterations I was able to isolate 3 nodes that were not presenting as broken, but once I accessed them with PHPmyadmin I was able to delete them from the list. Once I found them and removed them Cron began indexing once again.

Answer 2

I had a similiar problem with the same errors in the search cron log.

I have 100 000+ nodes and did'nt want to delete the faulty/orphan nodes.

But with this Select I was able to see where the indexing stopped.

SELECT n.nid, title, n.type, status FROM node n LEFT JOIN search_dataset d ON d.type = 'node' AND d.sid = n.nid WHERE d.sid IS NULL  OR d.reindex <> 0 ORDER BY d.reindex ASC, n.nid ASC LIMIT 0,1"

However I found that the problem was because of uid's > 0 in the comment table for uid's that does not exist in the users table (non existing users). So former users that had been deleted. But for some reason they still existed in the comment table with a uid > 0 (their old uid when they where active users).

Solution was to located these "Orhan-users" in and set their uid in the comment table to zero "0".

After that the indexing continued and the node was intact, but with some comment to the nodes from active and non-active (not existing) users. I don't delete comments even if the user is deleted from the site.

I used this to update the comment table after I located the "missing" user.

UPDATE comment SET uid=0 WHERE uid="the old uid from a deleted user (not existing in users-table)";

Heres the process:

1. Locate where the indexing stops with the first SELECT.
2. Find if the node has comments (same nid)
3. Find out if all users (uid) in the comment table still exists (in the users table)
4. For those users that don't exist but have made a comment, make sure the uid in the comment-table is zero "0". With the UPDATE-script above.

This made the node displaying and the indexing continued.