TermsFeed AutoTerms Capabilities and Roles

Decide who edits legal pages and who changes the plugin settings

TermsFeed AutoTerms controls access with 10 capabilities of its own, the plugin roles it creates, and the WordPress capabilities manage_options and unfiltered_html. The legal page screens follow the 10 capabilities. The settings screens need manage_options, or edit_wpautoterms_pages together with unfiltered_html, and every field that holds code or HTML needs unfiltered_html to save new code.

The plugin never adds a capability to the Administrator role. Check access in your code with current_user_can(), never by reading a role.

The legal page capabilities

Each of the 10 capabilities allows one action on legal pages, the posts of type wpautoterms_page. The post type maps the WordPress meta capabilities, such as edit_post, delete_post, and read_post, onto these 10, the way the page post type maps them onto edit_pages and its siblings.

A Super Admin, and any user with manage_options, passes every check about legal pages without holding the 10 capabilities. A site Administrator on a multisite network has manage_options and manages legal pages too. current_user_can( 'edit_wpautoterms_pages' ) therefore returns true for an Administrator.

The example adds a "Legal Pages" item, linked to All Legal Pages, to the admin toolbar for every user who edits legal pages, Administrators included.

add_action(
	'admin_bar_menu',
	function ( $wp_admin_bar ) {
		if ( ! current_user_can( 'edit_wpautoterms_pages' ) ) {
			return;
		}

		$wp_admin_bar->add_node(
			array(
				'id'    => 'mytheme-legal-pages',
				'title' => esc_html__( 'Legal Pages', 'mytheme' ),
				'href'  => admin_url( 'edit.php?post_type=wpautoterms_page' ),
			)
		);
	},
	100
);

The item appears for an Administrator and for a user with a plugin role. An Author with no role from the plugin does not see the "Legal Pages" item in the toolbar.

The roles the plugin creates

The plugin creates its roles on the first WordPress admin page load after you activate it. The second role exists only on sites that have the WordPress Editor role.

A user whose only role is "WPAutoTerms Pages Editor (additional)" holds none of the WordPress capabilities, read included. WordPress then sends that user to the home page after login and refuses the WordPress Dashboard and Profile screens. The legal page screens still open from their direct addresses, such as /wp-admin/edit.php?post_type=wpautoterms_page. Give the role only as a second role, to a user who keeps a main role such as Author or Contributor.

Each role keeps the capabilities it received at creation. The AutoTerms plugin adds a role only when the role does not exist, so an update never refreshes an existing role. A later change to the Editor role does not reach "Editor + WPAutoTerms Pages Editor" either. Change a role afterward with a role editor plugin or with WP_Role::add_cap() and WP_Role::remove_cap().

Deleting the plugin removes the plugin roles, on every site of a network. Users of "Editor + WPAutoTerms Pages Editor" become Editors. Users of the additional role keep their main role and lose the legal page capabilities. Read every step of removal in Install the TermsFeed AutoTerms Plugin on WordPress.

Who opens and saves each screen the plugin adds

Each screen opens and saves for a user with the capabilities in its row, and a user without that access does not see a menu item for the settings screens.

The common roles on a single site get this access to the settings screens.

• Administrator. An Administrator has manage_options and opens every screen the plugin adds.
• Editor + WPAutoTerms Pages Editor. The Editor role holds unfiltered_html on a single site, so this user opens the legal pages, Compliance Kits, and Settings.
• Author with the additional role. An Author lacks unfiltered_html, so this user edits legal pages and does not see the Compliance Kits or Settings item.
• Editor without a plugin role. The Editor does not see the TermsFeed menu.

On a multisite network, a site Administrator opens every settings screen through manage_options but does not save new code. An "Editor + WPAutoTerms Pages Editor" user sees the legal pages only. Set up a network with WordPress Multisite Legal Pages.

Fields that need the unfiltered_html capability

Every plugin field that prints code or HTML on your WordPress website keeps its stored value, or saves without markup, for a user without unfiltered_html. WordPress gives unfiltered_html to Administrators and Editors on a single site and to Super Admins on a network. Nobody holds it while wp-config.php defines DISALLOW_UNFILTERED_HTML as true. Some security plugins offer an option to turn off unfiltered HTML, so check in the documentation of yours whether that option removes it from Administrators.

The plugin checks unfiltered_html on every save, including a save from the WordPress "All Settings" screen at wp-admin/options.php. In the Cookie Consent kit settings it checks only the values that differ from the stored ones. A save by a user without unfiltered_html therefore keeps the code an Administrator wrote.

Markup means a < followed by a letter, /, !, or ?, the sequences that start a tag in a browser. Text such as "I <3 cookies" or "a < b" stays as typed.

The plugin shows an error at the top of the screen after a filtered save of a code field or a text field of the Cookie Consent kit. The error names the capability the account lacks.

Ask a user who holds unfiltered_html, such as a Super Admin on a network, to make the change. Find each symptom and its fix in Code or HTML Not Saving in WordPress.

Where each role the plugin creates is assigned

The WordPress user profile screen offers a single role per user, so it assigns "Editor + WPAutoTerms Pages Editor" in place of the Editor role. "WPAutoTerms Pages Editor (additional)" is a second role, which WP-CLI or a role editor plugin adds beside the main role.

Both commands apply from the next page the user loads. Give an Editor access to legal pages, step by step, with Edit and Publish WordPress Legal Pages.