WordPress.org

Making WordPress.org

Opened 5 years ago

Last modified 9 days 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 15 months ago.
New plugin wporg-bbp-code-blocks adding code expand/contract functionality

Download all attachments as: .zip

Change History (29)

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


3 years ago

#2 @Clorith
3 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
2 years ago

  • Milestone set to Q1

Somewhat related to #815

#4 @tellyworth
2 years ago

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

@valentinbora
15 months ago

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

#5 @valentinbora
15 months ago

  • Keywords has-patch added

#6 @Clorith
15 months ago

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

#7 @valentinbora
15 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.


15 months ago

#9 @dd32
8 months ago

  • Milestone changed from Q1 to 2020 Q1

Milestone renamed

#10 @dd32
8 months ago

  • Milestone changed from 2020 Q1 to Q1

Milestone renamed

#11 @tobifjellner
2 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
2 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.


2 months ago

#14 in reply to: ↑ 12 ; follow-up: @dd32
2 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
2 months ago

In 10702:

Support: Try wrapping long pastes in core blocks.

See #2107.

#16 @dd32
2 months ago

In 10703:

Support Forums: Bump cache after [10702].

See #2107.

#17 in reply to: ↑ 14 ; follow-up: @Clorith
8 weeks 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 weeks 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 weeks 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.


6 weeks ago

#21 in reply to: ↑ 15 @bcworkz
6 weeks 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.


3 weeks ago

#23 @vladytimy
3 weeks 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
3 weeks 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
2 weeks 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
9 days 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
9 days ago

In 10877:

Support Forums: Bump JS cache after [10876].

See #2107.

#28 @dd32
9 days 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.

Note: See TracTickets for help on using tickets.