Permission callbacks in Wordpress - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to register a REST route with a permission callback that allows only logged-in users.

Wordpress

register_rest_route('myplugin/v1', '/data', array(
  'methods' => 'GET',
  'callback' => 'myplugin_get_data',
  'permission_callback' => [1]
));

Drag options to blanks, or click blank then click option'

Afalse

Bcurrent_user_can('edit_posts')

Creturn_true

Dis_user_logged_in

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'false' disables access for everyone.

Using 'return_true' allows access to everyone, which is insecure.

The is_user_logged_in function checks if the user is logged in, which is a common permission callback for REST routes.

2fill in blank

medium

Complete the permission callback to allow only users who can edit posts.

Wordpress

register_rest_route('myplugin/v1', '/update', array(
  'methods' => 'POST',
  'callback' => 'myplugin_update_data',
  'permission_callback' => function() {
    return [1]('edit_posts');
  }
));

Drag options to blanks, or click blank then click option'

Acurrent_user_can

Bis_user_logged_in

Cuser_can

Dhas_cap

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'is_user_logged_in' only checks login status, not capabilities.

Using 'has_cap' is not a standard WordPress function.

The current_user_can function checks if the current user has a specific capability, such as 'edit_posts'.

3fill in blank

hard

Fix the error in the permission callback to correctly check if the user can delete posts.

Wordpress

register_rest_route('myplugin/v1', '/delete', array(
  'methods' => 'DELETE',
  'callback' => 'myplugin_delete_data',
  'permission_callback' => function() {
    return current_user_can([1]);
  }
));

Drag options to blanks, or click blank then click option'

A'delete_post'

B'delete_posts'

C'delete_own_posts'

D'remove_posts'

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'delete_post' is incorrect because WordPress uses plural form for capabilities.

Using non-existent capabilities like 'remove_posts' causes permission errors.

The correct capability to check for deleting posts is 'delete_posts'.

4fill in blank

hard

Fill both blanks to create a permission callback that allows only administrators to access the route.

Wordpress

register_rest_route('myplugin/v1', '/admin', array(
  'methods' => 'GET',
  'callback' => 'myplugin_admin_data',
  'permission_callback' => function() {
    return current_user_can([1]) && is_user_logged_in() && [2];
  }
));

Drag options to blanks, or click blank then click option'

A'administrator'

Btrue

Cfalse

D'manage_options'

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'administrator' as a capability string is incorrect; capabilities are specific strings like 'manage_options'.

Using 'false' in the second blank disables access.

The capability 'manage_options' is usually assigned to administrators. The second blank uses true to complete the logical expression correctly.

5fill in blank

hard

Fill all three blanks to create a permission callback that allows users who are logged in and have the 'edit_pages' capability.

Wordpress

register_rest_route('myplugin/v1', '/pages', array(
  'methods' => 'POST',
  'callback' => 'myplugin_edit_pages',
  'permission_callback' => function() {
    if (![1]()) {
      return false;
    }
    return [2]([3]);
  }
));

Drag options to blanks, or click blank then click option'

Ais_user_logged_in

Bcurrent_user_can

C'edit_pages'

D'edit_posts'

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'edit_posts' instead of 'edit_pages' changes the permission scope.

Not checking if the user is logged in before capability check.

The code first checks if the user is logged in with is_user_logged_in(). Then it checks if the user has the 'edit_pages' capability using current_user_can().

Practice

1. What is the main purpose of a permission callback in WordPress REST API routes?

easy

A. To define the URL of the REST API route

B. To check if the current user has permission to access the route

C. To format the response data before sending

D. To register the REST API route with WordPress

Solution

1. Step 1: Understand permission callback role

   A permission callback is a function that decides if a user can access a REST API route.

2. Step 2: Identify what permission callback checks

   It returns true if the user has the right capability, false otherwise.

3. Final Answer:

   To check if the current user has permission to access the route -> Option B

4. Quick Check:

   Permission callback = access control [OK]

Hint: Permission callbacks control access rights [OK]

Common Mistakes:

• Confusing permission callback with route registration
• Thinking it formats data instead of checking access
• Assuming it sets the route URL

