Filtering getResources and pdoResources by Tag-Like TV Values

Many older Evolution CMS projects store simple tags in one TV as a comma-separated string. That works, but it makes filtering trickier because you are no longer matching one clean scalar value.

The source example used a TV named tags and tried to filter resources whose TV content contained the current page tags.

Typical approach

[[pdoResources?
    &parents=`6`
    &depth=`4`
    &limit=`100`
    &includeTVs=`tags`
    &tvFilters=`tags==%[[*tags]]%`
]]

Another attempt was to move the condition into &where:

[[pdoResources?
    &parents=`6`
    &depth=`4`
    &limit=`100`
    &includeTVs=`tags`
    &where=`{"tags:LIKE":"[[*tags]]"}`
]]

Why results can be inconsistent

If the TV stores values like 1,2,3 or 2,1, a raw LIKE comparison may match too much or too little. For example, searching for 2 can also match 12 if the stored format is loose.

Safer pattern

Normalize the stored data format first, then match against delimited values instead of plain substrings. If redesign is not possible, keep the query tight and verify the exact TV contents you are matching against.

[[pdoResources?
    &includeTVs=`tags`
    &tvFilters=`tags==%,[[*tags]],%`
]]

The exact delimiter strategy depends on how the TV is stored, but the key idea is the same: match full values, not accidental partial fragments.

Long-term advice

If tags become central to navigation, a dedicated relation structure is more reliable than a comma-separated TV. But for smaller Evo sites, a disciplined TV format plus careful filtering is often enough.