Do the new line breaks have to stay?

browninc

I realize that, in general, it's a good idea for line breaks to be correctly interpreted as BR tags.

Unfortunately, that's not how it has worked for years, so there are hundreds—hell, probably thousands—of posts that have been hard-coded with BR tags to achieve the desired effect.

As a result of the recent change in the stylesheet or interpreter or whatever, all those BR tags now appear as double BRs—one for the line break and one for the BR tag.

You can't really think that was a good idea.

Either the new interpretation needs to go away, or you need to make it apply only to posts after the date the new interpretation was applied, or you need to offer a simple toggle to turn it off.

What are the chances of that happening?

Anonymoose

15 minutes to do a database dump, clean up, and reimport.

browninc

You mean ask the client's IT guy to drop everything so he can figure out how to do that and then do it and then wait while I go through hundreds or thousands of posts (assuming I can search the database for posts containing BR tags) and analyze every single BR tag to determine whether it's needed and remove the ones that aren't, and then replace the entire archive in the hope that everything will go without a hitch?

Yeesh.

Bleistivt

These changes are only in 2.2 right now. If you are using non-stable releases, things like this are to be expected.

Either the new interpretation needs to go away, or you need to make it apply only to posts after the date the new interpretation was applied, or you need to offer a simple toggle to turn it off.

Looks like this is not configurable yet:
https://github.com/vanilla/vanilla/blob/fd6484796abd2af457ab0a62cbc463e1bd88886e/library/vendors/markdown/Michelf/Markdown.php#L495

Might be a good idea @Linc

What are the chances of that happening?

For the first 2, I'd say they are very slim. Vanilla converts Markdown to HTML on the fly, so the syntax will always be newly interpreted by the current parser implementation.

You mean ask the client's IT guy to drop everything so he can figure out how to do that and then do it and then wait while I go through hundreds or thousands of posts (assuming I can search the database for posts containing BR tags) and analyze every single BR tag to determine whether it's needed and remove the ones that aren't, and then replace the entire archive in the hope that everything will go without a hitch?

If you were using Markdown before, you would do a simple line break by inserting 2 whitespace tokens at the end of a line. These line breaks have not changed with the new markdown parser.

If you were using just "Html" as your Inputformatter, I believe it already implemented soft line breaks, but I am not sure.

Using Markdown and br-tags is definitely not recommended.

Anyway, you don't have to weed through every post, just regex-search for

<br ?\/?>\r?\n

and replace by \n on a SQL-dump of your posts and discussion table.

browninc

Thanks for taking time to craft such a thorough response, @Bleistivt! I appreciate it.

I don't know what version the client is running, but they do tend to like life on The Cutting Edge.

I think a toggle would be great. I "get" the logic behind this change (I'm always editing formatted posts that got glommed into a single giant paragraph) and applaud the effort put into it, but it seems like the two-space method was sufficient and just needed to be documented.

Thanks for the regexp, too. It's good to know I could use that to find all the instances of a BR tag, but I'd still have to analyze each one to decide whether it's needed.

Best regards!

Linc

hard-coded with BR tags

You wrote Markdown with hard-coded <br /> tags? As in, you manually typed in an HTML entity every time you wanted a line break for thousands of posts?

browninc

Ideally, the stable release that includes this stylistic change would also include logic to NOT interpret a line as a line break IF that line ends with a BR tag.

That way, this:

aaaa aaaa
bbbb bbbb

...and this:

aaaa aaaa<br />
bbbb bbbb

...would both yield this:

aaaa aaaa
bbbb bbbb

browninc

You wrote Markdown with hard-coded <br /> tags? As in, you manually typed in an HTML entity every time you wanted a line break for thousands of posts?

Well, not an entity but the BR tag, just as you've shown above. In my own posts and whenever I saw a post in which this:

aaaa aaaa
bbbb bbbb

...had been displayed as this:

aaaa aaaa bbbb bbbb

That happened to MANY members posting in the client's forums. They hated it.

Linc

@browninc said:
That happened to MANY members posting in the client's forums. They hated it.

The Markdown way of doing that would be to add 2 spaces to the end of the line.

You hated the default implementation, so you hacked it, and now that I fixed it to work the way you wanted, you want me to hack core to unhack your change?

Linc

https://github.com/vanilla/php-markdown/commit/4c8db6115abf8b3c6a265f6bfb2bc53d939a97b4#diff-8e95e3657c7e2d073d1d898e1c9239c6R3216

If you want to make it so that <br />\n parses as a single soft break, I'd accept that pull request.

browninc

The Markdown way of doing that would be to add 2 spaces to the end of the line.

You hated the default implementation, so you hacked it, and now that I fixed it to work the way you wanted, you want me to hack core to unhack your change?

@Linc, I'm truly sorry if I've offended you. That was not my intent, and I hope you'll allow me to explain.

Most folks—myself included, until very recently—don't know about the "two-spaces" method of indicating a line break. All they know is that the forum software was ignoring their line breaks. I hope you'll agree that it's among the least obvious aspects of Markdown syntax, and I've seen numerous complaints from members.

So, whenever I saw an original post that looked like a single giant paragraph, I fixed it. Not knowing anyone would make such a radical change to the forum software, I fixed it in the way with which I (as a relative newcomer to Markdown, especially compared to my HTML experience) was familiar: the addition of BR tags where members had placed line breaks.

As for rolling back the change, I honestly don't know the correct solution. While it pains me, as a person certainly more concerned than most people with layout, to think of the myriad posts that now have double-spacing where it's not appropriate, it is, after all, only a forum. We're not saving starving children, and having the forum software honor line breaks as entered will hurt no one and give many the results they expect.

Thanks to you and @Bleistivt having taken time to explain the change so well, I understand it and will happily accept your decision, either way.

Thanks for taking time to read this message!

x00

@browninc live an learn, but if you were to do it at all, you do with stuff on output.

Linc

My suggested change above would solve your problem while being benign to most folks.

browninc

Then, yes, please.

Thanks again for engaging with me on this topic!

wjcroft

Excuse me for posting on this old thread. In February 2015, @Linc stated:

If you want to make it so that <br />\n parses as a single soft break, I'd accept that pull request.

Was this fix to the parser implemented? I'm asking because I'm upgrading a Vanilla forum, that has been running 2.1.8p2, for 4+ years. (Sorry about this.) :-) Our forum contains thousands of posts that help our OpenBCI customers troubleshoot their hardware and software. (OpenBCI = open source brain computer interface.) Thus this forum contains posts that are valuable, regardless of how old. We need to keep access to the old posts.

The posts in that 2.1.8 database use the <br> tag exclusively and extensively, on every line break and also for paragraph breaks. Apparently in that vintage of Vanilla, <p> tags were not used. And generally no newlines are in the raw text created by posting on 2.1.8p2 either. All these <br> tags were created by Vanilla 2.1.8 itself, not manually added.

On a test server, when I access the current database and posts when running the latest Vanilla version, ALL the posts are double spaced. And of course paragraph breaks are quad spaced. Essentially this makes the port to the new version unusable. Pastes of text examples of code or error logs, everything, it's all double spaced.

Question:

Is it possible this fix that treated <br /> specially, could be applied to the plain <br> tags that are present in all our 2.1.8 posts? Can you point me to where this would be done in the source, suggesting the mod? So that I can temporarily tweek it here for testing. Regardless whether it makes it into you mainline repo.

Thanks much,

William Croft, OpenBCI Forum

[also mentioning @browninc and @x00 ]

wjcroft

Excuse me for posting on this old thread. In February 2015, @Linc stated:

If you want to make it so that <br />\n parses as a single soft break, I'd accept that pull request.

Was this fix to the parser implemented? I'm asking because I'm upgrading a Vanilla forum, that has been running 2.1.8p2, for 4+ years. (Sorry about this.) :-) Our forum contains thousands of posts that help our OpenBCI customers troubleshoot their hardware and software. (OpenBCI = open source brain computer interface.) Thus this forum contains posts that are valuable, regardless of how old. We need to keep access to the old posts.

The posts in that 2.1.8 database use the <br> tag exclusively and extensively, on every line break and also for paragraph breaks. Apparently in that vintage of Vanilla, <p> tags were not used. And generally no newlines are in the raw text created by posting on 2.1.8p2 either. All these <br> tags were created by Vanilla 2.1.8 itself, not manually added.

