Skip to:
Content

BuddyPress.org

Opened 4 years ago

Closed 22 months ago

#6933 closed enhancement (maybelater)

Emails: Do not strip HTML content for email content

Reported by: r-a-y Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.5.0
Component: Emails Keywords: trac-tidy-2018
Cc:

Description (last modified by r-a-y)

Currently, we strip HTML tags to render the email content.

This isn't great as some content will be lost such as links and textual emphasis (bold, italic, etc.).

For HTML emails, we should add a customized version of KSES here.

For plain-text emails, we should preferably do some type of HTML to plain-text conversion (perhaps to Markdown?) for accessibility reasons.

Change History (7)

#1 @r-a-y
4 years ago

  • Description modified (diff)
  • Summary changed from Emails: Do not strip all HTML content for plain-text emails to Emails: Do not strip HTML content for email content

#2 @DJPaul
4 years ago

For plain-text emails, we should preferably do some type of HTML to plain-text conversion (perhaps to Markdown?) for accessibility reasons.

Plain text emails were designed as being distinct from HTML email content. I did consider whether we should auto-convert HTML emails to plain text (Drupal has some good code to do this), but decided against it. If you want to propose changing this, it needs it own ticket, not being snuck onto this one.

#3 @DJPaul
4 years ago

Where do we strip HTML tags from the email content? Are you talking about ALL HTML tags? That's not the intention. I assume you're talking about the email content that exists in the post type, which is ran through wp_filter_post_kses.

#4 @r-a-y
4 years ago

If you want to propose changing this, it needs it own ticket, not being snuck onto this one.

Agreed. I bundled them initially because both are related to each other. See #6934.

Where do we strip HTML tags from the email content?

I should have been more specific.

I primarily meant the usermessage token located here:

https://buddypress.trac.wordpress.org/browser/tags/2.5.0/src/bp-activity/bp-activity-notifications.php?marks=79#L76
https://buddypress.trac.wordpress.org/browser/tags/2.5.0/src/bp-messages/bp-messages-notifications.php?marks=63#L61

Are you talking about ALL HTML tags?

I think we should implement our own version of KSES for HTML email content (perhaps just for specific email tokens like usermessage). This would be similar to what we currently do for the Activity component's version of KSES.

Last edited 4 years ago by r-a-y (previous) (diff)

#5 @DJPaul
3 years ago

HTML emails support very few elements, think HTML4 and <b> -- like that. We could absolutely add a KSES for user message and other tokens.

The first thing to do would be look at the BuddyPress code and figure out what HTML tags can be passed through to usermessage, and then figure out which of those will work acceptably in an email. Then we can build a new KSES for this.

#6 @DJPaul
22 months ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#7 @DJPaul
22 months ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.