Prevent posting 10k lines of logs in replies, recommend Pastebin or GitHub gists

[ocean90]

To provide debugging information some users post their full logs in a reply. These can be up to 10k lines which makes reading the page really annoying because you have to scroll like 5 minutes.

Examples:

• ​https://wordpress.org/support/topic/qtranslate-x-compatibility-2/#post-8250157
• ​https://wordpress.org/support/topic/no-confirmation-email-received-2/#post-8235539

I suggest to prevent posting replies which have more than X chars/words/lines and to recommend using a service like Pastebin or GitHub gists.

[Clorith]

We are encouraging users to get debug data, and with our hopes of getting something for it into core, it would be a bad experience to then ship them off to a 3rd party site before making a post, adding another barrier basically.

What may work as a compromise here, is detecting if they're posting mass amounts of text without any code tags, and if they are show a warning like this:

You are about to post a very large amount of plain text. For improved readability, we will wrap it in code tags. You may want to consider splitting up your content, or using a paste service if this is not desirable.

If they still post it as is, we would wrap it in code tags for readability, the user was warned this would happen but chose to go with it.

[tellyworth]

Somewhat related to #815

[valentinbora]

New plugin wporg-bbp-code-blocks adding code expand/contract functionality

[Clorith]

2107.diff​ seems to be related to #4835, was this submitted to the wrong ticket?

[valentinbora]

@Clorith oops, good catch. It was late. Sorry about that, I'll repost to the appropriate ticket.

Can we consider closing this one as wontfix per your first comment in the ticket?

[dd32]

Milestone renamed

[dd32]

Milestone renamed

[tobifjellner]

It's also annoying to receive looooong WooCommerce debug info in Slack every time someone happens to paste one that includes my locale code. (Keeping in mind that all Global Translation Editors automatically receive notifications whenever their locale code is mentioned anywhere in the .org universe...)

[tobifjellner]

Possible alternative approach:
Automatically mark long pasted things as "code block".

[dd32]

Replying to tobifjellner:

Possible alternative approach:
Automatically mark long pasted things as "code block".

This seems like a reasonable alternative / half fix for this.

Catching the paste event and reformatting the content is ​easily done and so altering it to wrap more than x lines or x characters is a good idea.

Adding an upper limit to trigger a "Please don't paste that 10,000 line file" would also be beneficial, but without some kind of alternative way to pass that debug information along is not great.

Perhaps we could look into adding some kind of way to attach logs to a post, storing it outside of the reply, but accessible via the thread? Prompting people to attach Site Health debug output and the like could be useful, as would potentially being able expiring provided logs after a certain time frame. I'm not entirely sure if that functionality would be needed though..

[dd32]

In 10702:

Support: Try wrapping long pastes in core blocks.

See #2107.

[dd32]

In 10703:

Support Forums: Bump cache after [10702].

See #2107.

[Clorith]

Replying to dd32:

Perhaps we could look into adding some kind of way to attach logs to a post, storing it outside of the reply, but accessible via the thread? Prompting people to attach Site Health debug output and the like could be useful, as would potentially being able expiring provided logs after a certain time frame. I'm not entirely sure if that functionality would be needed though..

I'm not sure if this is needed either, Site Health debug information is added to the clipboard, so the user would then need to first save it as a file manually, over just pasting it straight away.

[dd32]

Replying to Clorith:

I'm not sure if this is needed either, Site Health debug information is added to the clipboard, so the user would then need to first save it as a file manually, over just pasting it straight away.

That's reasonable, But I guess I was thinking more that we'd have a separate field/request for the site health information, since that doesn't actually need to be posted publicly, and some plugins seem to add information in there that probably doesn't want to be discovered through a search engine.. so just a way to attach "logs" to a post without it being part of the editable reply content but also hidden from search engines/noindexed.

[Clorith]

Not sure how we would achieve a private field like that in a convenient manner, got any implementation in mind? (That said, plugins/themes can mark fields as private in Site Health and prevent them from being included in the copying mechanism)

