In your email notifications, I'd like to have four more tokens (in addition to the current: {category}, {username}, {website_url}, {file_name}):
I would also like all tokens to be available in the "Subject" field as well as the Body.
Then your default subject could be:
For example:
Similarly for the Body of the email.
Ideally, there could also be tokens for:
so these items could be hyperlinked in the body of the email so an administrator could go directly to the document, if desired.
This gives me critical information about who changed what file where on what site.
Thanks for a great product! Hopefully, this will make it even better (without too much effort).
Larry
- {editor_username}
{site_name}
{category_name}
I would also like all tokens to be available in the "Subject" field as well as the Body.
Then your default subject could be:
[{site_name}]: File '{file_name}.{file_extension}' added in '{category_name}' by {editor_username}
For example:
[RRCS Employee Portal]: File 'Test document.txt" added in 'Staff Meeting Minutes' by Larry Daniele
Similarly for the Body of the email.
Ideally, there could also be tokens for:
- {category_url}
so these items could be hyperlinked in the body of the email so an administrator could go directly to the document, if desired.
This gives me critical information about who changed what file where on what site.
Thanks for a great product! Hopefully, this will make it even better (without too much effort).
Larry
L
Hi Tristan,
Sorry for the confusion.
As I understand it, {username} is the name of the person you are sending the email TO (i.e. you are on the list of people to be notified when a file is added). I would like {editor_username} to be the username of the person that EDITED (add, edit or delete) the repository (i.e. the person that TRIGGERED the notification, not the person that RECEIVED it.)
So if "Mary" edits a file and "Larry" is supposed to be notified, then "{username}" is "Larry" and "{editor_username}" would be "Mary".
I would probably create "{subscriber_username}" as a synonym for "{username}" and phase out "{username}" in the documentation. This would help to differentiate the two. There can be many subscribers to a notification - each with their own {subscriber_username} in the email; there is only one user that edited the repository - {editor_username}.
Also, "username" should probably represent the actual WordPress "username" of the user (e.g. "ldaniele"
. "display_name" would be more accurate for the name we're using in the salutation (e.g. "Larry Daniele".
And you are correct, "{category_name}" is the same as "{category}". If we add "{category_url}", then it would be important to differentiate the two better.
Basically, I think the most sustainable solution for these kinds of tokens is to have them map one-to-one to a typical object in object-oriented programming. So, for example, where you would write things like this in PHP or C++:
you might have corresponding tokens such as:
This makes it more obvious what the names should be (since in many cases the WordPress objects are already well-defined). And it makes it clear how to extend the set when you want to add more attributes.
Sorry for the confusion.
As I understand it, {username} is the name of the person you are sending the email TO (i.e. you are on the list of people to be notified when a file is added). I would like {editor_username} to be the username of the person that EDITED (add, edit or delete) the repository (i.e. the person that TRIGGERED the notification, not the person that RECEIVED it.)
So if "Mary" edits a file and "Larry" is supposed to be notified, then "{username}" is "Larry" and "{editor_username}" would be "Mary".
I would probably create "{subscriber_username}" as a synonym for "{username}" and phase out "{username}" in the documentation. This would help to differentiate the two. There can be many subscribers to a notification - each with their own {subscriber_username} in the email; there is only one user that edited the repository - {editor_username}.
Also, "username" should probably represent the actual WordPress "username" of the user (e.g. "ldaniele"
. "display_name" would be more accurate for the name we're using in the salutation (e.g. "Larry Daniele".And you are correct, "{category_name}" is the same as "{category}". If we add "{category_url}", then it would be important to differentiate the two better.
Basically, I think the most sustainable solution for these kinds of tokens is to have them map one-to-one to a typical object in object-oriented programming. So, for example, where you would write things like this in PHP or C++:
- category.name
category.id
user.display_name
user.username
user.id
etc.
you might have corresponding tokens such as:
- category_name
category_id
user_display_name
user_username
user_id
etc.
This makes it more obvious what the names should be (since in many cases the WordPress objects are already well-defined). And it makes it clear how to extend the set when you want to add more attributes.
- Page :
- 1
There are no replies made for this post yet.
