Fred issue with MODX brackets

Support Extras
1

Summary

Fred rebuild is breaking some inline ModX calls in my pages. Modx [[ and ]] brackets are getting html encoded to %5b%5B and %5D%5D causing those code blocks to not execute properly.

Step to reproduce

On a Fred content area, I have set up as a full rich text type block with a RTE support/config, I have the following code for example, which grabs a local file download url from a template variable:

<p><strong>Download</strong> <a href="/[[*resource_file]]">[[*longtitle]]</a> now.</p>

Observed behavior

How it renders on the front end after a Fred rebuild:
<p><strong>Download</strong> <a href="/%5B%5B*resource_file%5D%5D">Filename Renders Here</a> now.</p>

Expected behavior

This is how it renders properly after saving a page with the code in it:
<p><strong>Download</strong> <a href="/downloads/proper-file-path-rendered.pdf">Filename Renders Here</a> now.</p>

Environment

Modx 2.7.3, Fred 1.1.1-pl

I have noticed that the longtitle never gets messed up - just the TV call. I also believe it sometimes gets messed up without a Fred rebuild occurring, but I have not been able to confirm/isolate that yet.

*Addendum: I have noticed this issue seems to be restricted to attributes inside an html tag - in this case the href inside an a tag. I have discovered it is NOT specific to TVs - it happens with regular [[~[[*id]]]] and similar tags if they are in an href attribute.

2

To use Modx tags with Fred you need to set an option set with remote = true i.e


{
    "remote":true,
    "settings": [
    {
        "type": "text",
        "name": "name",
        "label": "Full name",
        "value": "Jon doe"
    }
]
}
3

Sorry - that’s not the issue here.

I have these elements all set to “remote”: true

Thanks for the suggestion though!

4

how are you creating the link? Are you using the RTeditor and putting [[*resource_file]] in the url box?

5

Something like that - an RT area with text and code entered which appears like similar to this:

<p><strong>Download</strong> <a href="/[[*resource_file]]">[[*longtitle]]</a> now.</p>

I think the important thing to remember here is that this IS and DOES work just fine. I enter the above. Click save, and the content and link display just fine… UNTIL I do a FRED Rebuild… and then it breaks the inline calls as outlined above. Seems to be isolated to tags inside an href=""

And something to keep in mind. In order to get it working for a resource again, I merely have to go into edit mode in Fred on a resource with a broken link inside, and just click save. Don’t edit anything or have to change anything at all. Just save it again. Then the content is fine again until the next time I do a Fred rebuild, in which case it goes url encoded again basically.

So the takeaway is that the ModX tags are saving fine from Fred editing. They also render fine until something gets mis-parsed on Fred rebuild.

6

Interesting, I haven’t come across that yet. It seems like an issue with the way the rebuild parses the elements and contents.
Out of curiosity, what type of data does [[*resource_file]] hold? Is there a way to set the link using the RTEditor instead of using Modx tags? Or could you set this as an option and then use {{resource_file}} in the RTE instead?

7

The [[*resource_file]] is a file picker TV type. Just returns the path to a file. I could set it up as a Fred option, but I’d really prefer to keep it as a TV. Allows for much more usability.

8

Is there any way you can setup the element or template so you can call the TV outside of a FRED content area? This would probably be the best way. Also, just so you know, you can access TVs within Fred. Just add these options to your TV properties:

Screenshot 2020-03-05 at 12.31.05
Screenshot 2020-03-05 at 12.31.051515×604 115 KB

I think you can use text and image for the fred.type field. The Image field will give you access to the file selector. This might work for you as well.

9

Thanks - I will try the image type to see if the behaviour is different.

Interestingly though, I can confirm that this issue is duplicatable. On a completely different system I was able to replicate the exact same bug. To replicate, try the following:

  1. Add a new tv, give it the name (probably doesn’t matter what) resource_file and give it the input type of file. Assign it to a template that has Fred capabilities. Edit the resource in manager and pick a file using the newly added TV.

  2. Edit a resource in Fred that has the modified template. In an element/area that renders as a text/html block, add the following <a href="/[[*resource_file]]">Whatever Here</a>

  3. Save resource. View page - Link should be working.

  4. Do a Fred rebuild.

  5. Go back and view the resource. Link should no longer be rendering.

10

For extra confirmation of wierdness, put the following in to your textblock/edit:

<a href="/[[*resource_file]]">/[[*resource_file]]</a>

Repeat steps 3 & 4. You’ll notice that only the tag in the HREF is rendered incorrectly. The tag rendering between the <a> </a> renders fine.

11

I have opened up an issue on the Fred Github with screenshots for clarity. View issue and images here: