table

text block

0 | ]        | [
1 | \]        | \[
2 | \\]       | \\[
3 | \\\]      | \\\[
4 | \\\\]     | \\\\[

... It looked good when I posted the first time; I am now editing it.

... and even after editing, it looks good.

Yes, it appears the fix works.

This reply will be has been edited, but I won't didn't change anything beyond the horizontal line:

Examples of the rendering:

Similar happens in code-text-blocks

0 | ]        | [
1 | ]        | [
2 | \]       | \[
3 | \\]      | \\[
4 | \\\]     | \\\[

In the Notepad++ Community NodeBB instance, we are often talking about regular expressions, where you often have to backslash-encode specific characters, including square brackets.

For most escapes, just having the regex inside single-backticks , like A\(B\)C, will allow communicating the regex, and the backticks prevent NodeBB from collapsing the escape. And similarly for longer code blocks in ``` or ~~~ blocks.

However, NodeBB seems to treat backslash-left-square-bracket \[ and backslash-right-square-bracket \] as special cases, even when inside single-backticks or code blocks, and you have to go through mental gymnastics to find the right number of brackets to use. Even worse, the PREVIEW window shows what you expect would be required, but when you then submit it, extra backslashes are removed.

And further, when you try to edit a post after you've successfully gotten the number of backslashes just right for a given square bracket, then the editor shows the number of backslashes that it rendered rather than were originally typed, and when you submit after editing, NodeBB reduces the number of backslashes, thus messing up a section that used to be right.

We have a FAQ section that explains the oddities with backslash-bracket, but new users don't read FAQs and regular users forget just how strangely this special case behaves.

Examples of the rendering:

The preview of that showed the following, where the number of backslashes in the backtick-text renders as the same number in the PREVIEW window:

Since I already made the screenshots for the FAQ in the Notepad++ forum, the screenshot I am showing is from a light theme rather than a dark theme, but the rendering of the Markdown is the same here as it is there.

But that's not how it rendered once it was actually submitted/posted, which actually showed up with missing backslashes:

Similar happens in code-text-blocks

0 | ]        | [
1 | \]        | \[
2 | \\]       | \\[
3 | \\\]      | \\\[
4 | \\\\]     | \\\\[

Where the preview shows it correct:

... but as you can see from the render above, some of backslashes disappear.

Regarding the "edit" anomaly: I will also reply to this post with the same table and codeblock examples, then edit that reply exactly once without changing anything in those sections, so you can see how it changed even when i didn't change any of the backslash-bracket text.

@julian said in Spam not being caught:

This is fixed and slated for release with v3.6.0

Thanks for the fast fix!

Both of those have been working since we upgraded to 3.4.1, so that's great.

Unfortunately, with "minimum reputation for posting links" enabled, it also means that new users cannot (easily) reply to posts, because replies automatically include @-mentions (which count as links) and a link to the post they replied to (which counts as a link). It would be nice if the link reputation-for-link requirement were only for external links.

Though as I'm replying to this post, I see neither an automatic @-mention nor a link to the previous reply, so that implies that there's a way to turn off that automatic text. However, I cannot find a setting that turns those off. In 3.4.1, how can I turn those automatic "links" off? If I do that, it would allow newer users to reply more easily.

Thank you.

We haven't, as of yet, because we don't have enough coverage to approve such posts 24/7, and we get a lot of international posts -- we hadn't wanted to make users wait until one of the moderators was awake before their post is made public and starts getting replies. But maybe we'll have to.

We've got SpamBeGone enabled, with Akismet, Project Honeypot, and reCAPTCHA; and we only allow SSO login.

But recently, there's been a huge spate of sneaky spam posts where they just reply, then edit the @-mention URL to some external site -- or, even more sneaky, they leave the @ and the first few characters as the original @-mention link, but the last few characters of the username are really a link somewhere else; similar for the in [Name of This Topic](/post/####), it gets changed to in [Name of This Top](/post/####)[ic](link-to-external-site)

Sometimes they are "kind" enough to not post any text, so it's just got the quoted text, so while I'm reading posts, I can at least use that to clue me in to check for hidden links and then moderate/delete/ban. But if they combine it with a ChatGPT-style reply, they can often sneak past the radar.

Akismet, despite stopping many perfectly-reasonable posts, does nothing on those kinds of posts.

So does anyone else have ideas on how to combat/prevent those kinds of spam posts?

Or is there a setting or plugin that allows restricting which external sites can be linked to? (Like "allow links to google or our homepage or a few other sites, but not links to any random site") Or a way to get it to flag links that are external vs internal, so it's obvious all the links that go outside our forum?