User Manager for Polylang

1. Overview

User Manager for Polylang limits what non-administrator users can edit on a multilingual site that runs on Polylang. For each user you choose which Polylang languages, post types and taxonomies that user may work with. A French editor can then work on French content only, and a German shop manager can manage German products only. The plugin is listed on the Plugins screen as "Polylang User Manager" (the name in its plugin header). The licence screen uses the product name "User Manager for Polylang".

You set the rules in a Polylang access box on the Add New User and Edit User screens. The plugin enforces them as WordPress capabilities: it removes the permission to edit, delete or publish an item that is outside the user's rules. Because WordPress checks these capabilities for every route, the rules apply to the edit screens, the list tables, Quick Edit, bulk actions, admin AJAX, the block editor and the REST API (including the WooCommerce REST API). The plugin only removes permissions. It never gives a user a capability that the user's role does not already have.

How it works

1. An administrator opens Users → Add New User or edits an existing user, and chooses Restricted in the Polylang access box.
2. The administrator ticks the languages, post types and taxonomies the user may use, and saves the user. The choices are stored as user meta (see User meta).
3. On every request the plugin reads the user's rules once, then answers WordPress's capability checks: content outside the rules gets do_not_allow.
4. The plugin also keeps Polylang's admin language filter on the user's languages, forces new posts and terms into one of those languages, hides menus for post types and taxonomies the user may not use, and links a translation the user creates to its original.

At a glance

What it does not do

• It never restricts administrators (users with the Administrator role) or super admins on a multisite network.
• It does not stop a user from reading content. It removes the permission to edit, delete and publish. It adds no front-end output and does not filter front-end or REST read queries.
• It has no settings screen of its own. All choices are made per user, on the user's profile.
• It does not create roles or capabilities and does not change what a role can do. A user who may not edit pages by role still cannot edit pages when you tick Pages.
• It does not restrict non-public post types such as WooCommerce orders and coupons, or product variations on their own (a variation follows its parent product). Orders and coupons are not restricted by language.
• It does not stop a REST request that creates a new post of a post type the user has not been given. See Known limits.
• It does nothing without Polylang. See Requirements.

2. Requirements

When Polylang is not active, the plugin does not start. It shows this notice on every admin screen to users who can activate_plugins: "Polylang User Manager needs Polylang (or Polylang Pro) to be active." While it is not started, no restriction is enforced, and the licence screen and update checks of this plugin are not registered either (see Licence and updates).

3. Installation

1. Install and activate Polylang (or Polylang Pro) and add your site languages under Languages → Languages.
2. Open Plugins → Add New Plugin → Upload Plugin, choose the zip file from your purchase and click Install Now, then Activate.
3. Open Plugins → WpExperts Hub Licences and activate your licence key to receive updates (see below). The plugin works without a licence.
4. Open Users → Add New User, or edit a user, and use the Polylang access box (see The Polylang access box).

What activation creates

Nothing. The plugin has no activation routine: no database tables, no options, no roles, no scheduled events and no pages. Data is written only when you save a user's Polylang access, when a restricted user dismisses the information notice, when the plugin corrects Polylang's own pll_filter_content setting for a restricted user, and when the licence client stores a licence or its update-check cache (see Privacy). Versions before 2.7.0 created a database table that was never read. Version 2.7.0 no longer creates it, and uninstalling removes it.

Licence and updates

The plugin bundles the WpExperts Hub licence and update client (licence/class-wpxh-licence-client.php, client version 2.0.0). One screen manages every WpExperts Hub plugin on the site: Plugins → WpExperts Hub Licences. It needs the manage_options capability.

1. Find your licence key in the purchase email, or under My Account → Downloads on wpexpertshub.com.
2. Open Plugins → WpExperts Hub Licences. Each WpExperts Hub plugin has its own card with a status ("Active" or "Not active"), the installed version and, when known, "version X is available".
3. Paste the key into Licence key and click Activate licence. Spaces and any character other than letters, digits and hyphens are removed from the key before it is sent.
4. To move the plugin to another live site, click Deactivate licence first. The screen reminds you: "Deactivate before moving the plugin to another live site."
5. If you cannot find your key, open "Can't find your key? Email it to me", enter the email address used for the purchase and click Send licence key. The licence server sends the email.

