My apologies if this created extra work for you. Could you please send me a link of the threads that need reformatting? I tested and refined the formatting conversion code many times over several months to try to get it right, and I even reported quite a few bugs that the developer fixed in a third-party text format conversion tool that was plugged into the importer. But I’m sure there are a few quirks and edge-cases here and there.
Thanks ToyKeeper for the HTML and Markdown tips, as I was not familiar with those.
The Discourse Forum Engine seems to compress white space so that there is never more than “one blank line” no matter how many “carriage returns” I type.
I sometimes prefer “two or more blank lines” instead of “one blank line” between unrelated sections of my posts for clarity and discovered that inserting the four characters “<br>” will insert blank lines that do not get compressed out.
Note: In the above sentence, I had to precede the “<br>” characters with a “\” character so that it displayed as “<br>” instead of inserting a blank line.
1 Thank
Hi @roostre , that’s correct. You can use:
</br>
Another option is a backtick with a space followed by another backtick, all on its own line:
` `
Seems to work.
1 Thank
The threads look fine but when I go to edit them a lot of html code is revealed, to the point where it looks like page source code, and I think most of it is unnecessary, so my plan is to remove most of the html code and use markdown as needed.
The Old-Lumens contest archive has a lot of code to refine but the 10th annual O-L challenge thread only has a little. The 10th annual challenge thread may be used as a template for future contests, so I want it to be perfectly formatted.
Also, I tried a few things but could not get the countdown timer to display in the challenge thread.
Thanks! I tried a few variations and nothing produced a table, so I figured that part of Markdown wasn’t included in Discourse. But it looks like it was just ignoring Markdown there because it was inside of some HTML tags. It seems to adjust syntax locally based on contextual clues.
For example, the interpretation changes depending on whether something is inside a HTML blockquote vs being inside a Markdown blockquote:
Markdown inside HTML:
*hi there*
Markdown inside Markdown:
hi there
HTML inside HTML:
hi there
HTML inside Markdown:
hi there
So if something isn’t working, check to make sure it’s not inside of some HTML tags, because HTML turns off the Markdown parser.
1 Thank
Thanks for your time tweaking those. I think this will help you to convert the HTML into Markdown:
https://pandoc.org/try/
Paste in the HTML, set the from language to “html”, and the to language to “gfm”, and click Convert.
If there are sections that don’t convert correctly with the above tool it’s probably because my conversion script intentionally removed some of the HTML tags to make those parts display better in Discourse by default (without manual editing). Basically when the HTML tags are removed it will render those parts of the post such as images and videos using the Discourse engine’s automatic embedding method. So what you could do there is select the entire post in normal view mode (not clicking the Edit button) and use your browser’s “View selection source” option, and paste that into the Pandoc converter as described above.
1 Thank
Yep, that’s the reason. It doesn’t do mixed mode rendering, if it finds HTML then everything inside those tags will be treated as HTML with no additional rendering filters applied. For example, in the old forum <p>http://example.com</p> would still get linkified because an additional filter ran after the HTML was processed, but Discourse doesn’t.
@ToyKeeper Actually I was thinking that Discourse had a table builder button in the post editor by default, so thanks for bringing that to my attention, I need to add that for sure.
It honestly looks quite good to me. The major difference now compared to the original rendering is that it shows the overview images directly instead of just an HTML link to the image for that year. Actually no, the original version also showed the overview images directly. It could probably benefit from some proper ## Headings but that would be easy to add.
Unfortunately, that’s going to happen if you used the advanced post editor on the old forum and now want to edit those old posts on the new forum. That pretty much throws you right into the deep end. 
Also unfortunately, the advanced editor didn’t attempt to output human-friendly HTML, so it tends to come out as a big wall of text. That can be improved by pasting it into pretty much any code editor and having it auto-format the markup. Some automatic search-and-replace can help too, to remove attributes the new system doesn’t allow.
I use a command-line code “beautifier” called pup for this, but I’m pretty sure that’s not what you’re looking for. An online tool like sb linked is probably a much better choice. Just make sure to back up the original post into a file first, before you start processing it.
Markdown would be easier, but there’s no foolproof way to convert the advanced editor’s data into Markdown… because the old editor allowed a bunch of things which simply aren’t possible in Markdown. So either you’ll have to edit it as HTML, or do a lossy conversion.
Yeah, that’s probably not going to work in the new forum. It explicitly forbids cross-site scripts and other advanced trickery which worked on the old forum. Drupal allowed almost any HTML with no restrictions, but Discourse only allows a pretty limited subset of the full language. So, no mouse-overs, no javascript widgets, no embedded stylesheets, etc.
Any time you see a style="foo" or data-darkreader-inline-color="bar" or anything like that inside a HTML tag, Discourse is going to pretend it’s not there. May as well strip all those out with search-and-replace.
Anyway, it’s no fun getting tossed into the deep end… straight from a GUI to a wall of code. I’d love to tell you there’s an easy solution, but I don’t think there is.
1 Thank
@ToyKeeper and @Hoop
Another option for wrangling HTML from the old “Advanced Post Editor” is here:
And yes, as TK mentions, the old “Advanced Post Editor” generated some atrociously messy HTML. And also some of the manufacturers would paste in their new products directly from their catalogues with similarly dreadful HTML. So for the conversion I actually ran the “Advanced Post Editor” posts through the same converter I mentioned above, but in html -> html mode to clean it up and “beautify” the code a bit.
1 Thank
I wrote up a post with some code examples about issues related to uneven line spacing, then posted it. Some of the spacing issues visible in the PREVIEW pane were not present in the final submitted post.
This means that the “preview” window is inaccurate in some ways. It can’t be relied on to determine proper line spacing in a post.
For example, if you put an image in the editor, it will appear in the window on the right, and there will appear to be a <br> width gap after that image and any text which follows it. Then when you post, there is no gap… (No line break.)
This was the post:
I am editing the Old-Lumens contest archive thread now and I’ve noticed a few things:
Uneven line break spacing:
-The vertical height of the line break (the empty gap) when “return/enter” is used in the editor is not the same as when <br> is used. Return/enter seems to create the same gap as <p>.
-After an image appears in a thread there is an automatic line break added to the text which follows, and it seems that this line break cannot be removed, and this break is the <br> height, which is different from the return/enter line break spacing. This causes uneven spacing unless <br> was also used before the image.
Examples:
Return key used in editor:
LINE1
LINE2
LINE3
<br> used:
LINE1
LINE2
LINE3
<p></p> used:
LINE1
LINE2
LINE3
From those examples it seems clear that the editor creates <p></p> spacing when the return key is used.
Image spacing examples:
- No
<br>or<p></p>used:
TEXT PRECEEDING AN IMAGE
https://i.imgur.com/cgSU8WC.jpg
TEXT SUCCEEDING AN IMAGE
Result:
TEXT PRECEEDING AN IMAGE
TEXT SUCCEEDING AN IMAGE
- A line break added by using return/enter in the editor:
TEXT PRECEEDING AN IMAGE
https://i.imgur.com/cgSU8WC.jpg
TEXT SUCCEEDING AN IMAGE
Result:
TEXT PRECEEDING AN IMAGE
TEXT SUCCEEDING AN IMAGE
-
<br>used before the image: (this appears to result in equal spacing)
TEXT PRECEEDING AN IMAGE<br>
https://i.imgur.com/cgSU8WC.jpg
TEXT SUCCEEDING AN IMAGE
TEXT PRECEEDING AN IMAGE
TEXT SUCCEEDING AN IMAGE
-
<p></p>used before the image:
<p>TEXT PRECEEDING AN IMAGE</p>
https://i.imgur.com/cgSU8WC.jpg
TEXT SUCCEEDING AN IMAGE
Result: (no image appears and the succeeding text is not on its own line)
TEXT PRECEEDING AN IMAGE
https://i.imgur.com/cgSU8WC.jpg TEXT SUCCEEDING AN IMAGE–It is evident that line breaks need to be added using the post editor (return/enter) or the code doesn’t work. This is necessary with other tags too, not just in the case of the <p> tag.
Here it is again when adding a (return / enter) line break after the <p> tag:
<p>TEXT PRECEEDING AN IMAGE</p>
https://i.imgur.com/cgSU8WC.jpg
TEXT SUCCEEDING AN IMAGE
Result: (appears identical to the 2nd example shown where return/enter was used instead of <p>)
TEXT PRECEEDING AN IMAGE
TEXT SUCCEEDING AN IMAGE
-It may be the case that <p> is relatively useless and just causes problems, since the editor creates the same line break when return/enter is used.
-Since return/enter is sometimes necessary to make code work properly, and since it introduces a <p> gap, this will create uneven line spacing in certain cases, such as when it is sometimes necessary to make <b> work properly.
Furthermore:
-The line break spacings (vertical gaps) in the LEFT window of the editor do not match the spacing shown in the right window, for example with the return/enter line break is used. This makes it slightly more confusing when editing, and scanning from left to right. The effect of this is compounded when tags like <br> and <p> are used, and especially if those tags are used AND the return/enter key break is used, which as established earlier in this post, is necessary to keep certain tags from breaking. The use of return/enter effectively adds a <p> break gap, affecting the spacing in the post.
-The WIDTH of the two windows (editor LEFT, preview RIGHT) are not the same either, so paragraphs of text appear differently from one window to the next, even if no line breaks of any kind are used. This also makes it more difficult to just scan left to right and find one’s place in the post.
Suggestions:
-It would be nice if there were not a forced line break after an image. Then the user can generate their own break using either return/enter or <br> without being forced to use a <br> break before the image in order to create even spacing.
-I believe it would be better if hitting return/enter more than once actually resulted in more than one line break being generated. Using <br> would not be so necessary then.
-If the EDIT and PREVIEW windows were the same width, such that a typical paragraph kept the same words on the same line, this would make left to right scanning easier. The two windows are nearly the same width as is, but not quite.
So all of the aforementioned is still true, but some of it is true in regards to the post editor’s preview window, and not the final resulting post.
The major difference being that in the final post, there is no longer a <br> break inserted after the images. That gap is an inaccuracy which is only present in the preview window of the post editor.
1 Thank
Unread posts stopped working for me.
Thanks a lot @Hoop for testing that, I’ll try to reproduce it to see if there’s any rhyme or reason for it doing that or if a bug needs to be reported.
Please check this list of the threads you’re watching/tracking:
https://budgetlightforum.com/search?expanded=true&q=in%3Atracking%20order%3Alatest
If a thread isn’t set as Watched or Tracked then it won’t appear in the “Unread” tab when it has new posts. New threads that you haven’t read will appear in the “New” tab.
I like to view all threads sorted by most recent post. It’s helpful if there is a way to go to the first unread post. Like the old site.
Hi there, that’s the way it works by default now as well.
How different is the width? I’ve tried a bunch of different window sizes, shapes, and zoom levels, and the two windows stayed really close to the same size.
Looking into the stylesheets, it looks like they’re laid out in a “flex” arrangement, which attempts to keep them the same size… but the result is slightly off. I can adjust the relative sizes by changing the flex weight for each, but this tends to skew with the window size… so if I make it look right in a 800px wide window, it’s off-center in a 2400px wide window (and vice-versa).
Regardless, it appears to do okay if I give it a correction factor of 1%, maybe as much as 1.5%. This reduces the difference and doesn’t skew enough to become worse than the problem it’s trying to fix. So I put that into my stylesheet overrides for the next batch of updates.
I also reduced the padding a bit on the editor window, to make its contents closer in size to the preview.
However, some things aren’t really fixable. Like, one line in the editor (like an image) can turn into a large object in the preview, and vice-versa. So some things are going to stay out of sync.
Other things probably are fixable but it’s not clear that the result is desirable. Like, a line of text is 1em tall. A <br /> tag in the editor adds a blank line which is also 1em tall. However, a blank line in the editor splits the previous and next text blocks into different <p></p> paragraphs, and inter-paragraph spaces are frequently not 1em. Like, in my themes, that’s a 0.5em margin. The smaller gap allows more text to fit onscreen, but that’s not its primary purpose. It’s mainly to improve readability and make things look more natural. Setting the paragraph margin to 1em would make spacing more consistent but not necessarily better.
1 Thank