Custom endpoint registration in Wordpress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this WordPress REST API endpoint registration?

Consider the following code that registers a custom REST API endpoint in WordPress. What will be the JSON response when a GET request is made to /wp-json/custom/v1/message?

Wordpress

<?php
add_action('rest_api_init', function () {
  register_rest_route('custom/v1', '/message', [
    'methods' => 'GET',
    'callback' => function () {
      return ['greeting' => 'Hello, world!'];
    },
  ]);
});

A {"message":"Hello, world!"}

B {"greeting":"Hello, world!"}

C 404 Not Found error

D 500 Internal Server Error

💡 Hint

Look at the callback return value and the route path.

The callback returns an array with key 'greeting' and value 'Hello, world!'. WordPress converts this to JSON automatically for the REST API response.

📝 Syntax

intermediate

Which option correctly registers a POST method for a custom REST API endpoint?

You want to register a REST API endpoint in WordPress that accepts POST requests at /wp-json/custom/v1/data. Which code snippet correctly registers this endpoint?

A register_rest_route('custom/v1', '/data', ['methods' => 'post', 'callback' => 'handle_post']);

B register_rest_route('custom/v1', '/data', ['method' => 'POST', 'callback' => 'handle_post']);

C register_rest_route('custom/v1', '/data', ['methods' => ['GET', 'POST'], 'callback' => 'handle_post']);

D register_rest_route('custom/v1', '/data', ['methods' => 'POST', 'callback' => 'handle_post']);

💡 Hint

Check the key name and case sensitivity for HTTP methods.

The key must be 'methods' (plural) and the method name must be uppercase 'POST'. Option D uses correct syntax.

🔧 Debug

advanced

Why does this custom endpoint return a 404 error?

This code registers a custom REST API endpoint, but when accessing /wp-json/custom/v1/info, it returns a 404 error. What is the cause?

Wordpress

<?php
add_action('rest_api_init', function () {
  register_rest_route('custom/v1', 'info', [
    'methods' => 'GET',
    'callback' => function () {
      return ['info' => 'Details here'];
    },
  ]);
});

A The route path is missing a leading slash; it should be '/info'.

B The callback function must be named, anonymous functions are not allowed.

C The 'methods' key should be 'method' (singular).

D The 'rest_api_init' hook is incorrect; it should be 'init'.

💡 Hint

Check the route path format in register_rest_route.

The route path must start with a slash '/' to be recognized correctly. Without it, WordPress does not match the endpoint and returns 404.

❓ state_output

advanced

What is the output of this endpoint with permission callback?

Given this code, what will be the HTTP status code when an unauthenticated user requests /wp-json/custom/v1/secret?

Wordpress

<?php
add_action('rest_api_init', function () {
  register_rest_route('custom/v1', '/secret', [
    'methods' => 'GET',
    'callback' => function () {
      return ['secret' => '42'];
    },
    'permission_callback' => function () {
      return is_user_logged_in();
    },
  ]);
});

A 200 OK with JSON {"secret":"42"}

B 404 Not Found error

C 403 Forbidden error

D 401 Unauthorized error

💡 Hint

Consider what happens when permission_callback returns false.

If permission_callback returns false, WordPress returns 403 Forbidden, not 401 or 404.

🧠 Conceptual

expert

Which statement about custom REST API endpoint registration in WordPress is TRUE?

Select the one correct statement about registering custom REST API endpoints in WordPress.

A The 'rest_api_init' action must be used to register endpoints, and the route path must start with a slash.

B Endpoints can be registered anytime during the page load, even before 'init' hook.

C The 'callback' function must always return a WP_Error object for successful responses.

D Permission callbacks are optional but if omitted, the endpoint is always accessible.

💡 Hint

Think about when and how endpoints are registered and route path format.

Endpoints must be registered on 'rest_api_init' hook, and route paths require a leading slash. Permission callbacks are optional but if omitted, endpoint is accessible. Callback returns data, not WP_Error for success.

Practice

1. What is the main purpose of using add_rewrite_endpoint in WordPress?

easy

A. To enqueue styles and scripts

B. To register a new plugin in WordPress

C. To add a new URL part (endpoint) for custom content or actions

D. To create a new database table

Solution

1. Step 1: Understand the function purpose

   add_rewrite_endpoint is used to add new URL parts to WordPress URLs.

2. Step 2: Identify correct usage context

   This function helps create custom endpoints for special content or actions, not for plugins, tables, or scripts.

3. Final Answer:

   To add a new URL part (endpoint) for custom content or actions -> Option C

4. Quick Check:

   add_rewrite_endpoint adds URL parts = D [OK]

Hint: Endpoints add URL parts for custom content [OK]

Common Mistakes:

• Confusing endpoints with plugin registration
• Thinking it creates database tables
• Assuming it loads scripts or styles

2. Which hook is the correct place to call add_rewrite_endpoint when registering a custom endpoint?

easy

A. wp_footer

