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().