"No any post type permitted to edit for site editors": How to Fix It

The message No any post type permitted to edit for site editors. Ask please site administrators for details! means that WOLF treats the logged-in user as a site editor and finds no post type that site editors are allowed to edit. The page shows nothing else. In most cases the fix is one setting that an administrator fills in once. When an administrator sees the message, or a custom role cannot open WOLF at all, the cause is in how the user's roles are set up. This page covers all three cases.

What "No any post type permitted to edit for site editors" means

WOLF sorts users into two groups:

• Administrators work with every post type and every column, and see the Meta Fields tab and the settings that control site editors.
• Site editors are all other users who may open WOLF, first of all the editor role. They get only the post types listed in Settings → Site editors post types, and only the columns an administrator marked as visible for them.

The Site editors post types field is empty on a new installation. An empty list means zero post types, so the first editor who opens WOLF Bulk Editor sees the error until an administrator fills the field.

Fix: fill in "Site editors post types"

1. Log in as an administrator and open WOLF Bulk Editor → Settings.
2. In the General settings column, find Site editors post types.
3. Enter the post type slugs that editors may work with, separated by commas, for example post,page.
4. Click Save all settings. The editor reloads the WOLF page and gets the table.

Four details decide whether it works:

• Slugs, not names. Enter page, not Pages. The slug of a custom post type is in the address of its list screen: edit.php?post_type=property means property.
• No spaces. WOLF compares the text exactly. With post, page the second entry starts with a space, matches nothing, and editors only get posts. A typical sign: the editor selects pages in the post type switcher and the table keeps switching back to posts.
• The first slug is the default. When an editor's current post type is not in the list, WOLF switches the editor to the first slug.
• Only types WOLF already lists. The field narrows the post type list an administrator sees; it cannot add to it. A post type its plugin registered as non-public must first be added for everyone, as described in custom post type not showing in the bulk editor.

Next, decide what editors may change. In the Settings tab every column has the checkbox visible for the site editor; columns without it are hidden from editors and cannot be changed by them, in the table or in bulk. See how to limit what a site editor can edit. Meta fields are added by administrators only: editors do not get the Meta Fields tab.

Custom roles: no WOLF menu, or "not allowed to access this page"

WOLF opens for users who have the administrator or editor role, or a role added through one of two filters. Roles created by membership, course, forum or role-manager plugins are not on that list, so their users get no WOLF Bulk Editor menu, and the direct link answers with WordPress's Sorry, you are not allowed to access this page. The menu also requires the publish_posts capability, which editors and authors have and contributors do not.

Find the role slug first: in Users, click the role above the user list; the address ends with ?role= and the slug. Then choose the filter that matches what the role should do.

Full rights inside WOLF: wpbe_permit_special_roles

A role added here is treated like an administrator inside WOLF: every column, the Meta Fields tab, and the site editor settings. Give it only to roles you would trust with the whole content of the site.

/*
 * WOLF: give the role "content_manager" administrator rights in the bulk editor.
 * Child theme functions.php or a code snippets plugin.
 */
add_filter('wpbe_permit_special_roles', function ($roles) {
    $roles[] = 'content_manager';
    return $roles;
});

Keep administrator in the array: the filter replaces the default list, so a function that returns only your custom role locks out the real administrators. One limit remains: WOLF unlocks the full post type list only for accounts that have the administrator role itself. Users of a permitted custom role get the post types from Site editors post types, so fill that field as well, or they see the same error.

Own posts only: wpbe_author_area_roles

A role added here works as a site editor limited to its own content: the table shows only posts where the user is the author, the Author column cannot be changed, and only the columns marked visible for the site editor can be edited. This suits the author role or a custom writer role.

/*
 * WOLF: let authors bulk edit their own posts.
 * Child theme functions.php or a code snippets plugin.
 */
add_filter('wpbe_author_area_roles', function ($roles) {
    $roles[] = 'author';
    return $roles;
});

These users also get only the post types from Site editors post types.

When an administrator sees the error or loses admin tools

WOLF reads the roles of an account in two ways. For the post type list it checks whether the account has the administrator role at all. For everything else (the Meta Fields tab, the site editor settings, editing every column, choosing any post type) it checks the first role of the account against wpbe_permit_special_roles. A normal administrator account has exactly one role, so both checks agree. Role-manager plugins and plugins that add their own roles to users can break that in three ways, each with its own symptom:

To see what WOLF sees, add this snippet for a moment and open the WOLF page:

/*
 * Temporary check: prints the roles of the logged-in user on the WOLF page.
 * Code snippets plugin; remove it after the check.
 */
add_action('admin_notices', function () {
    if (isset($_GET['page']) && $_GET['page'] === 'wpbe') {
        $user = wp_get_current_user();
        echo '<div class="notice notice-info"><p>' . esc_html(print_r($user->roles, true)) . '</p></div>';
    }
});

A healthy administrator shows Array ( [0] => administrator ). If another role is listed under [0], remove it from this account, or make administrator the primary role in your role manager. If administrator appears only under [1] or later with nothing under [0], remove the capabilities that were assigned to the account itself; capabilities belong to the role. If administrator is missing, give the account the real administrator role back. When the extra role is one that only administrators hold, such as a forum keymaster role, adding it to wpbe_permit_special_roles is also a valid fix. Do not edit the plugin files: the cause is in the account, and edits are lost with the next update.

Checklist

• Site editors post types contains slugs, separated by commas, without spaces; the first one is the default.
• Every slug in it appears in the administrator's post type switcher.
• Custom roles are added with wpbe_permit_special_roles or wpbe_author_area_roles and have the publish_posts capability.
• The administrator account prints [0] => administrator in the role check.
• The columns editors may change are marked visible for the site editor.

If all of this is in place and the message still appears, open a topic on the WOLF support forum with the output of the role check and the content of Site editors post types.