Editor Role Triggering REST API Error in Search Exclude Plugin

Resolved Carlos
(@carloselevation)

4 months, 3 weeks ago
Hello everyone,

We are currently using the Search Exclude plugin (v2.5.8) on our WordPress website, and we have run into an issue specifically affecting users with the Editor role.

Whenever an Editor edits or updates a page or post, WordPress displays the following message:

rest_forbidden: Sorry, you are not allowed to do that

Even though the post/page still saves correctly, the message appears every time, which causes confusion for our editorial team.

After additional debugging in the browser console, we also see that the Gutenberg editor attempts to call:
POST /wp-json/quadlayers/search-exclude/settings

…which returns 403 Forbidden for Editors.

This confirms that the Search Exclude plugin is trying to access a REST endpoint that Editors do not have permission to use.What we’ve tried so far:
- Hiding the Search Exclude panel for Editors via CSS/JS
- Removing the REST endpoints dynamically
- Deregistering the plugin’s block-editor script
- Adjusting Editor capabilities via User Role Editor
- Checking plugin settings
However, the REST request continues to fire internally even when the UI is hidden, and Editors still encounter the error.

We do not want to grant Editors the manage_options capability for security reasons, and therefore we cannot use that as a workaround.Requested Assistance

We kindly ask if your team could advise whether there is a suggested method to:
1. Fully disable the Search Exclude meta box and related REST calls for non-admin users (e.g., a filter hook, PHP function, or conditional check)
OR
1. Provide or add a native option or filter that allows us to disable the plugin functionality for certain roles (Editors, Authors, etc.) without giving them elevated permissions.
Essentially, we would like administrators only to have access to the Search Exclude features and settings, while Editors should not load any UI or backend functionality related to the plugin, to avoid triggering the REST permission error.

If there is an existing hook or recommended approach, please let us know.

If not, we would appreciate any guidance or the possibility of implementing a role-based filter in a future update of the plugin.

Thank you very much for your time and assistance. We appreciate all the work you do on this plugin and look forward to your guidance.

Kind regards,
Carlos

The page I need help with: [log in to see the link]

Viewing 10 replies - 1 through 10 (of 10 total)

Plugin Support jmatiasmastro
(@jmatiasmastro)

4 months, 2 weeks ago

Thanks for report to us. Our development team are working on this problem.

Thread Starter Carlos
(@carloselevation)

4 months, 1 week ago

Hi there, do we have an update on this? Is there anything we can do on our end to help speed up the process? We look forward to hearing from you. Thank you in advance!

Plugin Support jmatiasmastro
(@jmatiasmastro)

4 months ago

@carloselevation Hi carlos,

Thanks for following up. We will check with our development team regarding the progress on this issue and get back to you as soon as we have an update.

Thank you for your patience.

Thread Starter Carlos
(@carloselevation)

3 months ago

Hello team, I am reviewing this ticket and it says it has been resolved when we have not received any indication of how it was resolved. Version 2.6.0 did not give the expected result. We look forward to your response so that you can help us with this issue, please.
hansspiess2025
(@hansspiess2025)

3 months ago
@carloselevation I observed the same behavior and have come up with this temporarily solution:
```
/**
 * Temporarily grant manage_options to editors/authors for the
 * Search Exclude REST API endpoints.
 *
 * WHY:
 * The Search Exclude plugin registers Gutenberg UI panels for all users
 * who can access the block editor, but its REST API routes are restricted
 * to users with the manage_options capability (admins only).
 *
 * As a result, editors and authors see the panel, but any API request
 * made by the block editor fails with a 403 error, triggering a toast
 * notification and breaking the UX.
 *
 * The plugin does not provide a filter or hook to alter its REST
 * permission callback, and forking the plugin is undesirable.
 *
 * WHAT THIS DOES:
 * This filter conditionally grants manage_options at runtime ONLY:
 * - during REST API requests
 * - for the Search Exclude plugin's REST namespace
 * - and only for editor/author roles
 *
 * This allows the Gutenberg panel to function correctly without:
 * - permanently modifying role capabilities
 * - granting editors broader admin access
 * - or altering plugin code
 *
 * Scope is intentionally narrow to avoid security side effects.
 */
add_filter( 'user_has_cap', function ( $allcaps, $caps, $args, $user ) {

    // Only affect REST requests
    if ( ! defined( 'REST_REQUEST' ) || ! REST_REQUEST ) {
        return $allcaps;
    }

    // Only affect Search Exclude REST routes
    $route = $_SERVER['REQUEST_URI'] ?? '';

    if ( strpos( $route, '/quadlayers/search-exclude/' ) === false ) {
        return $allcaps;
    }

    /**
     * Using user_can( $user, 'edit_posts' ) here leads to a race condition
     * so we have to directly inspect $allcaps here.
     */
    $can_use_block_editor =
        ! empty( $allcaps['edit_posts'] ) ||
        ! empty( $allcaps['edit_pages'] ) ||
        ! empty( $allcaps['edit_blocks'] );

    if ( $can_use_block_editor ) {
        $allcaps['manage_options'] = true;
    }

    return $allcaps;

}, 10, 4 );
```
While i agree on that it is not exactly “the way to go”, i think it is safe here as the filter is always evaluated in the has_cap core function which should run for every capability again.
Plugin Support jmatiasmastro
(@jmatiasmastro)

3 months ago
@carloselevation @hansspiess2025 Hi guys,

Regarding the current status: although updates were introduced in recent versions, we understand that the issue may still persist in some environments, particularly depending on user roles, WordPress version, and setup.

For anyone who is still experiencing this REST API permission error, we kindly ask you to open a support ticket directly with us so we can properly investigate the specific cause in your case and work toward a definitive solution.

Please create a ticket here:
https://urbiport.freshdesk.com/support/tickets/new

When submitting the ticket, make sure to reference this WordPress.org support thread and include:
- Your WordPress version
- Search Exclude plugin version
- PHP version
- The user role affected
  
  Best regards, Quadlayers Support Team.
hansspiess2025
(@hansspiess2025)

2 months, 4 weeks ago

Thanks for the assistance, @jmatiasmastro . I created the ticket there.

Plugin Support jmatiasmastro
(@jmatiasmastro)

2 months, 3 weeks ago

@hansspiess2025 @carloselevation Hi guys, could you please check if a newer version is available and update the plugin to see if the issue persists?

Best regards, Quadlayers Support Team.

hansspiess2025
(@hansspiess2025)

2 months, 3 weeks ago

@jmatiasmastro Thanks for the quick fix! I can confirm that Search Exclude 2.6.1 fixes the bug.

Plugin Support jmatiasmastro
(@jmatiasmastro)

2 months, 3 weeks ago

@hansspiess2025 @carloselevation Thanks for updating your ticket!

We would really appreciate it if you could take a moment to leave a review about our support here –> https://wordpress.org/support/plugin/search-exclude/reviews/

Your feedback helps improve our rankings and supports the ongoing development of our product.

Best regards, Quadlayers Support Team.

Viewing 10 replies - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Tags