2. Which of the following is the correct way to define a permission callback in register_rest_route?

easy

A. "permission_callback" => array(check_user_permission)

B. "permission_callback" => check_user_permission()

C. "permission_callback" => "check_user_permission()"

D. "permission_callback" => check_user_permission

Solution

1. Step 1: Understand callback syntax in PHP arrays

   Callbacks are passed as callable references without parentheses.

2. Step 2: Identify correct syntax for permission_callback

   It should be a string or callable without calling it immediately, so no parentheses.

3. Final Answer:

   "permission_callback" => check_user_permission -> Option D

4. Quick Check:

   Callback = function name without () [OK]

Hint: Use function name without parentheses for callbacks [OK]

Common Mistakes:

• Adding parentheses calls the function immediately
• Using array() incorrectly for single function
• Passing callback as a string with quotes and parentheses

3. Given this permission callback function, what will register_rest_route allow?

function my_permission_check() {
  return current_user_can('edit_posts');
}

register_rest_route('myplugin/v1', '/data', [
  'methods' => 'GET',
  'callback' => 'my_data_callback',
  'permission_callback' => 'my_permission_check'
]);

medium

A. Only users who can edit posts can access the route

B. All users can access the route

C. No users can access the route

D. Only administrators can access the route

Solution

1. Step 1: Analyze the permission callback function

   The function returns true if the current user has the 'edit_posts' capability.

2. Step 2: Understand effect on route access

   Only users with 'edit_posts' capability can access the route; others get denied.

3. Final Answer:

   Only users who can edit posts can access the route -> Option A

4. Quick Check:

   Capability check controls access [OK]

Hint: Permission callback returns true only for allowed users [OK]

Common Mistakes:

• Assuming all users can access without checking capability
• Confusing 'edit_posts' with administrator only
• Ignoring the return value of permission callback

4. Identify the error in this permission callback code:

function check_permission() {
  if (current_user_can('edit_posts')) {
    return true;
  }
}

medium

A. Function should not return boolean

B. Incorrect capability name used

C. Missing return false when user lacks permission

D. Permission callback must be anonymous function

Solution

1. Step 1: Review function return paths

   The function returns true if user can edit posts, but returns nothing otherwise.

2. Step 2: Understand permission callback requirements

   Permission callbacks must return true or false explicitly to avoid unexpected behavior.

3. Final Answer:

   Missing return false when user lacks permission -> Option C

4. Quick Check:

   Always return true or false in permission callbacks [OK]

Hint: Always return false if permission denied [OK]

Common Mistakes:

• Omitting return false causes implicit null return
• Assuming no return means false automatically
• Using wrong capability names

5. You want to create a REST API route that only allows users who can either edit_posts or publish_posts. Which permission callback function correctly implements this?

hard

A. function permission_check() {
return current_user_can('edit_posts') || current_user_can('publish_posts');
}

B. function permission_check() {
return current_user_can('publish_posts');
}

C. function permission_check() {
if (current_user_can('edit_posts')) {
return true;
}
return false;
}

D. function permission_check() {
return current_user_can('edit_posts') && current_user_can('publish_posts');
}

Solution

1. Step 1: Understand the requirement

   Access should be granted if user can edit posts OR publish posts.

2. Step 2: Analyze each function logic

   function permission_check() { return current_user_can('edit_posts') && current_user_can('publish_posts'); } requires both capabilities (AND), which is too strict. function permission_check() { return current_user_can('edit_posts') || current_user_can('publish_posts'); } uses OR, which matches requirement. function permission_check() { if (current_user_can('edit_posts')) { return true; } return false; } only checks edit_posts. function permission_check() { return current_user_can('publish_posts'); } only checks publish_posts.

3. Final Answer:

   function permission_check() { return current_user_can('edit_posts') || current_user_can('publish_posts'); } -> Option A

4. Quick Check:

   Use OR for either capability allowed [OK]

Hint: Use || to allow either capability [OK]

Common Mistakes:

• Using && instead of || for either/or logic
• Checking only one capability when two are needed
• Not returning false explicitly when needed