At /admin/config/user-interface/forward under the "Forward form" fieldset, there's a fieldset for the "Personal message field". It's got a setting called "Allowed HTML tags". That should only be visible if both the 'Personal message' field is something other than 'Hidden' AND if the 'Allow HTML in personal messages' checkbox is checked.

Before

 before

After - unchecked

 after (unchecked)

After - checked

 after (checked)

Comments

dww created an issue. See original summary.

dww’s picture

Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new856 bytes
new118.77 KB
new77.8 KB
new119.22 KB
dww’s picture

StatusFileSize
new707 bytes

Not sure which #states syntax is clearer.

In #2 I'm using AND between conditions, and specifying what has to happen for it to be visible.

Here, I'm using OR between conditions (thanks to more arrays!), and specifying what has to happen for it to be invisible.

This one is at least shorter and a smaller diff.

#2 is maybe more explicit? Up to the maintainer to pick. Both provide the same behavior as seen in the screenshots.

Cheers,
-Derek

john.oltman’s picture

In the "unchecked" case, the phrase "all tags not allowed below" no longer makes sense since tags are no longer displayed below. If you are going to conditionally display the tags field, my suggestion would be to change the descriptions as follows.

[x] Allow HTML in personal messages
If not enabled, any HTML in the message will be converted to plain text.

Allowed HTML tags
[ the input field is here ]
List of tags (separated by commas) that will be allowed if HTML is enabled above. XSS and tags not allowed will be filtered out. Defaults to:

However, this will mean existing translations for strings in Forward admin will now be out of sync. Therefore, I lean towards making this a "Closed (won't fix)" since the upside is minimal.

dww’s picture

Assigned: dww » Unassigned
Category: Bug report » Task
Status: Needs review » Postponed

Oh crap, good point. :/ This module is already stable, and changing these descriptions would break translations. Whoops.

Let's postpone this for a future text-breaking major release (either 8.x-3.x or 9.x or whatever), and yeah, fix the descriptions accordingly.

Thanks/sorry,
-Derek

dww’s picture

Assigned: Unassigned » dww
Issue summary: View changes
Status: Postponed » Needs review
StatusFileSize
new1.2 KB
new52.76 KB
new95.2 KB

Upon further consideration, let's just kill that description entirely. It's sort of confusing for end users, and I think the checkbox title speaks for itself. Especially in combination with the other setting (once revealed). This wouldn't break translations, since no strings are changed. There'd be extra translated text not being used, but that's better than the alternative.

Thoughts?

john.oltman’s picture

Status: Needs review » Postponed
john.oltman’s picture

Let's postpone. Whether somebody decides to enable the option could be influenced by the fact that there is a tag filter available. If I can't see that the tags can be filtered, I might not choose to enable it.

dww’s picture

Totally fair. I'll probably apply the patch locally on the sites I care about, but I completely respect your decision to leave this alone upstream.

Thanks,
-Derek

john.oltman’s picture

Version: 8.x-2.x-dev » 8.x-3.x-dev
Status: Postponed » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.