Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.
For 5.x documentation covering Platform see eZ Documentation Center, for difference between legacy and Platform see 5.x Architecture overview.

eZ Find 2.7 New Features

eZ Find 2.7 Documentation: new features

This document is about eZ Find 2.7 new features.

1. Overall

The eZ Find back end is upgraded to Apache Solr 3.5 and includes additional components not distributed before with eZ Find, related to a multilingual analysis and (experimental) search result clustering.

2. General Index Time Plugin Mechanism


This feature requires deeper understanding of eZ Publish kernel (object API), experience with eZ Find and PHP programming skills.

Goals and Use Cases

In some specific situations, the indexing with custom plugins per datatype is not sufficient or even applicable, hence the need to create a new index time plugin system that is capable of inserting new fields and/or modifying the fields generated by the regular eZ Find index engine.
Use cases are for example: indexing parent node information with an object or coping with a data model implementation where relations are part of the domain model, but do not use related objects or its datatype equivalents. This is typically the case where large amounts of data are imported into eZ Publish.
Another use case is to be able to modify boost factors of individual fields or whole documents based on the values or relations contained within an eZ Publish content object. For example, boosting articles that reference certain images, or articles that appear inside special eZ Flow blocks.

How it Works

During indexing, eZ Find can be instructed to call user defined functions from classes which implement a dedicated PHP interface. This is done after the eZ Find indexer has done the bulk of the work indexing the regular data and metadata.  The arguments are on one hand the current content object in the indexing process and on the other hand the eZ Solr document object --- consisting of raw fields and its corresponding values --- to be modified by the custom defined function. Not only fields can be modified or added, but also the overall document level and field level boost factors.

How to Use

The first step is to create your custom class implementing the function 'modify' as defined by the interface:

interface ezfIndexPlugin
    * @var eZContentObject $contentObject
    * @var array $docList
   public function modify(eZContentObject $contentObject, &$docList);

An example is given in the following listing where, for every language version of an object, the main node parent object name is indexed in a new field:

class ezfIndexParentName implements ezfIndexPlugin
      * The modify method gets the current content object AND the list of
      * Solr Docs (for each available language version).
      * @param eZContentObject $contentObect
      * @param array $docList
      public function modify(eZContentObject $contentObect, &$docList)
            $contentNode = $contentObect->attribute('main_node');
            $parentNode = $contentNode->attribute('parent');
            if ($parentNode instanceof eZContentObjectTreeNode)
                  $parentObject = $parentNode->attribute('object');
                  $parentVersion = $parentObject->currentVersion();
                  $availableLanguages = $parentVersion->translationList( false, false );
                  foreach ($availableLanguages as $languageCode)
                          $docList[$languageCode]->addField('extra_parent_node_name_t',  $parentObject->name( false, $languageCode ) );

In order to activate your plugin, you need to add your PHP class name to the eZ Find ezfind.ini settings in the IndexPlugins section, for example:

# Allow injection of custom fields and manipulation of fields/boost parameters
# at index time
# This can be defined at the class level or general
#Classhooks will only be called for objects of the specified class

This will enable the PHP class ezfIndexParentName for the myspecialclass eZ Publish class of objects.

3. Range Facets


This feature is for (template) developers building advanced search and navigation interfaces.

Goals and Use Cases

Range facets are a general type of facets, like date facets. They should be used to stitch together what otherwise could also be obtained with discrete query facets operating on numeric and date types.
Important: Range facets should also be used for date facets as the latter one is deprecated also in Solr!

How to Use

There can be multiple range facets specified, just like the field facets (but unlike the date facets in previous releases, where only one date facet could be called per fetch query).

Example of template code:

fetch( ezfind, search, hash( 'query', '$queryString, facet',array( hash( 'range', hash('field', 'published', 'start', 'NOW/YEAR-3YEARS', 'end', 'NOW/YEAR+1YEAR', 'gap', '+1YEAR' ) ) ) ) )

The parameters accepted as a hash array for the 'range' facet type are:






The field name to use (meta data or attribute).



Range start: any value valid for the numeric/data type.



Range end: any value valid for the numeric/data type.



Strig 'true' or 'false' (default) instructing Solr what to do if the intervals do not divide nicely between start and end.

If 'true', the 'end' parameter will be enforced. Otherwise, the gap will be used to determine the real end value.



String. Will be used to tell the back end  to provide more, less, all or no counts other than the ones in specified range:

  • before: all records with field values lower than the lower bound value of the first range
  • after: all records with field values greater than the upper bound value of the last range
  • between: all records with field values between the start and the end bound values of all ranges
  • none: no records will be computed
  • all: means all counts (shortcut to 'before', 'between' and 'after')



By default, the ranges used to compute range faceting between range start and range end.

The lower bounds are inclusive and the upper bounds are exclusive (i.e.: the 'before' range is exclusive and the 'after' range is inclusive).

This is the default behaviour, equivalent to 'lower' (see description below), and will not result in double counting at the boundaries.

This behaviour can be modified by the facet range.include parameter, which can be any combination of the following options:

  • 'lower': all gap based ranges include their lower bound
  • 'upper': all gap based ranges include their upper bound
  • 'edge': the first and last gap ranges include their edge bounds (i.e.: lower for the first one, upper for the last one), even if the corresponding upper/lower option is not specified
  • 'outer': the "before" and "after" ranges will include their bounds, even if the first or last ranges already include those boundaries
  • 'all': shorthand for lower, upper, edge, outer

Andrea Melo (08/05/2012 3:50 pm)

Andrea Melo (12/06/2012 11:20 am)

Andrea Melo, Paul Borgermans


There are no comments.