Opened 9 years ago
Closed 7 years ago
#6897 closed enhancement (maybelater)
Email tokens - descriptions and updated UI
Reported by: | DJPaul | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Emails | Keywords: | ui-feedback, needs-patch, ux-feedback, trac-tidy-2018 |
Cc: | espellcaste@… |
Description
There was a discussion on Slack started by @modemlooper who suggested that the email tokens should have some kind of panel in the UI to describe what they're used for (and also, what email types they *work* for). Here onwards for about two hours: https://wordpress.slack.com/archives/buddypress/p1455303829002038
The idea is good, but there are a couple of problems:
- Tokens aren't registered anywhere centrally.
- There's no way to currently get tokens without duplication the call to
bp_send_email
(where the tokens are passed).
To resolve this, tokens would have to become property of the email *type*, not of an email.
Taxonomies might make a good fit, with term meta to store text like token description (required for the UI).
We'd need to come up with a good UI to manage informing the user about the purpose of the email tokens, and which tokens are available for the current email.
Some initial problems I can imagine are that the tokens are intended to be filterable for developers. I could create a plugin that adds some kind of bespoke token, and have either have a scalar value for that or a function callback. How would registering tokens in a taxonomy interfere with easy development vs. a good interface users, etc.
Change History (8)
This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.
9 years ago
This ticket was mentioned in Slack in #buddypress by espellcaste. View the logs.
8 years ago
#7
@
7 years 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/
Thanks for summing this up, @DJPaul.
I'd suggest that token descriptions should not be stored in the DB (since they're not really meant to be editable). The term names/slugs would be canonical IDs, that would be used to reference a hardcoded, translated, filterable etc catalog of descriptions.