B. wp_enqueue_scripts

C. admin_menu

D. init

Solution

1. Step 1: Recall WordPress hook usage

   The init hook runs early and is the recommended place to add rewrite rules and endpoints.

2. Step 2: Eliminate incorrect hooks

   wp_enqueue_scripts is for scripts/styles, admin_menu is for admin menus, and wp_footer runs late in page rendering.

3. Final Answer:

   init -> Option D

4. Quick Check:

   add_rewrite_endpoint called on init hook = A [OK]

Hint: Use init hook for rewrite endpoints [OK]

Common Mistakes:

• Using wp_enqueue_scripts instead of init
• Adding endpoints in admin_menu hook
• Placing code in wp_footer hook

3. Given this code snippet, what will be the effect on the URL structure?

add_action('init', function() {
  add_rewrite_endpoint('special', EP_PERMALINK | EP_PAGES);
});

medium

A. Adds '/special/' as an endpoint to permalinks and pages URLs

B. Removes all existing endpoints from URLs

C. Creates a new admin menu called 'special'

D. Flushes rewrite rules automatically

Solution

1. Step 1: Analyze add_rewrite_endpoint parameters

   The first parameter 'special' is the endpoint name; the second parameter sets where it applies: permalinks and pages.

2. Step 2: Understand the effect on URLs

   This adds '/special/' to URLs of posts and pages, allowing custom handling of that URL part.

3. Final Answer:

   Adds '/special/' as an endpoint to permalinks and pages URLs -> Option A

4. Quick Check:

   Endpoint 'special' added to permalinks/pages = B [OK]

Hint: Endpoint name + location = new URL part [OK]

Common Mistakes:

• Thinking it removes endpoints
• Confusing endpoints with admin menus
• Assuming rewrite rules flush automatically

4. What is missing or incorrect in this code that registers a custom endpoint?

add_action('init', function() {
  add_rewrite_endpoint('promo', EP_ROOT);
});

medium

A. The endpoint name 'promo' is invalid

B. Rewrite rules are not flushed after adding the endpoint

C. The hook 'init' is incorrect for this function

D. The constant EP_ROOT cannot be used with add_rewrite_endpoint

Solution

1. Step 1: Check endpoint registration correctness

   The endpoint name 'promo' is valid, and EP_ROOT is a valid location constant.

2. Step 2: Identify missing step

   After adding endpoints, rewrite rules must be flushed (usually once) to apply changes; this code does not flush rules.

3. Final Answer:

   Rewrite rules are not flushed after adding the endpoint -> Option B

4. Quick Check:

   Flush rewrite rules after adding endpoints = C [OK]

Hint: Flush rewrite rules after adding endpoints [OK]

Common Mistakes:

• Skipping rewrite rules flush
• Using wrong hook instead of init
• Thinking endpoint names must be special

5. You want to add a custom endpoint 'download' that works on posts and pages, and you want to flush rewrite rules only once after activation. Which code snippet correctly achieves this?

hard

A. function add_download_endpoint() {
add_rewrite_endpoint('download', EP_PERMALINK | EP_PAGES);
}
add_action('init', 'add_download_endpoint');

register_activation_hook(__FILE__, function() {
add_download_endpoint();
flush_rewrite_rules();
});

B. add_action('init', function() {
add_rewrite_endpoint('download', EP_ALL);
flush_rewrite_rules();
});

C. function add_download_endpoint() {
add_rewrite_endpoint('download', EP_ROOT);
flush_rewrite_rules();
}
add_action('init', 'add_download_endpoint');

D. register_activation_hook(__FILE__, function() {
add_rewrite_endpoint('download', EP_PERMALINK | EP_PAGES);
});

Solution

1. Step 1: Register endpoint on init hook

   Function add_download_endpoint adds the endpoint on 'init' hook, which is correct.

2. Step 2: Flush rewrite rules only once on activation

   Using register_activation_hook to call the endpoint function and then flush rewrite rules ensures flushing happens once on plugin activation.

3. Step 3: Evaluate other options

   add_action('init', function() {
     add_rewrite_endpoint('download', EP_ALL);
     flush_rewrite_rules();
   });

   flushes rules on every page load (bad).

   function add_download_endpoint() {
     add_rewrite_endpoint('download', EP_ROOT);
     flush_rewrite_rules();
   }
   add_action('init', 'add_download_endpoint');

   flushes inside init (bad).

   register_activation_hook(__FILE__, function() {
     add_rewrite_endpoint('download', EP_PERMALINK | EP_PAGES);
   });

   does not flush rules at all.

4. Final Answer:

   Register endpoint on 'init' hook and flush rewrite rules once on plugin activation -> Option A

5. Quick Check:

   Register on init + flush once on activation = A [OK]

Hint: Flush rewrite rules once on activation, not every load [OK]

Common Mistakes:

• Flushing rewrite rules on every page load
• Not flushing rewrite rules at all
• Registering endpoint outside init hook