Tagger uncached calling problem

Modx Cloud 3.01, Babel, LangRouter, Tagger (all extra’s updatet to latest version)

This snippet call outputs the tags for the current resource as expected.

[[TaggerGetTags? &resources=`[[*id]]` &rowTpl=`tag` &separator=`,` &outTpl=`tags` &toPlaceholder=`testoutput`]]

<div class="results">
    	[[!+testoutput]]
</div>

When I call it uncached (with exclamation mark in front), it outputs part of the call itself:

[[!TaggerGetTags? &resources=

and this

[[!+nowdate:default=`now`:strtotime:date=`%Y`]]

in the footer of the site gets broken, which is not the problem, but it indicates the tagger snippet call is breaking the rest I guess.

Incorporated in a pdoResources call:

[[pdoResources?
    &parents=`168`
    &depth=`0`
    &where=`
        [[TaggerGetRelatedWhere?
            &tags=`[[TaggerGetTags? &resources=`[[*id]]` &rowTpl=`tag` &separator=`,` &outTpl=`tags`]]`
        ]]`
    &toPlaceholder=`testoutput`
]]

It outputs an array of resources once, after page refresh no output.
As soon as I make the calls uncached things get broken.

There are some errors in the log as well:

[2022-05-18 12:58:42] (ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 227) Error 42S22 executing statement: 
Array
(
    [0] => 42S22
    [1] => 1054
    [2] => Unknown column 'Context.name' in 'field list'
)

[2022-05-18 13:05:16] (ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 666) Could not load class: TaggerTag from mysql.taggertag

What is wrong?

I couldn’t reproduce the problem.

Can you maybe provide the whole template/markup of the page (or everything that is necessary to replicate the issue)?

And please put lines with three back-ticks at the start and at the end of your code, so that the back-ticks are preserved.

```//line with 3 back-ticks at the beginning
//your code with the MODX tags here
```//line with 3 back-ticks at the end

It’s hard to check if there is just a syntax error in your MODX tag, if the back-ticks are not visible.

Thanks for pointing out about the 3 backticks… I didn’t know that and couldn’t get things straight here.

The main problem is that I can’t call the Tagger snippets uncached, like

[[!TaggerGetRelatedWhere?
    &tags=`[[!TaggerGetTags? &resources=`[[*id]]` &rowTpl=`tag` &separator=`,` &outTpl=`tags`]]`
    &toPlaceholder=`testoutput`
]]

For the complete picture: main template has:

<section> news item <section>
[[*showRelatedItems:is=`1`:then=`[[$blok_related_items]]`]]
<footer> ... </footer>

Chunk ‘blok_related_items’ :

<section>
        [[pdoResources?
            &parents=`168`
            &depth=`0`
            &where=`[[TaggerGetRelatedWhere?
                &tags=`[[TaggerGetTags? &resources=`[[*id]]` &rowTpl=`tag` &separator=`,` &outTpl=`tags`]]`
            ]]`
            &toPlaceholder=`testoutput`
        ]]
    	<div class="results">
    		[[!+testoutput]]
    	</div>`
</section>

Like this the output is shown as a series of <pre> with array of resource in div.results, which is good.
When I add an exclamationmark to either or all of the snippet calls:

        [[!pdoResources?
            &parents=`168`
            &depth=`0`
            &where=`[[!TaggerGetRelatedWhere?
                &tags=`[[!TaggerGetTags? &resources=`[[*id]]` &rowTpl=`tag` &separator=`,` &outTpl=`tags`]]`
            ]]`
            &toPlaceholder=`testoutput`
        ]]

then the output shows only [[!pdoResources? &parents=

I don’t think this is a problem with Tagger.

The parser in MODX3 shows some weird behaviour, if there is an uncached tag with properties inside a cached tag.

For example

[[*id:is=`1`:then=`[[!mySnippet? &prop=`value`]]`]]

returns [[!mySnippet? &prop=


But this works correctly: (Both tags are uncached)

[[!*id:is=`1`:then=`[[!mySnippet? &prop=`value`]]`]]

And this also works:

[[*id:is=`1`:then=`[[!mySnippet]]`]]

(The behaviour is the same, if I move the mySnippet call into a separate chunk.)

1 Like

Try to write the line

[[*showRelatedItems:is=`1`:then=`[[$blok_related_items]]`]]

like this

[[ [[*showRelatedItems:is=`1`:then=`$blok_related_items`]] ]]

I think this way it should work.

1 Like

Awesome! That that did the trick… I couldn’t have thought of that. Thanks a lot!

This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.