WordPress standards impose a number of contraints to keep security at highest level possible. Here is an overview on how this affects the user experience with the Newsletter plugin and, if needed, how to change it.
These contraints limit the usage of some HTML features on newsletters and configurations.
Allowed roles
The roles allowed to use the plugin features can be set on the plugin Settings panel. The Administrator role is always allowed to access all the features. Other enabled roles can only access a subset of the available features.
For example, they cannot change the main settings or activate integrations with external delivery services. Generally, they cannot access configurations that are part of the plugin setup but only daily use features.
This is hardcoded and cannot be changed.
Single site case
If your blog is a single-site WP installation (if you don’t know what’s that, probably it is) both the Administrator and Editor roles are allowed to use all the HTML features, specifically adding JavaScript and editing a full HTML page.
Other roles (like Author) are not allowed to freely use the HTML so the plugin “filters” the content and the configurations when saved.
This means that the full HTML edit of a newsletter will be disabled, for example.
Usually there is no need to change that behaviour. The Administrator role always has access to all plugin features, while the Editor role can be enabled on the plugin Settings page.
Multisite case
If your blog is a multisite WP installation, there is a “new” role, the Super Admin. This is the only role allowed to deal with unfiltered HTML.
That means: even the administrators of each single site cannot use some of the features or configurations, like the HTML newsletter editor.
To unlock this block, a special constant can be defined on the wp-config.php file:
define('NEWSLETTER_HTML_ALLOWED', true);Please note: use it at your own risk.
About the XSS vulnerability
Skipping the technical details, if a user can add JavaScript to the content it can insert malicious code that could be executed by another user, for example the administrator. That code can try to steal the credentials and/or execute actions with admin privileges.