Bug in eZFind 2.3, objects + mainNode, ezsolr line 357

Thursday 07 October 2010 2:40:17 am

Currently I am facing multiple issues regarding the new eZFind 2.3 and indexing/updating objects that are not within the table 'ezcontentobject_tree' thus have no node-object in its attribute 'main_node'.

When having such objects in your database and using eZFind 2.3 (official stable release) the cronjob fails with:

Fatal error: Call to a member function attribute() on a non-object in 
...../extension/ezfind/search/plugins/ezsolr/ezsolr.php on line 357

After poking in the code, I found the glitch that has been introduced in 2.3. 2.2 does not have this issue:

355: // Get global object values
356: $mainNode = $contentObject->attribute( 'main_node' );
357: $mainNodePathArray = $mainNode->attribute( 'path_array' );

Line 357 failes, because the return value $mainNode from line 356 is not checked before calling methods on this object (or in my case it's not an object, it is null).

I have this patch to provide a workaround and continue state to index other objects that are 'valid' and have a main-node ...

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -354,7 +354,7 @@
         }
         // Get global object values
         $mainNode = $contentObject->attribute( 'main_node' );
-        $mainNodePathArray = $mainNode->attribute( 'path_array' );
+        
         // initialize array of parent node path ids, needed for multivalued path field and subtree filters
         $nodePathArray = array();
         if ( !$mainNode )
@@ -362,6 +362,9 @@
             eZDebug::writeError( 'Unable to fetch main node for object: ' . $contentObject->attribute( 'id' ), 'eZSolr::addObject()' );
             return false;
         }
+        // get main-node contentobject-tree-node
+        $mainNodePathArray = $mainNode->attribute( 'path_array' );
+        
         //included in $nodePathArray
         //$pathArray = $mainNode->attribute( 'path_array' );
         $currentVersion = $contentObject->currentVersion();

But I am also curious. What is the reason, that i got contentobjects floating around without any node/tree attachment? What may be the possible initial cause for those ghost-objects?

Thanks,

chris

PS: eZPublish 4.2, imported content using the data_import extension, ezFind 2.2 manually updated to 2.3 due to 'date null import errors' in eZFind 2.2.

Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613

Thursday 07 October 2010 8:16:23 am

Thanks for your input Carlos,

well... we do not use the mentioned extension - but nice to know, thanks :-) May be useful sometime.

The site is a relatively new one, based on ezp 4.2.0, filled with approx 150.000 content-nodes and about 5000 users, all in about 15 languages. All the content-nodes have been imported in a 'import' folder. The customer now moves the imported articles from import-folder to the location he/she wants them to be.

In the process of moving, translating and adding related-objects to those articles, somehow the 'ghost-objects' appear. I just stumbled over them because the ezfindexcontent-cronjob was hardly quitting at one of such object which was in the 'pending_tasks' table about to be indexed using 'delayed indexing'.

 don't know if having those 'orphan' objects indexed can also leads in error while buidling the list of result nodes...

In eZFind 2.2 such ghost objects would never make it into ezfind. In eZF 2.3 the indexer crashes. So either way a search would never return such objects. So its no problem on this side. Returned nodes are all good.

Thanks again for your thoughts.

Chris

Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613

Monday 21 March 2011 7:54:39 am

A trashed item loses the main_node_id. The cronjob ezfindexcontent verifies the content object, not if his node exsists.

In solr.php (ezFind 2.3.0) the main_node check - if ( !$mainNode ) - should be moved to the line 355 otherwise the $mainNodePathArray = $mainNode->attribute( 'path_array' ) generates error.

from

354 $mainNode = $contentObject->attribute( 'main_node' );
355 $mainNodePathArray = $mainNode->attribute( 'path_array' );
356 // initialize array of parent node path ids, needed for multivalued path field and subtree filters
357 $nodePathArray = array();
358 if ( !$mainNode )
359 {
360     eZDebug::writeError( 'Unable to fetch main node for object: ' . $contentObject->attribute( 'id' ), 'eZSolr::addObject()' );
361     return false;
362 }

to

354 $mainNode = $contentObject->attribute( 'main_node' );
355 if ( !$mainNode )
356 {
357     eZDebug::writeError( 'Unable to fetch main node for object: ' . $contentObject->attribute( 'id' ), 'eZSolr::addObject()' );
358     return false;
359 }
360 $mainNodePathArray = $mainNode->attribute( 'path_array' );
361 // initialize array of parent node path ids, needed for multivalued path field and subtree filters
362 $nodePathArray = array();