text/plain email notifications do not render the `@` in front of mentions

[TimWolla]

trafficstars

A post like:

@test test

will render as:

test test

It works fine for the text/html version.

[TimWolla]

This is non-trivial, the UserBBCode is not being executed for text/plain outputs (or rather: no BBCodes are executed for text/plain) outputs. This is due to the following:

https://github.com/WoltLab/WCF/blob/6bc9841ff3ef744357d5162f77a56e960fd42f52/wcfsetup/install/files/lib/system/html/output/node/HtmlOutputNodeProcessor.class.php#L180-L184

These lines will remove the <wcfNode-…> elements that are later required in here to re-insert the BBCodes:

https://github.com/WoltLab/WCF/blob/6bc9841ff3ef744357d5162f77a56e960fd42f52/wcfsetup/install/files/lib/system/html/node/AbstractHtmlNodeProcessor.class.php#L120-L146

[dtdesign]

I'm not sure that we can fix this at all. The BBCodes are somewhat flawed in that they are very limited in their scope and for the most part do not deal with different output types at all. The entire workflow of BBCodes is strange for historic reasons (returning a HTML string instead of DOM nodes) and while we can target the user BBCode itself, there is always that one BBCode that will still be broken.

Maybe we should consider establishing a new concept that is aware of the output type and forces the developer into specialized code paths. For example, getHtml(): string, getPlainText(): string and getSimplifiedHtml(bool $allowInteractiveContent): string ($allowInteractiveContent = false would be suppressing things like <a>). We would still run it through a draconic filter, but at the end of the day the BBCode author could gracefully handle those cases.