Data sources 

Overview 

Not every source necessarily holds what its name suggests. A processor invoked through TYPO3's dataProcessing chain always receives a contentObjectConfiguration , but once it is nested inside another processor's own dataProcessing , that value is no longer the top-level HANDLEBARSTEMPLATE configuration — it is whatever the parent processor forwards instead (its own config block, for example). The collection built for HANDLEBARSTEMPLATE 's own preProcessing / postProcessing hooks, which run before dataProcessing itself, sets only contentObjectRenderer and processorConfiguration ; contentObjectConfiguration and processedData are genuinely absent there.

Priority order 

When a lookup is not restricted to a specific source, all sources that are actually available are searched in priority order, highest first:

1. processorConfiguration
2. processedData
3. contentObjectRenderer
4. contentObjectConfiguration

The first source that has the requested key wins; sources are never merged for this kind of lookup. This is why an option like table , set by an outer processor, can be picked up by a nested processor without being repeated explicitly — as long as the nested processor actually queries that source (some processors restrict a given option to a specific source, or a specific subset, rather than searching all four).

Resolving a data payload (dataSource / data) 

process-each and process-variables accept a dataSource (or inline data ) option to pick the actual payload they operate on, independently of whatever their own configuration otherwise resolves from the four sources above. iterable-to-array and object-access use the exact same mechanism under a processor-specific option name — iterable and object respectively — instead of the generic dataSource .

dataSource (or the processor-specific option name)

One or more data source references, each optionally scoped to a sub-path with a colon (e.g. processedData:files ). A single reference is resolved and used as-is, whatever its type — it is not coerced into an array.

Multiple references, configured as a TypoScript array with numeric keys, are resolved in ascending key order:

• If every reference resolves to an array, they are merged, with later references overriding earlier ones on key conflicts.
• If any reference does not resolve to an array, the last resolved reference wins outright — all earlier references, including any that were arrays, are discarded rather than partially merged.

A warning is logged, and the payload cannot be resolved, if the option is empty, references an unsupported data source identifier, a data source that is missing in the current context, or a sub-path that does not exist within a data source. Note that an unconfigured option (rather than one configured with an invalid value) is not itself an error — see the fallback below and each processor's own documentation for what happens next.

data

Inline data, used as a fallback if the option above is not configured at all. This fallback always uses the fixed key data ( data. for an inline array in processorConfiguration , or a plain data key already present in processedData ), regardless of what the primary option is called for a given processor.

See each processor's own documentation for further, processor-specific fallbacks once neither option yields a value.