Hello everybody, I have a very strange (never seen before) problem.
I’m updating a site from modx 2.8 to modx 3.1.1.
Everything works fine except for a TV defining the thumbnail of a show.
With modx 2.8, the variable was called with FastField, which is no longer available with modx 3.
So I proceeded with GetResourceField, then i tried pdoField, and also wrote my own snippet.
(a simple getObject(modResource), then getTVValue to retrieve the TV value)
But in all 3 cases, I manage to retrieve the value, my image is displayed correctly, but I end up with a whole series of numbers that I have no idea where they come from, and which are displayed outside the div where the image is located!
No matter which snippet I use to retrieve the TV, I end up with these numbers coming from nowhere (they look like timestamps…).
Does anyone have any idea about the source of the problem?
The extra FastField doesn’t work in MODX 3, but if you have the extra pdoTools installed, the same FastField-syntax can still be used as before.
These are definitely timestamps. But only looking at the front-end output (without knowing how the output of the resource is created) there is no way to determine what the source of the issue is.
The chunk “chk_un_evenement” works perfectly except for the line below where agenda_spectacle is the id of the show resource, and spectacle_vignette the TV of the image to be displayed.
You can see that the code works with FastField syntax (thanks for the FastField/pdoTools tip).
The “agenda_spectacle” TV retrieves the show id and the thumbnail is displayed correctly, so the code seems correct (and worked with modx 2.7/php 7.4)
Here, I tested with :
FastField syntax
pdoField
getResourceField
a personal snippet
And whatever the method, the image is displayed, but I end up with all these timestamps displayed outside the calling div.
If I delete the img tag, no timestamp is displayed.
No errors in the log, in short, something to go mad about…
Looking at the front-end, none of those timestamps appear to be inside the “vignette” divs which would seem to imply they’re not coming from your “chk_un_evenement” chunk. They’re all inside <font> tags. I can’t say more without seeing the full code though.
Thank you dev_willis, here’s the full code of the chunk.
You made me think that the problem maybe comes from the first line that filters the shows.
but I don’t understand why it does that, and even less why it’s been working for 5 years with modx 2.7 and not anymore…
the strangest thing is that if I just delete the vignette code, the timestamp disappears
if you check the link in my first post, it’s the strict exact same chunk working perfectly with modx 2.7
[[+tv.agenda_date:strtotime:isgte=`[[!+nowdate:default=`now`:strtotime]]`:then=`
<div class="chk_un_evenement">
<div class="date">
<span class="jour">[[+tv.agenda_date:strtotime:date=`%a`]]</span>
<span class="date">[[+tv.agenda_date:strtotime:date=`%d/%m`]]</span>
<span class="heure">[[+tv.agenda_date:strtotime:date=`%HH%M`]]</span>
</div>
<a class="spectacle" href="[[~[[+tv.agenda_spectacle]]]]">
<div class="vignette">
<img src="[[!getResourceField? &id=`[[+tv.agenda_spectacle]]` &field=`spectacle_vignette` &processTV=`1` ]]"
alt="vignette [[#[[+tv.agenda_spectacle]].pagetitle]]"></div>
<div class="texte">
<span class="titre">[[+pagetitle]]</span>
<span class="details">Détails du spectacle</span>
</div>
</a>
<div class="lieu">
<div class="lieu_nom">[[+tv.agenda_lieu]]</div>
[[+tv.agenda_lien:isnot=``:then=`
<a class="btn_lieu" href="[[+tv.agenda_lien]]" title="Voir le site internet du [[+tv.agenda_lieu:esc]]" target="_blank" rel="noopener">
Lien internet du lieu
</a>
`]]
</div>
</div>`]]
Well, I think the problem came from the nesting with the first line of the chunk that allowed filtering on dates.
I solved the problem by writing a clean snippet to do this filtering on dates in PHP, making a clean array and a getChunk, and hey presto…
Doing this kind of thing only with HTML code and input/output filters can be handy, but in the end, writing a clean snippet to handle all the logic is more efficient.
Thanks for trying to help. I’m just sorry I didn’t understand the cause of this bug.
The MODX parser works slightly different in MODX 3 than it did in MODX 2.
My guess is that the uncached tag ([[!+..]]) inside the output modifier of a cached tag ([[+...]]) confused the parser:
Also to make your code more performant, I would suggest already filtering the data in the database (for examply by using the &tvFilters property with getResources).