Display code blocks

[sottwell]

I’ve always used the FixedPre plugin and its

  `<pre><fixedpre>...</fixedpre></pre>`

tags to display code on a page. This isn’t working as a Fred Element, the fixedpre tags are removed in the final results, which can have unfortunate effects on rendering the page.

The HTML tags are converted to entities and the entities are output instead of the tags, and the MODX tags are left as-is, so MODX tries to process them as usual, which doesn’t work too well if you’re displaying code with MODX snippet calls.

How do we display code blocks, with HTML and MODX tags displayed and not rendered?

[bobray]

Do you use pre tags as well? If not, that might work better:

<pre><fixedpre>
/* code */
</fixedpre></pre>

[sottwell]

That’s exactly what I did.

[sottwell]

Until I can display HTML and MODX tags in a code block, I can’t use Fred.

I have tried every variation on pre and fixedpre and code tags that I can think of, and it still converts HTML tags to HTML entities and displays that, and runs MODX snippets, either causing a loop or a bad gateway error.

[sottwell]

This is what it should do
https://c0281.paas1.ams.modxcloud.com/testing.html
But this is what it does - and it tries to process a menu snippet, causing infinite loops and 500 server errors.

Building a Site Part Two - The Template - Learning Fred

[bobray]

What if you just put the fixedpre tags around the MODX tag instead of the whole thing?

[sottwell]

How can you do that in a Fred Element’s markup? This should work, it’s the code I’ve always used. But Fred stores HTML tags as HTML entities, which get displayed. And some MODX tags appear to be displayed without being processed, while others, such as pdoMenu snippet tags, are obviously being processed, resulting in a long line of errors about bad link tags, or even server 500 errors.

<pre data-fred-name="code"><fixedpre>Put code here</fixedpre></pre>

That element with a pdoMenu snippet to display will result in a Bad Gateway server error when trying to preview the page.

[sottwell]

I had thought that I needed to give the FixedPre plugin precedence over the Fred plugin, but it doesn’t use the same events. And Fred is converting HTML tags before saving anyway, as well as adding br tags, so pre can’t do its job of reproducing exactly what was entered.

[sottwell]

If I view the block after logging out, it displays as in the first post. However, when I log in and view the page through Fred again whether in edit mode or preview mode, it displays exactly as entered, just as pre and fixedpre should do.

[sottwell]

Bottom line here, I am at a loss. Perhaps there is something I can do with an Option set to tell Fred to not convert the HTML entities?

[bobray]

I’m not much help here since I don’t use Fred (though I have nothing against it). Since it looks like all the issues appear to be direct replacements of what you want there, it should be possible to create a late-running plugin that only runs on some pages and translates things into what you want if they’re inside pre tags.

I’d like to think there’s an easier solution, though.

[sottwell]

Well, frustratingly enough, the fixedpre part of allowing MODX tags to be displayed and not parsed appears to have suddenly begun to work…I have no idea why.

<pre data-fred-name="code"><fixedpre>Put code here</fixedpre></pre>

Now all I need to do is figure out how to keep Fred from converting HTML tags into entities and all line returns into br tags - in other words, trashing the pre tag’s content. There should be a setting or an option setting for that, but so far I’m not finding anything. I can’t find where it does that in its code, either.

Oops… it worked for a few page views, then stopped working again.

[sottwell]

I wonder… @bobray, could it be possible that fixedpre needs to be using other events with Fred?

[sottwell]

I’m beginning to think that fixedpre is in fact doing what it does, but then Fred is saving it that way, and then when viewing again after logging out, fixedpre is already gone, and things get confused.

[sottwell]

What’s especially frustrating here is that the Fred docs specifially mention code blocks as an example of element categories. So somebody must have some idea how to display code.

[sottwell]

I think I’ve figured out what’s going on. It’s not Fred, exactly, it’s fixedpre sometimes being invoked and sometimes already having been invoked and so not in the source any more.

Perhaps use one of the Fred events to have fixedpre reverse what it has done, perhaps the FredOnBeforeFredResourceSave, so that it will always get saved when editing with Fred, with the original content and fixedpre still in place.

[matdave]

To fix this I just leached into TinyMCE’s code editor. If you want an element that is ONLY a code sample you can create a new Tiny RTE Config in Fred called “code” and put the following values in:

{
  "theme": "inlite",
  "inline": true,
  "plugins": "code",
  "selection_toolbar": "code",
  "extended_valid_elements": "fixedpre"
}

Then you just need to assign that RTE Config to your element:

<pre data-fred-name="code" data-fred-rte="true" data-fred-rte-config="code">
 <fixedpre>Put code here</fixedpre>
</pre>

Now you can just hit Tiny’s code editor to insert actual code.

If you want to include fixedpre and a code editor in your regular TinyMCE config, you can create an RTE Config called “TinyMCE” and give it the following value:

{
  "theme": "inlite",
  "inline": true,
  "plugins": "modxlink image imagetools media lists contextmenu code codesample",
  "insert_toolbar": "image media quicktable modxlink codesample",
  "selection_toolbar": "bold italic underline codesample | alignleft aligncenter alignright | bullist numlist | modxlink h2 h3 h4 blockquote | code",
  "image_advtab": true,
  "imagetools_toolbar": "alignleft aligncenter alignright | rotateleft rotateright | flipv fliph | editimage imageoptions",
  "extended_valid_elements": "fixedpre",
  "auto_focus": false,
  "branding": false,
  "relative_urls": false,
  "image_dimensions": false,
  "force_br_newlines": true,
  "remove_linebreaks": false,
  "codesample_languages": [
    {
      "text": "HTML/XML",
      "value": "markup"
    },
    {
      "text": "JavaScript",
      "value": "javascript"
    },
    {
      "text": "CSS",
      "value": "css"
    },
    {
      "text": "PHP",
      "value": "php"
    }
  ]
}

[sottwell]

Looks good. Thank you.