Quote context impacts functionality of quote

I have users who edit their quote syntax poorly and cause the quote function to fail. For example we have this one from a current topic. This is un-escaped:

[quote=“CFO.Digest.Input, post:1, topic:3258”]
he suggested that I put mineral oil back in. [/quote]

The problem is that the /quote is in stream, while the opening quote is on its own line. I have found that you can do either, but they must match. For example this works (’ added to escape the function):

'[quote=“CFO.Digest.Input, post:1, topic:3258”]
he suggested that I put mineral oil back in.

and this works:

'[quote=“CFO.Digest.Input, post:1, topic:3258”]he suggested that I put mineral oil back in.[/quote]

… but you can’t mix the modes.

I know someone will say “then don’t do that” or “Use the quote button” but we still have users out there who won’t do it right.

Isn’t there a way to parse this so the modes can be mixed?

1 Like

This was a conscious change a few years ago:


Oh my… so we’re basically enforcing coding standards on our customers and users?

While I agree with Sam’s analysis of the format, there is a difference between being difficult for the writer to read and difficult for everyone viewing the post to read. Kinda seems like we’re punishing the readers for the sins of the writer…

Guess I’ll plan to keep editing posts when people mess them up.

Edit: Another option would be to force a line feed after the [/quote] if there isn’t one there… auto-edit the format for readability.


That doesn’t seem like a bad idea, but if they just select text and use the quote button it works. They are going back and editing the quote and breaking the formatting?


Yes they are! Quite remarkable, really… and not noticing that they are breaking the format in the process. I guess they don’t have the preview up? Or may be doing it by mobile…

And the person who did this one of the principles in the business… glad I didn’t make him an editor! :slight_smile:


Aha! Mobile is a good bet. It’s hard too select just right and then you’d be ham-handed and have no preview when you tried to “fix” it.


This is still a recurring issue in my system. Here’s a message which came up today:


I edited the post with a carriage return after the closing quote tag, but still find it surprising that the text stream isn’t parsed like HTML where line feeds and carriage returns don’t impact the functionality of the tags. Seems like a bug to me…

No, that’s how the tags work. You can’t randomly insert them in random order and expect things to work.

The order isn’t random, it is just fine. But unlike HTML, in this system is matters where the linefeeds happen to fall.

All it took to fix that broken post was adding a line feed / CR after the closing tag.

I’m willing to keep manually editing posts when users fail to comply with the required structure, but it still seems strange that line feeds should matter to the parser…

Take a look at the markdown spec. Unlike HTML markdown is entirely dependent on well-placed line breaks.

An errant line break in an <h1> element wouldn’t have any impact on rendering, but:

here in markdo

wn world it does

This is true for lots of elements, markdown tables are horribly broken by additional line breaks. HTML tables OTOH are not.

I’m not sure the HTML analogy sticks or is useful, users aren’t being asked to write HTML, can you imagine the pain of missing <p></p> and <br>? Literal walls or text.

If you think “markdown first” which Discourse is, rather than “HTML first” which Discourse absolutely is not, then the challenges presented by throwing tags in without respecting structure begin to make sense.

1 Like

I’m fine with navigating these waters, like any coder, but our users are civilians and would think markdown has something to do with prices at Walmart.

As you say, thankfully we’re not asking them to write HTML! What is gained by forcing them to implement markdown formatting? Seems like a small bit of coding cleverness would insulate them from those realities of our world.

I don’t know how complicated it would be to automatically force a new line after a [/quote] (as long as it’s not in a codeblock or something like that…) and I understand that there is a structure to observe when using markdown.

But I also understand how frustrating it can be when a malformed quote appears in a user message because of such a tiny “mistake” that it is to write text on the same line that a [/quote] (not sure I can call that a mistake).
Is there any purposeful case where text would be written on the same line as a [quote]?
If there isn’t any, then I feel there is no reason at all for a text to exist on the same line and a forced new line after the closing quote tag could be beneficial for both users and staff. But I’m also sure that this is not as simple as it seems.

Right. The basic nature of markdown is that a newline (or two newlines) is the same as paragraph tag. Because of this, some tags require newlines before or after them to be properly interpreted. It’s part of the spec, I believe.