On a test server, when I access the current database and posts when running the latest Vanilla version, ALL the posts are double spaced. And of course paragraph breaks are quad spaced. Essentially this makes the port to the new version unusable. Pastes of text examples of code or error logs, everything, it's all double spaced.

Question:

Is it possible this fix that treated <br /> specially, could be applied to the plain <br> tags that are present in all our 2.1.8 posts? Can you point me to where this would be done in the source, suggesting the mod? So that I can temporarily tweek it here for testing. Regardless whether it makes it into you mainline repo.

Thanks much,

William Croft, OpenBCI Forum

[also mentioning @browninc c and @x00 ]

R_J

Can you post the database entry and the resulting html?

charrondev

@wjcroft we have definitely have a configuration setting for this. I won't track down the pull request but the configuration setting is:

$Configuration['Garden']['Format']['ReplaceNewlines'] = false;

I'm not 100% sure how this will affect your setup, but maybe that will help?

If not, then no adjustment to the parser was made. You're option would be some custom CSS to style around the line breaks however you see fit. You can easily target user content with the .userContent selector in 2.8.

wjcroft

Thanks very much @charrondev and @R_J . I will give the config setting a test shortly.

Here's an example of the raw html shown in the edit window when I select the html view ('<>' button), as a code quote. It contains zero newlines, but does have <br>'s:

Bill, Jps, Neutron, thanks.<div style=""><br></div><div style="">Check out some of the figures in this document,</div><div style=""><br></div><div style="">https://www.eeginfo-neurofeedback.se/fileadmin/images/was_ist_neurofeedback/wie_funktionierts/SCP_recording_electrodes_and_paste.pdf<br></div><div style=""><br></div><div style="">Although you are likely not doing slow cortical potential work, it does contrast the stability and noise of various metal types. Tin and steel are not the best for EEG. That honor goes to silver chloride.</div>

Pasting as a regular quote:

Bill, Jps, Neutron, thanks.<div style=""><br></div><div style="">Check out some of the figures in this document,</div><div style=""><br></div><div style="">https://www.eeginfo-neurofeedback.se/fileadmin/images/was_ist_neurofeedback/wie_funktionierts/SCP_recording_electrodes_and_paste.pdf<br></div><div style=""><br></div><div style="">Although you are likely not doing slow cortical potential work, it does contrast the stability and noise of various metal types. Tin and steel are not the best for EEG. That honor goes to silver chloride.</div>

And this is what the post looks like displayed by the 2.1.8 forum, pasted here as an image.

Comments appreciated. Thanks again.

William Croft, OpenBCI

wjcroft

Adam @charrondev and Robin @R_J , thanks for your previous comments.

Well, I tried Adam's suggested addition to my config.php,

$Configuration['Garden']['Format']['ReplaceNewlines'] = false;

However, it does not have any effect on the double spacing of the previous database posts that contain <br>'s to separate lines and paragraphs. (See actual html in my previous post above.) NOR does it have any effect when creating a new thread / post. On a new post everything works as before: the return key generates a new paragraph (double space). I tried generating a bare newline (linefeed, ascii 0x0a) character on my Mac keyboard. Next to impossible. I even tried entering using the Mac's Unicode Hex Input (alt key method), still could not generate a bare newline. I assume if my old database actually contained bare newlines, the switch that Adam gave would likely do the right thing. These are not likely to appear that often. The main case to handle are the <br>'s, which occur in the vast majority of the posts on the 2.1.8 database I'm now using with the 2.8.4 testbed.

Question:

On his previous post Adam suggests that some custom CSS could remap the <br>'s. I'm not a CSS wiz. Can you possibly point me to an example or page demonstrating what that might look like? You can see the raw html in my 2.1.8 database in the above post. The <br>s are enclosed in a <div style="">, but I'm not sure that is always the case.

Perhaps you have a Vanilla help page on how to customize the CSS that controls the display of the post html.

Thanks for your help and suggestions.

William Croft, OpenBCI

charrondev

Yeah you could add some CSS somewhere in your theme that looks like like the following:

.userContent div > br {
    display: none;
}

That would hide the br tags.

From there you could applying the spacing of your choice to the divs.

I’m on a mobile device right now so I’ll try to dig into this more tomorrow.