Post

# Syntax

Post:<post-type>:<ID|slug>

The post-type has to exactly match the post type key for the registered post type with register_post_typeopen in new window. For example, the regular WordPress posts use the post type key post, and pages - page.

# Definition

Redefine how users can access a post. Under post we mean any post, page, media library item or custom post type. Basically any record stored in the wp_posts database table.

Each post is identified internally by three attributes:

• post type (e. g. post, page, product, attachment).
• post ID (e. g. 174, 12, 89).
• slug aka post name (e. g. hello-world, first-post).

When defining the Post resource, you explicitly provide the post type and either post ID or slug. For example if you need to restrict to edit and delete the page "Contact" (ID 78 and slug contact) the following statements target this page.

{
    "Statement": [
        {
            "Effect": "deny",
            "Resource": "Post:page:78",
            "Action": [
                "Edit",
                "Delete"
            ]
        },
        {
            "Effect": "deny",
            "Resource": "Post:page:contact",
            "Action": [
                "Edit",
                "Delete"
            ]
        }
    ]
}

The Post resource supports several actions that define more granular access to what users can or cannot do with the post. If you need to be more specific about where access controls should be applicable, use conditions.

# Read

Manage the ability to read or directly access a post. However, note that this does not hide the post in the search results, list of posts, menu, etc. To hide the post, use the List action.

The following statement restricts to read some posts, pages and custom post types.

{
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "Post:page:members-only",
                "Post:post:how-does-membership-pricing-work",
                "Post:course:introduction-to-ecommerce",
                "Post:course:advanced-email-marketing"
            ],
            "Action": "Read"
        }
    ]
}

You can fine-tune how direct access to a post is protected with additional configurations. For example, you may want to protect your content with a password or show a teaser message instead. Last but not least, maybe you want to redirect the user to a different location. With additional properties in the statement you can do so.

# Password Protected

The Password property declares a password to access the restricted post. You can define the password directly in the statement as a string or dynamically injected with a marker.

In the example statement below, the password is declared as a constant WORDCAMP_PASSWORD in the wp-config.php file, and the post wordcamp-material is password protected between April 1st and April 30th, 2023.

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:wordcamp-material",
        "Action": "Read",
        "Password": "${CONST.WORDCAMP_PASSWORD}",
        "Condition": {
            "Between": {
                "${DATETIME.y-m-d}": [
                    "2023-04-01",
                    "2023-04-30"
                ]
            }
        }
    }
}

# Teaser Message

The Teaser property declares the teaser message instead of the post's content. In other words, a user can directly access the post, however, instead of its content, they see the defined teaser message. The message can be plain text or rich HTML with embedded shortcodesopen in new window.

The common use case for the teaser message is to show the end user that certain content is available for logged-in users or paid members. In the example statement below the custom callback function ContentLimiter::generateTeaserMessage returns the teaser message instead of the "Introduction to AWS" E-book page if the user does not have the Gold tier.

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:ebook:introduction-to-aws",
        "Action": "Read",
        "Teaser": "${CALLBACK.ContentLimiter::generateTeaserMessage}",
        "Condition": {
            "NotIn": {
                "gold": "(*array)${USER.roles}"
            }
        }
    }
}

# Redirect

The Redirect property allows defining the redirect to a different page, URL or to display a custom message. The redirect happens before the post content renders, so the end-user does not see the restricted content.

AAM support several redirect types as follows:

• Redirect to a different page by slug or id.
• Redirect to a different URL within the allowed hosts (AAM performs the safe redirect with the core WordPress function wp_safe_redirectopen in new window).
• If restriction is meant for not-authenticated user, a redirect to the login page is available.
• Display WordPress core standard "WP Die" dialog with custom message.
• Trigger a callback function that performs redirect and halts further PHP execution with exit or die; or returns a safe URL for AAM core to perform redirect.

You can set any 3xx HTTP status code with StatusCode property as recommended by MDNopen in new window. The default status code is 307 (Temporary Redirect).

There are example of various redirects.

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "page_redirect",
            "Slug": "authentication-required",
            "StatusCode": 301
        }
    }
}

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "page_redirect",
            "Id": 76,
            "StatusCode": 307
        }
    }
}

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "url_redirect",
            "Url": "/different-page",
            "StatusCode": 302
        }
    }
}

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "custom_message",
            "Message": "You are not allowed to be here"
        }
    }
}

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "login_redirect"
        }
    }
}

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:postman-testing",
        "Action": "Read",
        "Redirect": {
            "Type": "trigger_callback",
            "Callback": "do_redirect_or_return_redirect_url_func"
        }
    }
}

# List

Manage post visibility. In other words - hide the post, however, allow direct access with the URL. To protect the post from accessing it, use the Read action.

Use the On property to define the website areas where this permission applies. Supported values are frontend, backend, and api. The On property can be specified either as an array of values or as a string if only a single area is being designated.

The following statement hides a few pages even if the page is part of any menu or fetched via RESTful API.

{
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "Post:page:discounts",
                "Post:page:123"
            ],
            "Action": "List",
            "On": "frontend"
        }
    ]
}

{
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "Post:page:discounts",
                "Post:page:123"
            ],
            "Action": "List",
            "On": [
                "frontend",
                "api"
            ]
        }
    ]
}

# Comment

Determine if the commenting feature is enabled for a post. It basically controls the WordPress core native "Allow Comments" feature.

In the policy below, we restrict commenting for the post if user is not authenticated.

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:post:idea-board",
        "Action": "Comment",
        "Condition": {
            "Equals": {
                "(*bool)${USER.isAuthenticated}": false
            }
        }
    }
}

# Edit

Manage the ability to edit a post. If denied, the user will not be able to make changes to the post through the backend or RESTful API unless conditioned differently.

The following statement restricts a user from editing the page with ID 45.

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:page:45",
        "Action": "Edit"
    }
}

# Delete

Manage the ability to delete a post (move to trash). If denied, the user will not be able to delete a post through the backend or RESTful API unless conditioned differently.

The following statement restricts a user to delete the page "Home".

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:page:home",
        "Action": "Delete"
    }
}

# Publish

Manage the ability to publish a draft post. If denied, the user will not be able to publish a draft the post through the backend or RESTful API unless conditioned differently. However, if the post is already published, the action has no effect.

The following statement restricts a user from publishing the page "Discounts".

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:page:discounts",
        "Action": "Publish"
    }
}

# Exclude Authors Flag

You can grant permissions to all users as demonstrated above, but you can also exclude post authors from a specific permission by using the ExcludeAuthors boolean property. To effectively use this property, it’s important to understand how AAM processes it.

The ExcludeAuthors flag has no effect when applied to an individual user or visitor access levels. This is because these levels represent a single, specific identity and do not encompass the concept of "others". Consequently, this permission is only applicable to roles or default access levels.

For example, the policy below restricts access to the post with the slug my-personal-journey, allowing only its authors to read it when applied to the default access level.

{
    "Statement": [
        {
            "Effect": "deny",
            "Resource": "Post:post:my-personal-journey",
            "Action": "Read",
            "ExcludeAuthors": true
        }
    ]
}