Advanced WordPress test (Advanced)

Sample questions

5 sample questions from the Advanced WordPress test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. What is REST API Cross-Origin Resource Sharing (CORS), and how does it compare with Same-Origin Policy (SOP)? When is CORS preferred?

   1. REST API Cross-Origin Resource Sharing (CORS) is a security measure that prevents malicious websites from accessing sensitive data. It is not essential when the front end and back end are hosted on different domains. In contrast, Same-Origin Policy (SOP) allows a web application running at one origin (domain) to make requests to a resource at a different origin. SOP is preferred when building distributed systems or when the front end and back end are on separate domains, as it provides a secure way to allow cross-origin requests.
   2. REST API Cross-Origin Resource Sharing (CORS) is a security measure that prevents malicious websites from accessing sensitive data. It is essential when the front end and back end are hosted on different domains. In contrast, Same-Origin Policy (SOP) allows a web application running at one origin (domain) to make requests to a resource at a different origin. SOP is preferred when building distributed systems or when the front end and back end are on separate domains, as it provides a secure way to allow cross-origin requests.
   3. REST API Cross-Origin Resource Sharing (CORS) allows a web application running at one origin (domain) to make requests to a resource at a different origin. It is essential when the front end and back end are hosted on different domains. In contrast, Same-Origin Policy (SOP) restricts web pages from making requests to a different domain than the one that served the web page. SOP is a security measure that prevents malicious websites from accessing sensitive data. CORS is preferred when building distributed systems or when the front end and back end are on separate domains, as it provides a secure way to allow cross-origin requests.
   4. REST API Cross-Origin Resource Sharing (CORS) allows a web application running at one origin (domain) to make requests to a resource at a different origin. It is not essential when the front end and back end are hosted on different domains. In contrast, Same-Origin Policy (SOP) restricts web pages from making requests to a different domain than the one that served the web page. SOP is a security measure that prevents malicious websites from accessing sensitive data. CORS is not preferred when building distributed systems or when the front end and back end are on separate domains, as it provides a secure way to allow cross-origin requests.

   Answer: C. REST API Cross-Origin Resource Sharing (CORS) allows a web application running at one origin (domain) to make requests to a resource at a different origin. It is essential when the front end and back end are hosted on different domains. In contrast, Same-Origin Policy (SOP) restricts web pages from making requests to a different domain than the one that served the web page. SOP is a security measure that prevents malicious websites from accessing sensitive data. CORS is preferred when building distributed systems or when the front end and back end are on separate domains, as it provides a secure way to allow cross-origin requests.

   REST API Cross-Origin Resource Sharing (CORS) allows a web application running at one origin (domain) to make requests to a resource at a different origin, which is essential in distributed systems. Same-Origin Policy (SOP) restricts such requests for security reasons. CORS is the correct choice when the front end and back end are hosted on different domains, as it provides a secure way to enable cross-origin requests.

2. When registering a custom post type in WordPress, which of the following is the correct approach regarding flushing rewrite rules?

   1. Flush rewrite rules only when the plugin is activated, not on every page load.
   2. Use a custom function to manually flush the rewrite rules on every post save.
   3. Flush rewrite rules on every page load to ensure consistency.
   4. Register the custom post type without using the 'flush_rewrite_rules()' function.

   Answer: A. Flush rewrite rules only when the plugin is activated, not on every page load.

   When registering a custom post type in WordPress, it is essential to flush the rewrite rules only during activation. This is because flushing rewrite rules on every page load can cause performance issues and unnecessary overhead. The correct approach is to use the 'flush_rewrite_rules()' function within the plugin activation hook, ensuring that the rewrite rules are only updated when necessary.

3. When registering a custom REST API route in WordPress, which of the following is a correct and required practice?

   1. Skip the permission_callback argument to allow unrestricted access to the endpoint.
   2. Define the permission_callback as a string instead of a function reference.
   3. Register a custom REST API route using register_rest_route with a permission_callback.
   4. Use the default permission callback for all endpoints to simplify development.

   Answer: C. Register a custom REST API route using register_rest_route with a permission_callback.

   When registering a custom REST API route in WordPress, it is required to provide a permission_callback function. This ensures that the endpoint is properly secured and only accessible to users with the appropriate permissions. Omitting this argument will trigger a _doing_it_wrong notice, as it is a core requirement of the register_rest_route function.

4. When developing a headless WordPress theme, which approach best aligns with the principles of a headless architecture?

   1. Use WordPress plugins to generate static HTML files for the front end and serve them via a CDN.
   2. Use WordPress themes to manage content and styling, but disable the admin panel for front-end users.
   3. Use a separate front-end application (e.g., Next.js) to consume the REST API and render content client-side, while keeping WordPress as the headless CMS.
   4. Create custom REST API endpoints for every page and use WordPress as the front-end server.

   Answer: C. Use a separate front-end application (e.g., Next.js) to consume the REST API and render content client-side, while keeping WordPress as the headless CMS.

   In a headless WordPress setup, the front end is decoupled from WordPress, and the CMS is used solely for content management. This is achieved by using the REST API or GraphQL to retrieve content and rendering it in a separate front-end application. This allows for greater flexibility in design and delivery, as the front end can be built with modern JavaScript frameworks.

5. A developer is trying to register a custom REST API endpoint with the following code: `register_rest_route('acme/v1', '/ping', ['methods' => 'GET', 'callback' => fn() => ['ok' => true]]);`. However, the endpoint is not working as expected. What is the most likely issue?

   1. The custom route is missing a required permission_callback argument.
   2. The custom route's callback function is not properly defined.
   3. The custom route is not registered under the correct base path.
   4. The custom route uses an incorrect namespace.

   Answer: A. The custom route is missing a required permission_callback argument.

   The register_rest_route function requires a permission_callback argument to be specified. If it is omitted, WordPress will trigger a _doing_it_wrong notice, and the endpoint will not be accessible as intended. This is a critical requirement for ensuring proper access control and security for custom REST API routes.