Code formatting still messes up the code

If I use the code tags the result contains some weird additional visible tags like “[crayon-5f4e12375f580387562191 inline=“true” ]” at the beginning of the code block or & # 0 3 9 ; instead of a single quotes.

Here is an example:

Yes, I think there is an issue between TinyMCE and Crayon. TinyMCE always encodes entities according to current HTML and XML specifications. >, <, ", and are stored as their Unicode equivalents when a post is submitted (saved to the forum database).

When the post is then displayed on the forum the stored text is interpreted by the web browser for display. In normal text blocks, the Unicode strings are converted to their respective characters and you see them display correctly. However, in Crayon blocks the conversion is disabled (for the sake of displaying code literally), so you just see the Unicode that TinyMCE stored that character as.

Technically, both TinyMCE and Crayon are working as intended… but not the way we want.

For some reason I don’t understand yet, some posts using Crayon end up with both pre and code tags surrounding the same block, which produces the [crayon-###…] strings. To make matters worse, the problem doesn’t show up in the normal forum editor. If you click “Edit” on your post it looks like this:
(the code is enclosed in backticks)
However, if I edit the post through the WordPress Admin Control Panel it looks like this:
(the code is enclosed in both pre and code tags)
Every time I find a post that has the [crayon-###…] string it has this problem.

Crayon is actually a dead project, but unfortunately the alternatives have their own custom tags for displaying code rather and don’t use pre or code, which would mean breaking code display in all of our old posts.

Also, it seems the forum no longer displays gists automatically.

Hmmm … thanks for the explanation. Is there a way around it? Is it better not to use the available buttons of the post editor and add the tags manually? If yes wich ones? Would you recommend using the text view or the visual view?

Personally, I write my posts in the “Text” view, which seems to produce fewer differences between how I intend the post to display and how it actually displays. I type out my tags manually.

I did a lost of testing in this thread:
and there is a solution for the HTML entity decoding. If you add the attribute decode:true to the opening pre tag like this:

pre class="decode:true"

it will decode HTML entities to their characters. This is demonstrated in Test 7 in the testing thread.

You can do this manually by typing out the tag, or you can use the Crayon dialog.
In the “Text” editor, clicking the Crayon button will bring up the dialog. There are a lot of options in here, but you don’t have to change them. If you write your code in and click “Add”, it will set HTML decoding by default.
In the “Visual” editor, there should be a button to the right of the Redo button that looks like <>, which brings up the Crayon dialog. However, I’ve found that display of this button is inconsistent - sometimes it’s just not there. I don’t know why. In any case, the Crayon button is always available in the “Text” editor.
Don’t use the Format -> Code or Format -> Blocks -> Preformatted options in the “Visual” editor.

Also, James has clarified that we are not using the original Crayon Syntax Highlighter that is no longer under development. We are using this forked version which is being actively developed.
It has several nice features that you can use, some of which I’ve demonstrated in the testing thread. For instance, you can apply a theme (from these choices) and a title, and highlight specific line(s), as in Test 1. You can specify different coding languages (from these choices) if you need to, and also the automatic language recognition built into crayon seems to work quite well. If you want to display code samples from other websites you can link them as shown in Test 6 - this works for displaying gists. Other features are (mostly) documented on the github page.

Note that the code tag does not accept attributes and therefore cannot be set to decode HTML entities. It’s convenient for in-line code, but it won’t display > and < correctly and may or may not display and " correctly. There’s no fix for this - if you need those characters use pre and not code.