How to Prevent Authors From Deleting Posts in WordPress

Remove the author role’s delete_posts capability. To protect published posts too, remove delete_published_posts; if authors could affect content owned by other users, remove delete_others_posts as well. For a rule that must hold across the dashboard, REST, bulk actions and custom workflows, enforce it with pre_delete_post and pre_trash_post in a site-specific plugin.

Which WordPress capabilities control deletion?

WordPress separates editing, publishing and deletion. An author can retain the ability to edit or publish while losing the ability to delete.

#	Preview	Product	Price
1		Posts fixed pages plugins setting method steps to read after installing WordPress for the first time...	$2.99	Buy on Amazon

For the common policy “authors may edit and publish, but may not delete,” remove all three deletion capabilities while retaining only the editing and publishing capabilities the role needs.

Option 1: Change the Author role in a capability editor

WordPress does not provide a full role-capability editor in its core settings. A role-management plugin can expose the controls in the dashboard. PublishPress Capabilities, for example, provides controls for who may read, edit, publish and delete content and can create or copy roles. Check its current WordPress compatibility and terms before installing.

#1 Best Overall

Posts fixed pages plugins setting method steps to read after installing WordPress for the first time (Japanese Edition)

$2.99

Buy on Amazon

1. Back up the site and record the current role capabilities.
2. Open the capability plugin’s role editor and select Author, or select a dedicated custom role.
3. Clear delete_posts.
4. Clear delete_published_posts if published posts are included in the policy.
5. Clear delete_others_posts if the role must not delete posts owned by other users.
6. Leave edit_posts, edit_published_posts and publish_posts enabled only where the workflow requires them.
7. Test with a non-administrator account that has the affected role.

Changing the built-in Author role affects every user assigned to it. Use a separate role when only one team, site section or workflow needs the restriction.

Option 2: Create a dedicated role in code

A custom role avoids changing every existing Author account. Add it from a small plugin during activation or another controlled deployment, rather than placing one-time role creation in a theme template.

<?php
add_role(
    'managed_author',
    'Managed Author',
    array(
        'read'                  => true,
        'edit_posts'            => true,
        'edit_published_posts'  => true,
        'publish_posts'         => true,
        'delete_posts'          => false,
        'delete_published_posts'=> false,
        'delete_others_posts'   => false,
    )
);

Assign users to managed_author instead of Author. If the role already exists, update its capabilities deliberately; calling add_role() repeatedly does not replace an existing role. Remove or revise the role in a controlled deployment when the policy changes.

The exact capabilities for a custom post type depend on how that post type was registered. Do not assume the standard post capabilities apply unchanged.

Protecting published posts without blocking editing

To let an author continue editing a live article but prevent its removal, keep edit_published_posts and remove delete_published_posts. Also remove delete_posts if drafts and other posts must be protected. If the role can work with posts owned by other users, remove delete_others_posts to close that separate permission path.

Test each status separately: an author’s draft, an author’s published post, another user’s draft and another user’s published post. The result can differ because WordPress checks ownership, status and the relevant capability together.

Enforce the rule in a site-specific plugin

Role settings are the normal solution, but a code policy is useful when deletion must be blocked regardless of which interface initiates it. The pre_delete_post filter runs before deletion and can short-circuit the operation by returning a non-null value. The pre_trash_post filter provides the corresponding interception point before an item is moved to Trash.

<?php
function freedom251_block_managed_author_removal( $override, $post ) {
    if ( ! $post instanceof WP_Post ) {
        return $override;
    }

    $user = wp_get_current_user();
    $blocked_role = in_array( 'managed_author', (array) $user->roles, true );

    if ( $blocked_role && 'post' === $post->post_type ) {
        return false;
    }

    return $override;
}
add_filter( 'pre_delete_post', 'freedom251_block_managed_author_removal', 10, 2 );
add_filter( 'pre_trash_post', 'freedom251_block_managed_author_removal', 10, 2 );

This example blocks both permanent deletion and moving a standard post to Trash for users with the managed_author role. Adapt the conditions to your policy: check post type, post author, status and the current user, and decide whether a blocked operation should return false or another application-specific response. Keep the code in a small site plugin so it remains active when the theme changes.

After deploying, test the normal post editor, list-table bulk actions, REST requests, XML-RPC if enabled, revisions or custom workflows, and every custom post type. A filter that checks only the dashboard interface is not a complete enforcement policy.

Trash is not a permission boundary

WordPress normally sends an ordinary post to Trash when Trash is enabled. wp_delete_post() can permanently delete when its $force_delete argument is true, when Trash is disabled, or when the post is already in Trash. wp_trash_post() likewise documents permanent deletion when Trash is disabled.

• Disabling Trash does not stop authors from deleting; it removes the recovery step and can make deletion permanent.
• Allowing Trash does not grant protection; a user who can delete can usually move the post there.
• Use capabilities and, where necessary, the pre-action filters to decide who may remove content. Treat Trash only as a recovery workflow.

Custom post types need a separate capability check

Inspect the post type registration before changing a role site-wide. The important settings are capability_type, an explicit capabilities array and map_meta_cap. These determine whether WordPress generates capabilities such as delete_posts, delete_published_posts and delete_others_posts, and how each object-level check is mapped.

• Find the registration code for the post type and note its generated or explicitly named capabilities.
• Confirm which capability is checked for deleting that post type’s drafts, published items and other users’ items.
• Apply the role changes to those exact capabilities, not merely to the standard post names.
• Exercise the post type through its editor, bulk actions and API endpoints after deployment.

A custom post type can therefore require a different role policy from ordinary Posts even when the same users manage both.

Quick Recap

Bestseller No. 1

Posts fixed pages plugins setting method steps to read after installing WordPress for the first time (Japanese Edition)

$2.99

Verification checklist

• Use a test account with the restricted role, not an administrator account.
• Confirm the Delete and Move to Trash actions are unavailable or fail safely.
• Try a draft and a published post owned by the test user.
• Try a post owned by another user if delete_others_posts is part of the policy.
• Test bulk actions, REST-based editing or deletion and any editorial plugin that handles posts.
• Verify administrators and approved editorial roles retain their intended capabilities.
• Document the role, capabilities and custom-post-type mappings so later plugin changes do not silently reopen deletion.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.