Users are discussing an issue where images fail to display correctly in tables due to Discourse inserting a | symbol between the filename and dimensions, which breaks the Markdown syntax. biminiroad initially suggests deleting the | as a workaround, noting it’s unintuitive for beginners. Falco offers a better solution: escaping the pipe with \|, which preserves the ability to resize images — e.g., . biminiroad confirms understanding and plans to update their forum tutorial. codinghorror adds that image dimensions are optional but omitting them may cause layout instability. sam and Vitaly explain this is a known limitation: tables are parsed at the block level before inline elements like images, per GitHub Flavored Markdown (GFM) spec. Vitaly notes this behavior matches GitHub and is unlikely to change, as it’s a niche case with a viable workaround. The thread ends with appreciation for Discourse’s capabilities compared to older platforms like Vanilla.
Our forum uses tables to describe the function of digital synthesizer modules. In the first column, we use a picture. Because Discourse inserts a | between the file name and resolution, it breaks the link to the picture when using it in a column.
The solution is you have to delete the | symbol. Not a big deal, but also not intuitive for beginners.
Meter | Displays
---|---
 | `Pattern`
Sure, but you can also just delete the | as well. I’m personally not super versed in code so I had to puzzle through this at first.
Perhaps it’s not worth changing, I just thought maybe no one was really using pictures in tables and no one had come across this before. Not a big deal, I made a note of it on a tutorial about tables on our forum.
Maybe if I get this right, if the picture doesn’t load, it would say “Meter-Pattern” with your \ solution and “Meter-Pattern108x108” if you did it by deleting the |?
I will amend the advice on the forum to reflect this. Thanks a lot! I’m so psyched about the powers of this new forum. We were struggling on an old version of Vanilla that didn’t even have bold text. Yeesh.
Agree, very interesting edge case. If we give up allowing , in title for images we can work around it but I wonder if this is a bug @Vitaly in the ordering of the table processing in the pipeline (maybe we should process images prior to tables)? (see OP)
Table is parsed on block level. It can’t jump to inline mode before it detects cells layout. So, it only process backticks and escapes.
Since tables are not part of CommonMark spec, we follow GFM spec. You can check, github behave the same way.
In short: currently all backticks and pipe chars inside tables MUST be escaped.
If you wish different behaviour, you need to ask github guys to update spec. But, personally, i’m not sure if good resolutions possible at all on spec level. IMO this case is very specific, has workaround, and does not worth efforts to be spent for spec/parsers rework.
