WordPress.org

Making WordPress.org

Opened 5 years ago

Last modified 3 months ago

#2107 accepted enhancement

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

Reported by: ocean90 Owned by: tellyworth
Milestone: Q1 Priority: low
Component: Support Forums Keywords:
Cc:

Description

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:

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.

Attachments (1)

2107.diff (4.6 KB) - added by valentinbora 21 months ago.
New plugin wporg-bbp-code-blocks adding code expand/contract functionality

Download all attachments as: .zip

Change History (37)

This ticket was mentioned in Slack in #forums by clorith. View the logs.


4 years ago

#2 @Clorith
4 years ago

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.

#3 @tellyworth
3 years ago

  • Milestone set to Q1

Somewhat related to #815

#4 @tellyworth
3 years ago

  • Owner set to tellyworth
  • Status changed from new to accepted

@valentinbora
21 months ago

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

#5 @valentinbora
21 months ago

  • Keywords has-patch added

#6 @Clorith
21 months ago

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

#7 @valentinbora
21 months ago

  • Keywords has-patch removed

@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?

This ticket was mentioned in Slack in #forums by clorith. View the logs.


21 months ago

#9 @dd32
14 months ago

  • Milestone changed from Q1 to 2020 Q1

Milestone renamed

#10 @dd32
14 months ago

  • Milestone changed from 2020 Q1 to Q1

Milestone renamed

#11 @tobifjellner
8 months ago

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...)

#12 follow-up: @tobifjellner
8 months ago

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

This ticket was mentioned in Slack in #forums by clorith. View the logs.


8 months ago

#14 in reply to: ↑ 12 ; follow-up: @dd32
8 months ago

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..

#15 follow-up: @dd32
8 months ago

In 10702:

Support: Try wrapping long pastes in core blocks.

See #2107.

#16 @dd32
8 months ago

In 10703:

Support Forums: Bump cache after [10702].

See #2107.

#17 in reply to: ↑ 14 ; follow-up: @Clorith
8 months ago

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.

#18 in reply to: ↑ 17 @dd32
8 months ago

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.

#19 @Clorith
8 months ago

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)

This ticket was mentioned in Slack in #forums by clorith. View the logs.


8 months ago

#21 in reply to: ↑ 15 @bcworkz
8 months ago

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.

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


7 months ago

#23 @vladytimy
7 months ago

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


#24 follow-up: @bcworkz
7 months ago

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.

#25 in reply to: ↑ 24 @dd32
7 months ago

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 :)

#26 @dd32
7 months ago

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.

#27 @dd32
7 months ago

In 10877:

Support Forums: Bump JS cache after [10876].

See #2107.

#28 @dd32
7 months ago

[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.

#29 follow-up: @tobifjellner
6 months ago

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.

#30 in reply to: ↑ 29 @dd32
6 months ago

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.

#31 @tobifjellner
6 months ago

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

#32 @Clorith
6 months ago

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.

#33 @dd32
6 months ago

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.

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


5 months ago

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


5 months ago

This ticket was mentioned in Slack in #forums by vladytimy. View the logs.


3 months ago

Note: See TracTickets for help on using tickets.