I've added in a processing filter for MARKDOWN and CODE in forum posts and comments sitewide ("Filtered HTML" text elements only). Note that only specific elements of MARKDOWN are supported (there are about 10 different competing versions of MARKDOWN and the Drupal extension supports a specific one with only some elements) and are then fed through the allowed HTML filter bits after. So, no tables or quick hash for code as they are incompatible.
I also added in a CODE extension which allows you to use <code> tags to put your code in and will automatically escape most things within them. This should make it easier to post code snippets. Note that there is no Drupal 8 version of this extension, so this could break on future site upgrade, but we'll hopefully address it before then.
UPDATE: Markdown has been split out as a separate Text format for trying things out. Switching to a simple WYSIWYG editor with just the basic tags we support is also being considered which would eliminate the need for HTML or markdown.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
This is certainly a step forward in the right direction.
Thanks for listening to my suggestion.
daemon.devin
I'm waiting to see if there are any performance issues with it tomorrow when the main userbase hits the site. It's the primary reason I haven't installed it until now. It's used for all page generation on comments and forum posts in addition to the other 6 filters.
Side note: Personally, I dislike markdown. It's not standardized, supported haphazardly in most sites/add-ons (including the one we're using) and far more people are familiar with HTML than markdown. So we'll see if folks use it. Ultimately, it's down to how well it works for most folks regardless of my own personal dislike of it.
Sometimes, the impossible can become possible, if you're awesome!
You're doing the right thing John. I can see why you feel that way about it and I completely get it. It's proven successful with GitHub and Stackoverflow (even though they use different variations between the two.. lol) but setting aside your own personal preferences for the greater good is admirable; even if it's for just a testing period.
daemon.devin
It's 'testing' more for performance than usage. Even if just a handful of devs find it useful and it helps them do their work better, I'm fine with it. I just want to make sure it doesn't impact site performance, because I can't afford a better hosting plan.
Sometimes, the impossible can become possible, if you're awesome!
What's this sites current average statistics as far as growth goes? Are you factoring in future spikes in users/bandwidth? I only ask because I've been actively supporting your PA.c brand here all over the internet on a lot of forums and other websites and I know I cannot be the only one doing this. My website, which supports and backs your portable brand has been gradually getting new visitors daily (an average of 3-5 unique new visitors a month; small but rising nonetheless) and my PAF GitHub projects are growing in unique views as well. This means your site has got to be on the rise and if I'm correct than your site here will be much bigger the next few years. Might be something to think about.
daemon.devin
I would think that one should have to choose "Filtered HTML" or "MarkDown", as opposed to having it accept MarkDown in the "Text format" labeled "Filtered HTML".
As an aside, I personally have a bit of a 'love/hate' relationship with MarkDown, as I liked the
\*this is bold\*,_this is italic_that GMail's built in chat system uses (or at least used to, I haven't used it much in a long time), and it's similar, but I dislike the\*italic\*,_italic_,\*\*bold\*\*,__bold__system that MarkDown uses as it feels much less clear to me. Also there are other things I like & dislike about it, and the fact that it's such a haphazard mess of "standard"s under one name instead of one, actually standardized standard is a big mark against it, though "CommonMark" is working to fix this.On another note, the MarkDown interpreter seems to be reading the asterisks and backticks (as everyone seems to call them these days), but interestingly not underscores, inside <code></code> blocks, so I had to escape them with a
\. Is this how it's meant to be working?Edit: Typographical errors.
~3D1T0R
This is the way it works. You have to select Markdown before Filtered HTML otherwise people will be able to create tables in comments and mess up page layouts and no HTML filtering will be enabled at all. There are no options to select which markdown tags are allowed or not or which interpretation of many of markdown it will use. It's a single add-on with no options. Same with the CODE blocks. The markdown filter messes them up a little. There are no options to fix it.
Sometimes, the impossible can become possible, if you're awesome!
Sorry about going on a tangent or two there, but my main point was that I think accepting MarkDown syntax in a "Text format" labelled "Filtered HTML" is a poor choice. I would personally prefer to have a new "Text format" labelled "MarkDown" or something like that, which accepts MarkDown instead of HTML.
At the moment, below the comment input textbox I have a drop-down menu containing "Filtered HTML", "Full HTML (Pages Only)", "HTML for Devs (project pages only)", and "Plain text". Obviously "Full HTML" and "HTML for Devs" aren't available to everyone, but "Filtered HTML" and "Plain Text" both are, so my suggestion is to add a new option in the "Text format" list called "MarkDown" (or something similar), and allow MarkDown usage there instead of mixing it in with "Filtered HTML".
Also, a separate idea: Since most posts are only text anyway, would making "Plain text" the default possibly help to improve performance?
~3D1T0R
It would still work the same as we can't have markdown without then running it through Filtered HTML. Otherwise we wind up with tables and junk destroying page layout as well as external image links breaking HTTPS and possibly linking to NSFW, illegal, or corrupted images with overflow code built in. The only thing this would gain is to ditch the collision between CODE and markdown since CODE would only be on Filtered HTML
Sometimes, the impossible can become possible, if you're awesome!
Is there no possibility of a "Filtered MarkDown", which filters out the things you mentioned, but doesn't accept HTML?
I personally would still prefer to keep MarkDown seperate from the existing "Filtered HTML" Text format, and I think that would help deal with the performance hit, as people should only switch it to "Filtered MarkDown" if they're actually using MarkDown.
~3D1T0R
The Markdown add-on has no options. You can't pick what you want. You remove things by running the Filtered HTML filter afterwards as mentioned in the Markdown add-on's documentation.
I've separated out Markdown to its own Text Format. Not sure how discoverable it'll be to most users.
Sometimes, the impossible can become possible, if you're awesome!
To make it more discoverable, you could add a line to the description of whatever text format you set to be the default mentioning that there are other option(s) available. This would be particularly effective if you put such a line at the top, and especially if "Plain text" was the default, as people wanting to add formatting will likely look there see that the first line about text formatting is telling them to choose either HTML or MarkDown from the "Text format" options, then they'll choose whichever one they want. This would also make for an interesting test, as you could potentially use such a system to see which people tend to prefer too.
~3D1T0R
I'm also considering enabling WYSIWYG instead. That would allow the site to automatically generate the basic HTML and then users won't need to know HTML or Markdown or worry about switching formats. We'd start with something like CKEditor's basic toolbar with code snippet active and add in any specific buttons for things we use.
Sometimes, the impossible can become possible, if you're awesome!
Are you looking at this module? It's apparently included by default in Drupal 8, so that's fairly promising.
~3D1T0R
I'm looking at that one because it's the most widely used and because it's the default in Drupal 8. Similarly, I'm looking to CKEditor because it's also the default in Drupal 8 (and because it's widely used, actively developed, and very customizable. I use WYSIWYG+CKEditor in several of my own sites already, including for actual page edits, not just comments, and it works quite well.
Sometimes, the impossible can become possible, if you're awesome!
Hi John,
What about moving to Discourse Framework (https://www.discourse.org/)?
Wouldn't that make things easier for you?
Thank You.
Right now we use Drupal's built-in forum and comments with some custom stuff applied. Bolting on an entirely different system is messy.
Sometimes, the impossible can become possible, if you're awesome!
I've disabled the CODE add-on as it's breaking all line breaks for some reason. I'll keep working on it.
Sometimes, the impossible can become possible, if you're awesome!
I tweaked the PRE tag to make it scrollable again. Max height is 400px at the moment. Not sure if that's ideal or not.
Sometimes, the impossible can become possible, if you're awesome!
That looks like a good height.
I regularly review threads from my phone and this height allows me to scroll past long PRE sections if needed, in a single scroll, depending on my phone's orientation.
That's about what I was going for. I was a bit worried it was a tad too tall.
Sometimes, the impossible can become possible, if you're awesome!