[bcworkz]

Replying to dd32:

In 10702:

Support: Try wrapping long pastes in core blocks.

See #2107.

This seems to be working well, with one exception. This code needs to verify that backticks are not already in place in pasted content or we end up with double backticks, defeating the entire purpose of doing this.

[vladytimy]

Looking at changeset 10702 I see the intention is to trim ` off before wrapping.

"`" + paste.trim().replace(/^`|`$/g, '') + "`" +     // The pasted text, trimming ` off it and wrapping with `

Per ​Slack discussion and testing, trimming ` off doesn't happen. I don't know why it doesn't work as described, but I personally am happy it doesn't trim them off - because of custom pre-defs that contain `

Suggested alternative: check if ` exists in the pasted text before wrapping and if true, don't wrap.
Suggested updated condition:

        // If no pasted text,  no textarea value or includes ` then skip.
	if ( ! paste.length || ! $val.length || paste.includes("`") ) {
             return;
	}

Or paste.indexOf("`") !== -1 instead of includes() for IE compatibility

[bcworkz]

I think the reason why we're still seeing double backticks in forum posts is people are pasting their code into a pair of backticks. To avoid this we'd also need to check content on either side of the cursor position in the textblock.

[dd32]

Suggested alternative: check if ` exists in the pasted text before wrapping and if true, don't wrap.

That probably isn't an ideal solution, as ` is a common character in SQL and as a result often inside debugging pastes from what I've seen.

I personally am happy it doesn't trim them off - because of custom pre-defs that contain `

When it comes to predefs, if you paste it into the reply when there's no reply content yet, this code doesn't kick in (intentionally).. which could actually be annoying if you start your responses with "Hi @....mention, *paste*".

If required, we can probably add some way of opt-out for it.

Replying to bcworkz:

I think the reason why we're still seeing double backticks in forum posts is people are pasting their code into a pair of backticks. To avoid this we'd also need to check content on either side of the cursor position in the textblock.

That makes sense, I don't see any reason not to do that. I think I might have just assumed that very few people would do that :)

[dd32]

In 10876:

Support Forums: Don't wrap pastes in code blocks when the paste cursor previous character is a backtick.

This also doesn't affect pastes when they begin OR end with a backtick, allowing for predefs which end with a code block but do not start with one.

See #2107.

[dd32]

In 10877:

Support Forums: Bump JS cache after [10876].

See #2107.

[dd32]

[10876] accidentally lowered it to 500char / 5 lines, which I was using for easier testing.. I'm going to leave it at that lower number to see how it plays out.

[tobifjellner]

I just spotted a weird thing.
It seems someone pasted a complete post (perhaps after copying it from an almost ready post in "wrong forum".
The pasted segment already contained a long "WooCommerce style system report" that was correctly surrounded by backticks.
When our system added another couple of backticks beginning and end, this "swapped" the appearance so that the initial few lines and the last couple of lines in the post got marked as cope, while the long WooCommerce status got rendered as normal text.

[dd32]

Replying to tobifjellner:

When our system added another couple of backticks beginning and end, this "swapped" the appearance so that the initial few lines and the last couple of lines in the post got marked as cope, while the long WooCommerce status got rendered as normal text.

I don't see a way around this unfortunately. But yes, I'm guessing as you are, that they copied an entire post from elsewhere, came to the right place, typed something into the field and then pasted the rest of the post that they'd copied.

If they had pasted it into an empty new post, it wouldn't have triggered.

[tobifjellner]

How about:
Do nothing if the pasted string contains at least one backtick (in order to not make things worse).

[Clorith]

How about looking for two backticks, and skipping the wrapper then?

If there's only a single backtick, we could instead escape it somehow to avoid potential half-wrapped code.

[dd32]

How about looking for two backticks, and skipping the wrapper then?

I guess that's a reasonable option.

we could instead escape it somehow to avoid potential half-wrapped code.

Unfortunately escaping isn't possible, at least not with how the code blocks work at present. Integrating the Gutenberg editor would probably make it possible.