• Updates come through WordPress. An active licence puts the plugin on the normal Dashboard → Updates and Plugins screens. When an update exists but the server returns no package for your site, WordPress shows "Automatic update is unavailable for this plugin. Activate your licence to enable updates." under the plugin.
• The update information is cached. The answer from the licence server is kept in the site transient wpxh_licence_check_v2 for 12 hours. After a failed request the previous answer is kept and the check is retried after one hour. The cache is cleared when you activate or deactivate a licence, send a key request, or when any plugin is upgraded.
• A reminder on the Plugins screen. On Plugins, users with manage_options see "Activate your WpExperts Hub licence to receive updates for: ..." with a Manage licences link while any registered WpExperts Hub plugin has no active licence.
• A link in the plugin row. This plugin adds "Activate License" or "Deactivate License" (the plugin's own wording) under its name on the Plugins screen. It links to the licence screen.
• Licence key only unlocks updates. No code in the plugin checks the licence status before enforcing restrictions. The status is only used for the link text and the licence screen. The plugin works the same with or without a licence. Whether the server returns an update package for a site is decided on the licence server.
• Without Polylang the licence client is not registered, because the plugin does not start. Activate Polylang to see the licence card and receive updates.

What the licence client sends to wpexpertshub.com, and when, is listed under Data sent to wpexpertshub.com.

Updating

Update from Dashboard → Updates (needs an active licence), or upload the new zip over the old plugin. There is no migration routine. Rules saved by versions before 2.7.0 keep working: a user who had a language assigned and has no saved mode stays restricted to those languages, and a user with no language stays unrestricted. Open and save the user's profile to move it to the new mode setting (see The Polylang access box).

Multisite

The plugin has no network admin screen. Super admins are never restricted. The rules are stored in user meta without a site prefix, so they belong to the user rather than to one site, while the language choices are Polylang term IDs of the site where they were saved. Uninstalling removes the user meta for all users and drops the old table on every site of the network. On a multisite network WordPress runs the same user_new_form hook on both the "Add Existing User" and the "Add New User" forms, so the Polylang access box is shown there. The plugin saves the box only through the hooks edit_user_created_user and edit_user_profile_update. In WordPress 7.1.2 the multisite Add New User form creates a signup (or activates it) without calling edit_user(), so edit_user_created_user does not fire and nothing you tick on either multisite form is saved. Create or add the user first, then set the rules from Users → Edit User. On multisite WordPress lets only super admins edit other users' profiles (edit_user maps to manage_network_users), so only a super admin can save the rules.

Deactivating and deleting

Deactivating the plugin keeps all saved rules and ends enforcement. Deleting it from the Plugins screen removes the rules (see What deactivation and uninstall remove). Deleting does not remove the licence options, so deactivate your licence on Plugins → WpExperts Hub Licences before you delete the plugin if you want the activation released.

4. Quick start

1. Activate Polylang and this plugin. Make sure the user has the role you want (for example Editor or Shop Manager). Administrators are never restricted.
2. Open Users → All Users, then Edit the user. Scroll to the Polylang access box. (For a new user use Users → Add New User; on multisite create the user first and then edit them, see Multisite.)
3. Choose Restricted.
4. Tick the Languages the user may work in. Tick none to allow every language.
5. Tick the Post types (for example Posts, Pages, Products) and Taxonomies (for example Categories, Product categories) the user may use. Read the live summary under the box: it says what you are about to save.
6. Click Update User (or Add User).
7. Test it: open Users → All Users and check the Polylang access column. Then log in as the user (or use a private window) and open the Posts list: it lists only content in the user's language, because Polylang's language filter is locked to those languages. Open the edit address of an item in another language directly (post.php?post=ID&action=edit): it shows "You do not have permission to access this page."

5. Features

Parts of this section describe what WordPress core does once this plugin has answered a capability check. Those parts were checked against WordPress 7.1.2 and can differ in other versions.

Who is restricted

A user is restricted only when all of these are true:

• The user is logged in and does not have the Administrator role, and is not a super admin.
• The saved mode (_poly_user_restricted) is 1, or no mode has been saved and the user has at least one language saved (profiles saved before 2.7.0).
• Polylang is active, so that the plugin has started.

Everyone else is unrestricted: visitors, administrators, super admins, users set to Full access, and users who never had rules. A user whose saved mode is 0 keeps the saved choices, which are ignored until you switch the user back to Restricted.

The result can be changed in code with the polylang_user_manager_access filter (see Filters). The rules are worked out once per request for each user and kept in memory only. They are cleared when a language is added or changed in Polylang (actions pll_add_language and pll_update_language) and when a profile is saved. The plugin also listens for pll_delete_language, but Polylang 3.8.10 does not fire that action.

The Polylang access box

The box has the title Polylang access. It appears at the end of Users → Add New User and Users → Edit User, only for users who have manage_options. It does not appear on your own Users → Profile screen (an administrator is never restricted). It contains:

• Access. Two radio buttons. Full access: "Can work with every language, post type and taxonomy the role allows." Restricted: "Only the languages, post types and taxonomies ticked below." New users start on Full access.
• Languages. One tick box per Polylang language, with its flag, name and slug (for example "French fr"). Links Select all and Clear tick or untick the group. The note says: "Leave all unticked to allow every language (the post types and taxonomies below still apply)."
• Post types. One tick box per public post type except Media. Types that Polylang does not translate carry the small label "not translated". The note says: "The user can only add and edit the ticked post types. Items of a translated post type are also limited to the languages above."
• Taxonomies. One tick box per public taxonomy, again with "not translated" where Polylang does not translate it. The note says: "The user can only add and edit terms of the ticked taxonomies."
• Live summary. A line under the box that updates as you tick: "Full access to every language, post type and taxonomy." or for example "Restricted to French, German · 2 post types · 1 taxonomy". With no language ticked it reads "Restricted to every language". When nothing is ticked under Post types and Taxonomies it adds "Nothing is allowed yet: tick the post types and taxonomies this user may use."

The three groups are hidden while Full access is chosen. They are still submitted, so what you ticked is saved and kept if you switch back. If you change the Role field on the form to Administrator, the box hides the choices and shows "Administrators are never restricted." When you open an existing administrator, the box shows "Administrators are never restricted. Change the role to Editor, Author or Shop Manager to limit this user." instead of the choices. Because no choices are shown for an administrator, changing that user's role on the same form saves no rules: save the role first, then open the user again and set the box.

What is enforced, and where

The plugin answers WordPress's capability checks edit_post, delete_post, publish_post, edit_page, delete_page, edit_term and delete_term for a restricted user. It adds do_not_allow when the item is outside the user's rules. It does this in the map_meta_cap filter at priority 20, so it runs after most other plugins and can only take permission away. For post types registered without meta capability mapping (the plugin's code comment names WooCommerce product variations as an example), it also watches the type's own edit, delete and read capability, for example edit_product.

A post is outside the rules when any of these is true:

• Its post type is a public type (other than Media) that is not ticked, and the type is not opened with the poly_user_open_access filter.
• Its post type is translated by Polylang and the post's language is not one of the user's languages. A post that has no language is outside the rules, except an auto-draft (a new, unsaved item).
• It is a product variation whose parent product is outside the rules. A variation follows its parent.

A term is outside the rules when its taxonomy is a public taxonomy that is not ticked, or when the taxonomy is translated by Polylang and the term has a language that is not one of the user's languages. A translated term with no language is allowed. Polylang's own internal taxonomies and non-public taxonomies are never blocked.

The Polylang admin language filter

Polylang remembers which language a user is filtering by in the admin, in the user meta key pll_filter_content. For restricted users the plugin keeps that filter on one of the user's own languages:

• Before Polylang reads the filter (action setup_theme, priority 0, admin requests only, not admin AJAX), the stored filter is replaced by the user's first allowed language if it is not one of the user's languages. The very first request is already filtered.
• A lang value in the address is accepted only if it names one of the user's languages (by slug or by language id). Anything else, including lang=all and lang=0, is replaced by the current allowed language.
• The language list in the admin bar (Polylang's "Filters content by language" menu) only lists the user's languages. The "Show all languages" item is removed, also for a restricted user who has no language ticked (every language allowed): such a user sees one language at a time.
• The plugin also filters Polylang's current and preferred admin language (pll_admin_current_language and pll_admin_preferred_language, priority 20) so that a disallowed language is replaced by the first allowed one.
• The language columns of the post and term lists show only the user's languages.

Because the stored value is a Polylang setting, it stays on the language it was last set to when you later give the user Full access. The user can choose "Show all languages" again from the admin bar.

Language of new posts and terms

• Add New screens. For an allowed, Polylang-translated post type (and for the terms screen of an allowed, translated taxonomy), a request without a new_lang value is redirected to the same screen with new_lang set to the user's preferred language. The preferred language is Polylang's preferred language (pref_lang: the admin language filter, or the site's default language when no filter is set) if the user may use it, otherwise the first allowed language.
• Saving. After WordPress saves a post (hook wp_insert_post, priority 999, in the admin and in REST requests), a new post whose language is not allowed is set to the preferred language. For an update, a post whose language changed to a disallowed one is set back to its previous language (or to the preferred language if it had none). Types that Polylang does not translate, revisions, and post types opened with poly_user_open_access are skipped.
• Terms. After a term is created (hook created_term, priority 999, in the admin and in REST requests) in a translated taxonomy, a language that is not allowed is replaced by the preferred language. This also covers terms created in a block editor or through the WooCommerce REST API.
• Language drop-downs. In the Languages box, Quick Edit, bulk edit and term forms, the Polylang language drop-downs (post_lang_choice, term_lang_choice, inline_lang_choice) only list the user's languages. A small script does this in the browser, including for Quick Edit rows that WordPress clones when you open them. The server refuses a request for another language anyway.
• Translations table. The inputs of Polylang's translations table (#post-translations, #term-translations) are read-only for restricted users. On post screens the table is also hidden (by a style rule in the classic editor and by the block editor script), and the classic editor's Duplicate button is hidden.

Creating a translation

A restricted translator can create the translation of an existing item in any of their own languages. The user clicks the "+" for their language in the Polylang language column of the source item (Polylang's own link, which opens Add New with from_post and new_lang), writes the translation and saves. The plugin then links the new item to the source through Polylang's own function. In the block editor the link is made by a short request that the editor sends after each save (see AJAX actions).

The link is made only when all of these are true:

• The language is one of the user's languages and it is the language the new item really has.
• The source item exists, has the same post type as the new item, and the user may read it.
• The source item does not already have a translation in that language in another post. The plugin never replaces an existing translation.

If the source item has no translation group yet, the group is created from the source item's language. If you save an ordinary item (no source), the plugin makes sure it is in its own translation group.

Menus, "+ New" and screens

• The top-level menu entries of public post types that are not ticked (except Media) are removed (action admin_menu, priority 9999). The submenu entries of public taxonomies that are not ticked are removed as well.
• The "+ New" items of those post types are removed from the admin bar.
• Hiding a menu is only cosmetic. The screens themselves refuse access, as listed in What is enforced, and where.
• On the profile of the user, and in the notice below, the names are the labels WordPress shows (for example "Posts", "Product categories").

The information notice

A restricted user sees a dismissible blue notice on the Dashboard, the post lists and the term lists: "Polylang access Your account is limited to content in: French, German. Post types: Posts, Pages. Taxonomies: Categories." The sentence for a restricted user with every language reads "Your account is limited to the content types below, in every language." The "Post types" and "Taxonomies" parts are left out when none is ticked. When the user dismisses the notice, the plugin stores _pllum_notice_dismissed for that user and never shows it again.

Restricted users who do not have manage_options also see a read-only Polylang access table on their own profile with the rows Languages ("Every language" when none is ticked), Post types and Taxonomies ("None" when empty), and the text "An administrator limited the content you can edit. You can change this only by asking them."

The Users list

On Users → All Users the plugin adds:

• A Polylang access column. It shows "Never restricted" for administrators and super admins, "Full access" for unrestricted users, and for restricted users one badge per language (or "All languages") followed by the number of post types and taxonomies, for example "2 post types · 1 taxonomy". Clicking a language badge lists the restricted users of that language (address users.php?pll_access=restricted&pll_lang=fr); restricted users who have every language are included. A "Language removed" badge appears when a language assigned to the user no longer exists.
• Two views above the table: Restricted by Polylang with a count, and Not restricted by Polylang. The second one lists every user who is not in the first list, administrators included.

The view count and the filter look at up to 5,000 users that have any saved rule.

WooCommerce products and variations

WooCommerce is optional. If you use it, tick Products and the product taxonomies (for example Product categories, Product tags) for the shop manager, and make products translatable in Polylang (or use Polylang for WooCommerce). If products are not translated, only the Products tick applies, not the language.

• Variations follow the parent product. A variation of a product outside the user's rules cannot be edited or deleted. This holds in the REST API and in the classic product screen's AJAX requests. This protection arrived in 2.7.0.
• REST API. A write request (any method except GET) to /wc/v<n>/products/<id>/variations or a path below it is refused with rest_forbidden ("Sorry, you are not allowed to do that.", HTTP 403) when the parent product is outside the rules. The check runs on rest_pre_dispatch and covers batch requests below that path.
• Product categories and tags in the REST API. WooCommerce's term permission check (woocommerce_rest_check_permissions, priority 20) is also answered with the term rules, for the edit and delete contexts.
• Classic product screen AJAX. For admin AJAX actions whose name starts with woocommerce_, the request fields product_id, post_id, variation_id, variation_ids and variable_post_id are checked. If one names an item outside the rules, the request ends with -1 and HTTP 403.
• Orders and coupons. They are not public post types, so they are not restricted by this plugin.

A language that was deleted

If a language assigned to a user is later deleted in Polylang, the user is not silently unrestricted. The Edit User screen shows "A language assigned to this user no longer exists. Until you choose a language below, this user cannot edit translated content." The Users list shows a "Language removed" badge. If the deleted language was the only one assigned, the user has no allowed language and cannot edit any content of a translated post type until you choose a language again. If other assigned languages still exist, the user keeps working in those.

Leaving a post type open

The filter poly_user_open_access returns the names of post types that restricted users may use without ticking them. For those types the plugin skips its post type check, the language checks on save, the language-change guards on the edit screens and the row-action removal. Read Known limits first: for a post type that Polylang translates, WordPress's edit, delete and publish capability checks still compare the item's language with the user's languages. The filter is aimed at post types that Polylang does not translate. See Filters for the code.

Known limits

• Creating through the REST API. The capability checks run on existing items. When a restricted user creates a new post with a REST request, WordPress 7.1.2 asks only for the post type's own create capability (and its publish capability when the new post is published). The plugin does not add a check for the post type tick on creation. It does set the language of the new post to an allowed one. New terms are checked (taxonomy and language). On the admin screens, a post type that is not ticked is refused on Add New and its menu is hidden.
• Reading is not restricted. The plugin does not hide other-language content from REST read requests or from the front end.
• Open post types that Polylang translates. As explained under Leaving a post type open, listing such a type in poly_user_open_access does not lift the language check inside WordPress's edit, delete and publish capabilities.
• Assigning terms. The plugin does not check the capability to assign a term to a post. It limits creating, editing and deleting terms.
• Media. Media is never blocked by the post type rule. If Polylang translates media, the language rule applies to media items.
• Large sites. The "Restricted by Polylang" view and the Users list filter read at most 5,000 users that have saved rules.

WP-CLI

Three commands manage the rules from the command line. They exist only while Polylang is active (without it the plugin does not start). Full details are in WP-CLI commands.

6. Settings

There is no settings screen and no site-wide option. All settings are per user, in the Polylang access box described in The Polylang access box. The form field names below are what the box submits; the user meta key is where the value is stored.

The form is saved only when the request carries the plugin's own nonce (pllum_nonce, action pllum_save_access), the current user has manage_options and may edit the target user. Other plugins that fire the same profile hooks cannot clear a user's rules (a fix in 2.7.0). Saving a profile of an administrator writes empty lists and mode 0, because the box shows no choices for administrators.

7. Developer reference

Filters

The $access array has these keys:

Example: leave the post type contact open for restricted users (best for post types that Polylang does not translate, see Known limits):

add_filter( 'poly_user_open_access', function ( $post_types ) {
	$post_types[] = 'contact';
	return $post_types;
} );

Example: give every restricted user the event post type as well, without ticking it on each profile:

add_filter( 'polylang_user_manager_access', function ( $access, $user_id ) {
	if ( $access['restricted'] && ! in_array( 'event', $access['posts'], true ) ) {
		$access['posts'][] = 'event';
	}
	return $access;
}, 10, 2 );

The Users list column, the notice, the own-profile summary and the WP-CLI list command read the same rules, so this filter changes what they show for the users it touches. The Polylang access box on Add New User and Edit User shows the saved user meta (the ticks and the mode), not the filtered result; only its "language no longer exists" warning uses the filtered rules.

AJAX actions

WP-CLI commands

The commands are registered under wp polylang-user-manager when WP-CLI runs and Polylang is active. A <user> argument is a numeric ID, an email address or a login.

wp polylang-user-manager set editor_fr --languages=fr --post-types=post,page --taxonomies=category
wp polylang-user-manager set 42 --languages=fr,de --post-types=product --taxonomies=product_cat,product_tag
wp polylang-user-manager list --format=csv
wp polylang-user-manager clear editor_fr
wp polylang-user-manager clear editor_fr --forget

If the main plugin object is missing, the commands stop with "Polylang is not active."

User meta

Options, transients and tables

The plugin has no options and no tables of its own. The licence client uses these:

Versions before 2.7.0 created the table {prefix}poly_user_from. Nothing reads it. Uninstall drops it.

Core and other-plugin hooks the plugin attaches to

These are listed so that you can tell which other code runs before or after it. Priorities are exactly as in the code.

Capabilities and roles

• Setting rules: manage_options and edit_user for the target user.
• The "needs Polylang" notice: activate_plugins.
• The licence screen and its actions: manage_options.
• The capabilities the plugin denies: edit_post, delete_post, publish_post, edit_page, delete_page, edit_term, delete_term, and the matching type-specific primitives for post types registered without meta capability mapping.
• The plugin adds no roles and no capabilities.

Form fields, scripts and constants

• Profile form fields: poly_user_restricted, poly_user_lang[], poly_post_types[], poly_tax_types[], nonce pllum_nonce.
• Fields the plugin reads from Polylang forms: post_lang_choice, inline_lang_choice and term_lang_choice (a value of -1 is ignored), translation_language, and the plugin's own hidden fields pll_post_lang_choice and pll_from_post.
• Scripts: pllum-profile (js/profile.js, Add New User and Edit User only), pll-user-admin (js/common.js, localised object pll_user) and pll_user_block (js/pll-user.js, block editor). The profile stylesheet is pllum-admin (css/admin.css).
• Constants: the plugin defines POLYLANG_USER_MANAGER_VERSION. The licence client reads WPXH_LICENCE_SERVER if you define it. It also has the filters wpxh_licence_server and wpxh_licence_sslverify. Certificate checks are switched off only when the licence server host ends in .local, .test or .localhost, or is localhost or 127.0.0.1.
• Main object: $GLOBALS['polylang_user_manager'] holds the instance of Polylang_User_Manager. Its public methods (get_user_access(), user_can_access_post(), user_can_access_term(), post_type_allowed(), taxonomy_allowed(), get_language_map()) are not a documented interface and can change.

File layout

8. Privacy

What is stored

• User meta for each user you save rules for: the five keys listed under User meta. They contain language IDs, post type names, taxonomy names, a mode flag and a notice flag. They contain no personal data beyond the link to the user account.
• Polylang's pll_filter_content user meta is updated for restricted users, as explained under The Polylang admin language filter.
• Licence data, if you activate a licence: the licence key and its status as options, and the cached licence-server answer as a site transient (see Options, transients and tables).
• The plugin sets no cookies, writes no log, creates no tables and keeps no copy of content.
• It does not register privacy policy text or personal data exporters or erasers.

Data sent to wpexpertshub.com

Only the bundled licence client contacts another server. It sends JSON by HTTP POST to https://wpexpertshub.com/wp-json/wphub-licence/v1/<route> (the server can be changed with the WPXH_LICENCE_SERVER constant or the wpxh_licence_server filter), with a 20 second timeout. The routes and what each one sends:

WordPress adds its usual User-Agent header to every remote request: "WordPress/<version>; <site address>" (checked in WordPress 7.1.2). The plugin sends no content, no user data and no data about your Polylang setup. What the licence server stores or logs cannot be seen from the plugin's code.

What deactivation and uninstall remove

• Deactivation removes nothing.
• Uninstall (deleting the plugin on the Plugins screen) deletes the user meta keys _poly_user_lang, _poly_user_post_types, _poly_user_tax_types, _poly_user_restricted and _pllum_notice_dismissed for all users, and drops the table {prefix}poly_user_from of earlier versions on every site (on a multisite network, every site). It does not touch Polylang's pll_filter_content.
• Uninstall does not delete the licence options, the licence transients or the activation on the licence server. Deactivate the licence first.

9. Troubleshooting

10. FAQ

11. Changelog

2.7.0 - 2026-10-06

• New: choose any number of languages per user (checkboxes instead of a single drop-down). Saving the Edit User screen used to keep only one language of a multi-language user.
• New: "Full access" / "Restricted" mode. A restricted user without a language may use every language but only the ticked post types and taxonomies.
• New: redesigned "Polylang access" box with a live summary, Select all / Clear, flags and a hint for post types and taxonomies Polylang does not translate.
• New: Users list column, "Restricted by Polylang" / "Not restricted by Polylang" views and language filter.
• New: read-only access summary on the user's own profile and a dismissible notice on the dashboard and list screens.
• New: menus, "+ New" items and list screens of post types and taxonomies the user may not use are hidden or refused.
• New: Quick Edit and bulk actions stay available on content the user may edit (every item is checked).
• New: WP-CLI commands list, set and clear; filter polylang_user_manager_access.
• Security: product variations of other-language products could be edited, added and deleted by a restricted shop manager (REST API and the classic product screen's AJAX). They now follow their parent product.
• Security: "?lang=0", "?lang=all" or a language id in the URL unlocked the language filter and listed other-language content.
• Security: the profile fields are only saved with this plugin's own nonce. Other plugins firing the same profile hooks used to clear a user's restrictions.
• Fix: the stored language filter is corrected before Polylang reads it, so the first request of a restricted user is already filtered; an invalid filter request keeps the current allowed language.
• Fix: the block editor linked new translations using the user's first language, so translations in a second language were never linked.
• Fix: Media is no longer offered as a restrictable post type (it was never enforced), and its edit screen is no longer refused.
• Fix: the unused database table is no longer created; it is removed on uninstall together with the plugin's user meta.
• Fix: a language assigned to a user and later deleted is flagged instead of silently locking the user out.

2.6.0 - 2026-09-27

• Security - New licence client: licence data is exchanged as JSON only (the old client unserialized server responses) and a failed server request can no longer cause a fatal error.
• Enhancement - One "Plugins → WpExperts Hub Licences" screen manages the licences of all WpExperts Hub plugins (previously only one plugin's licence page could be opened when several were installed). Existing activations are kept.
• Enhancement - Updates are delivered through the standard WordPress update screen for sites with an active licence; "Email me my key" added.
• Security: restrictions are now enforced with capabilities, so other-language content can no longer be edited or deleted through the REST API (block editor, WooCommerce REST), quick edit, bulk edit/trash or AJAX.
• Security: the translation-link AJAX request now checks a nonce, the edit capability and the user's language.
• Fix: the saved language was not preselected on the Edit User screen, so saving the profile again removed the restriction.
• Fix: the plugin could stay inactive depending on plugin load order; it now starts after Polylang is loaded.
• Fix: changing a post to another language through the Languages box moved the post before the edit was refused; the change is now blocked first.
• Fix: the language drop-down removed English instead of the languages the user may not use.
• Fix: terms edited on the Edit Term screen (term.php) were not checked; term actions on the taxonomy screens now follow the rules.
• Fix: edit-tags.php requests with an action (delete, search) were redirected and lost.
• Fix: post types that Polylang does not translate were fully blocked for restricted users.
• New: Polylang's admin language filter is locked to the user's language; new posts/terms (including REST) get the user's language.
• Performance: removed a transient deletion that ran on every get_terms() call.
• Input sanitising and output escaping throughout; PHP 8.x compatibility; tested with WordPress 7.1 and Polylang 3.8.

2.5

• Previous release.

12. Support

Email support@wpexpertshub.com. Please include:

• Your order ID.
• The plugin version (this page describes 2.7.0), your WordPress version, your PHP version and your Polylang version.
• The role of the user, what you ticked on their Polylang access box, and the exact message you see.
• What you already tried. A screenshot of the Users list column and of the profile box helps.

More plugins and documentation are at wpexpertshub.com.