URL Resolver

url resolver configuration reference the json url resolver lets you define rules that compute url paths for content and taxonomy entities without writing javascript rules are evaluated at request time and return one or more candidate paths ordered by priority top level structure { "rules" \[ rule objects ] } field type required description rules array of rule yes ordered collection of resolver rules all enabled rules whose condition matches are evaluated; results are sorted by priority descending rule { "ruleid" "regular post detail", "name" "regular post detail", "description" "human readable explanation of what this rule does ", "enabled" true, "priority" 5, "condition" { }, "pathbuilder" { } } field type required default description ruleid string yes — unique identifier for the rule used in logs and test output name string no — display name shown in the editor ui description string no — free text explanation useful for documenting non obvious logic enabled boolean no true disabled rules are skipped entirely priority integer no 0 higher value = earlier in the result list when multiple rules match rules with equal priority appear in declaration order condition condition no — if omitted the rule matches every entity of the correct param type pathbuilder pathbuilder yes — defines how the url path is assembled condition determines whether a rule applies to a given entity all filters must pass (logical and) { "paramtype" "content", "filters" \[ { "property" "posttype", "operator" "equals", "value" "tests" } ] } field type required description paramtype "content" | "taxonomy" yes the entity type this rule applies to a rule with "content" never matches a taxonomy and vice versa filters array of filter no all filters must pass an empty array (or omitting the field) means the rule matches every entity of the given paramtype filter field type required description property string yes dot notation path into the entity (see resolvable properties) operator string yes comparison operator (see table below) value string, string array, or null depends on operator the value to compare against filter operators operator value type passes when equals string resolved property equals value (case sensitive) notequals string resolved property does not equal value in array of strings resolved property is one of the values in the array notin array of strings resolved property is not in the array contains string resolved property contains value as a substring (case insensitive) isnull — (omit value) resolved property is absent or null isnotnull — (omit value) resolved property is present and non null pathbuilder assembles the url path from an ordered list of segments { "prefix" "/", "separator" "/", "segments" \[ segment objects ] } field type required default description prefix string no "/" prepended verbatim before all segments separator string no "/" inserted between consecutive normal segments not used before propertysuffix segments (see below) segments array of segment yes — ordered list of path components the final path is prefix + segment\[0] + separator + segment\[1] + separator + a propertysuffix segment is an exception it is concatenated directly onto the preceding segment with no separator (see segment propertysuffix) if segments is empty the path equals prefix (typically "/") if any required segment cannot be resolved (e g a referenced property does not exist), the entire rule is silently skipped and produces no path segments segment literal a fixed string value { "type" "literal", "value" "hefte" } field type required description value string yes the exact text to include in the path example { "type" "literal", "value" "presse" } contributes presse to the path segment property reads a value from the entity at the given dot notation path { "type" "property", "source" "properties slug" } field type required description source string yes dot notation path into the entity (see resolvable properties) if the property is absent or null the rule is skipped (no path produced) segment taxonomychain resolves a taxonomy identifier to its full ancestor chain and joins them with / { "type" "taxonomychain", "source" "taxonomies category identifier" } field type required description source string yes a path that resolves to a taxonomy identifier (typically taxonomies \<type> identifier) the engine loads all ancestors of the resolved taxonomy and joins their identifiers with /, ordered from root to leaf this produces a nested path like electronics/laptops/gaming if the identifier cannot be resolved or the taxonomy lookup fails the rule is skipped segment propertysuffix resolves a property value and concatenates it directly onto the preceding segment — no path separator is inserted before it fails the rule (like property) when the source property is absent { "type" "propertysuffix", "source" "properties purple custom content id" } field type required description source string yes dot notation path to the property value to append example with a preceding property segment resolving to my article and source resolving to 12345, the segment contributes 12345 concatenated directly my article12345 use literalsuffix segments before and after to add surrounding punctuation (see segment literalsuffix and the composition example) segment literalsuffix appends a fixed string directly onto the preceding segment — no path separator is inserted before it always renders (cannot be made conditional) { "type" "literalsuffix", "value" " 1 html" } field type required description value string yes the exact text to concatenate onto the preceding segment example with a preceding property segment resolving to my article, a literalsuffix with value = " html" produces my article html resolvable properties the dot notation paths used in filter property fields and segment source fields content properties path description example value type name content type post, bundle, issue id internal mongodb id "64a1f2 " externalid external identifier "ext 42" name display name "my article" posttype post type (post content only) "tests", "ratgeber", "page" bundletype bundle type (bundle content only) "magazine" publication id publication id "pub 1" publication name publication name "my magazine" properties \<key> custom property by key properties slug → "my article" taxonomies \<type> identifier identifier of the first taxonomy with the given type taxonomies category identifier → "news" taxonomies \<type> name name of the first taxonomy with the given type taxonomies author name → "jane smith" taxonomies \<type> type type of the first taxonomy with the given type taxonomies category type → "category" taxonomies \<index> identifier identifier of the taxonomy at the given 0 based index taxonomies 0 identifier taxonomies \<index> name name of the taxonomy at the given index taxonomies 0 name note properties \<key> uses only the first segment after properties as the key a property stored with the key taxonomy category primary (containing dots) is not accessible via dot notation — use the taxonomies \<type> identifier path instead taxonomy properties path description example value identifier url safe identifier "essen trinken" type taxonomy type "category", "author", "tag" name display name "essen & trinken" parentidentifier identifier of the parent taxonomy, or null "food" internalid internal mongodb id "64b3e1 " properties \<key> custom property by key properties slug complete examples bundle → /hefte/{slug} {id} html literalsuffix and propertysuffix compose to build the {id} html part directly onto the slug with no / separator between them { "ruleid" "bundle hefte detail", "name" "hefte detail", "condition" { "paramtype" "content", "filters" \[ { "property" "type name", "operator" "equals", "value" "bundle" } ] }, "pathbuilder" { "segments" \[ { "type" "literal", "value" "hefte" }, { "type" "property", "source" "properties slug" }, { "type" "literalsuffix", "value" " " }, { "type" "propertysuffix", "source" "properties id" }, { "type" "literalsuffix", "value" " html" } ] }, "priority" 10 } produces /hefte/oeko test spezial 2024 42 html when slug = "oeko test spezial 2024" and id = "42" fails (produces no path) when id is absent — use a lower priority rule without the suffix segments as a fallback if needed regular posts → /{category}/{slug} {contentid} 1 html uses static slug when present, falls back to slug via two rules at different priorities { "ruleid" "regular post detail static", "name" "regular post detail (static slug)", "condition" { "paramtype" "content", "filters" \[ { "property" "posttype", "operator" "in", "value" \["post", "tests", "ratgeber", "reaktionen von herst"] } ] }, "pathbuilder" { "segments" \[ { "type" "property", "source" "taxonomies category identifier" }, { "type" "property", "source" "properties static slug" }, { "type" "literalsuffix", "value" " " }, { "type" "propertysuffix", "source" "properties purple custom content id" }, { "type" "literalsuffix", "value" " 1 html" } ] }, "priority" 2 }, { "ruleid" "regular post detail", "name" "regular post detail", "condition" { "paramtype" "content", "filters" \[ { "property" "posttype", "operator" "in", "value" \["post", "tests", "ratgeber", "reaktionen von herst"] } ] }, "pathbuilder" { "segments" \[ { "type" "property", "source" "taxonomies category identifier" }, { "type" "property", "source" "properties slug" }, { "type" "literalsuffix", "value" " " }, { "type" "propertysuffix", "source" "properties purple custom content id" }, { "type" "literalsuffix", "value" " 1 html" } ] }, "priority" 1 } the static variant (priority 2) fires only when static slug is set; when it is absent its segment fails and the rule is silently skipped, leaving the base variant (priority 1) to fire both rules may fire simultaneously when static slug is set — the higher priority path is used as the canonical url category taxonomy → /{identifier} { "ruleid" "category overview", "name" "kategorie übersicht", "condition" { "paramtype" "taxonomy", "filters" \[ { "property" "type", "operator" "equals", "value" "category" } ] }, "pathbuilder" { "segments" \[ { "type" "property", "source" "identifier" } ] }, "priority" 5 } evaluation order and multiple paths all enabled rules are evaluated against every request a single entity can match multiple rules and receive multiple paths — this is intentional for canonical/alias url patterns results are returned ordered by priority descending the first path in the list is treated as the canonical url by consumers when a rule's path cannot be fully assembled (a required property is missing, a taxonomy lookup fails, etc ) that rule is silently dropped from the results it does not cause an error when no config exists on the app, or the config has no rules, the engine returns nothing and the js resolver is used as a fallback