Global navigation

   Documentation Center
   eZ Studio & eZ Platform
     User Manual
     Technical Manual
   eZ Publish 4.x / legacy

eZ Publish (5.x)

eZ Publish 5.x | For eZ Platform & eZ Studio topics see Technical manual and User manual, for eZ Publish 4.x and Legacy topics see eZ Publish legacy

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


Criteria are the filters for Content and Location Search in "Platform stack", for generic use of API Search see Search Criterions and Sort Clauses

Criteria, the plural form for Criterion, consists of two parts just like SortClause and FacetBuilder:

  • The API Value: Criterion 
  • Specific handler per SearchEngine: Criterion Handler

The Criterion represent the value you use in the API, while CriterionHandler deals with the business logic in the background translating the value to something the Search engine can understand.

Implantation and availability of a Criterion handler typically depends on SearchEngine capabilities/limitations, currently only Legacy (SQL) Search Engine exists, and it's support for FullText and Field Criterion is not optimal and it is advised to avoid heavy use of these until future search engine arrives.

Common concepts for most Criteria

For how to use each and every Criterion see list below as it depends on the Criterion Value constructor, but in general you should be aware of the following three concepts:

  • target: Exposed if the given Criterion supports targeting a specific sub field, example: FieldDefinition or Meta Data identifier
  • value: The value(s) to filter on, this is typically a  scalar or array of scalars.
  • operator: Exposed on some Criteria
    • All operators can be seen on eZ\Publish\API\Repository\Values\Content\Query\Criterion\Operator, at time of writing: IN, EQ, GT, GTE, LT, LTE, LIKE, BETWEEN, CONTAINS
    • Most Criteria does not expose this and selects EQ or IN depending on if value is scalar or array
    • INBETWEEN always acts on a array of values, while the other operators acts on single scalar value

List of Criteria

The list below reflects Criteria available in eZ\Publish\API\Repository\Values\Content\Query\Criterion namespace (it is also possible to make custom criterion not listed here):

Certain Criteria has been deprecated from use with ContentSearch because they are location specific and gives unpredictable result when Content has several locations. New criteria for LocationSearch has been introduced as replacements under Location\ namespace.

CriterionConstructor arguments description
Location\Depth>= 5.3/2014.03 operator (IN, EQ, GT, GTE, LT, LTE, BETWEEN), value being the location depth(s) as an integer(s).
Location\IsMainLocation>= 5.3/2014.03 value (Location\IsMainLocation::MAIN, Location\IsMainLocation::NOT_MAIN)
Location\Priority>= 5.3/2014.03  operator (GT, GTE, LT, LTE, BETWEEN), value being the location priority(s) as an integer(s).
ContentIdvalue being scalar(s) representing the Content id.
ContentTypeGroupId value being scalar(s) representing the ContentTypeGroup id.
ContentTypeId value being scalar(s) representing the ContentType id.
ContentTypeIdentifier>= 5.1/2013.01  value being string(s) representing the ContentType identifier, example: "article"
DateMetadatatarget (DateMetadata::MODIFIED , DateMetadata::CREATED), operator (IN, EQ, GT, GTE, LT, LTE, BETWEEN), value being integer(s) representing unix timestamp.
DepthDEPRECATED IN 5.3/2014.03

target (FieldDefinition identifier), operator (IN, EQ, GT, GTE, LT, LTE, LIKE, BETWEEN, CONTAINS), value being scalar(s) relevant for the field.

FieldRelation>= 5.3/2014.05 target (FieldDefinition identifier), operator (IN, CONTAINS), value being array of scalars representing Content id of relation.
Use of IN means relation needs to have one of the provided ID's, while CONTAINS implies it needs to have all provide id's.

value being the string to search for, properties is array to set additional properties for use with future search engines like Solr/ElasticSearch

LanguageCodevalue being string(s) representing Language Code(s) on the Content (not on Fields), matchAlwaysAvailable >= 5.2/2013.11 as boolean.
LocationId value being scalar(s) representing the Location id.
LocationPriorityDEPRECATED IN 5.3/2014.03
LocationRemoteId value being string(s) representing the Location Remote id.
LogicalAndA LogicalOperator that takes array of other Criteria, makes sure all Criteria matches.
LogicalNotA LogicalOperator that takes array of other Criteria, makes sure none of the Criteria matches.
LogicalOrA LogicalOperator that takes array of other Criteria, makes sure one of the Criteria matches.
MapLocationDistance>= 5.3/2014.03 target (FieldDefinition identifier), operator (IN, EQ, GT, GTE, LT, LTE, BETWEEN), distance as float(s), latitude as float, longitude as float.
MatchAllMainly for internal use when no filter or query is provided on Query object.
MatchNoneMainly for internal use by BlockingLimitation.
ObjectStateId value being string(s) representing the Content ObjectState id.
ParentLocationId value being scalar(s) representing the Location Parent id.
RemoteId value being string(s) representing the Content Remote id.
SectionId value being scalar(s) representing the Content Section id.
Subtree value being string(s) representing the Location id.
UserMetadatatarget (UserMetadata::OWNER , UserMetadata::GROUP, UserMetadata::MODIFIER), operator (IN, EQ), value being scalars(s) representing the User or UserGroup id(s).
Visibilityvalue (Visibility::VISIBLE , Visibility::HIDDEN), Note: acts on one of the locations involved meaning when used with with ContentSearch hidden content will be returned if it has other location which is visible. Use LocationSearch to avoid this.
  • No labels