WordPress Developer interview questions

I keep the main plugin file as a small composition root rather than the place where features are implemented.

• It defines the plugin header, guards direct access, and establishes path or version constants.
• It loads Composer's autoloader and wires service objects or hook registrars.
• It registers activation and deactivation callbacks from the main file, then delegates request-time work.

I use namespaces for PHP symbols and PSR-4 autoloading so classes map predictably to files.

• composer.json maps a vendor namespace such as Acme\Catalog to the src directory.
• The bootstrap requires vendor/autoload.php once instead of maintaining manual include chains.
• WordPress hook names, option keys, and global functions still need unique prefixes because namespaces do not cover them.

I split domain behavior, WordPress adapters, storage, and presentation instead of making one hook class own everything.

• Hook registrars translate WordPress actions or filters into calls on focused services.
• Repositories contain $wpdb or metadata access, while controllers handle REST or admin request contracts.
• Templates receive prepared view data and do not create queries or enforce business rules.

I check dependencies after plugins are loaded and before registering integration behavior.

• plugins_loaded is suitable for class or function availability because active plugins have been included by then.
• A dependency should be checked by a documented class, function, or API rather than only its directory name.
• If it is absent, the plugin should skip the integration and show an admin notice instead of causing a fatal error.

An activation callback runs as a one-time lifecycle operation, not as a normal fully initialized request.

• It should create schema or defaults idempotently and avoid assuming later hooks such as init have fired.
• If rewrite rules are needed, it must register the relevant structures before calling flush_rewrite_rules().
• The callback should not perform slow remote work or rely on output because activation may occur through admin, CLI, or network activation.

Deactivation stops temporary behavior, while uninstall may permanently remove owned data.

• Deactivation can unschedule cron events, release temporary resources, and flush changed rewrite rules.
• It normally preserves options, custom tables, and user content so reactivation is reversible.
• uninstall.php or register_uninstall_hook() may delete data after checking intent and any keep-data setting.

I put portable content behavior in a plugin and presentation tied to the active design in the theme.

• Post types, permissions, REST routes, and business rules should survive a theme switch.
• Templates, theme.json settings, patterns, and visual assets belong to the theme.
• A WooCommerce integration can keep pricing logic in a plugin while exposing theme templates or hooks for markup.

after_setup_theme runs after the theme files load but early enough to declare theme capabilities.

• add_theme_support(), register_nav_menus(), and image sizes belong there rather than on init.
• A child theme's functions.php loads before the parent's, while callbacks on this hook can use priorities for deliberate ordering.
• Request-dependent work does not belong there because the main query has not been established.

They mark dependency availability, theme setup, and general WordPress registration at different stages.

• plugins_loaded runs after active plugins are included, so plugin integrations can be wired there.
• after_setup_theme is for supports and theme-owned registrations after functions.php files load.
• init is later and suits post types, taxonomies, rewrite endpoints, and other request-wide registrations.

By wp, WordPress has parsed the request and built the main query, so query conditionals are meaningful.

• Functions such as is_singular() and is_archive() depend on the main WP_Query state.
• On init, post types exist but the requested object and conditional flags are not yet established.
• wp suits request-context decisions, while registration still belongs on earlier hooks.

I use template_redirect for redirects or response decisions after the query is known but before theme output.

• A redirect should call wp_safe_redirect() or wp_redirect() and then exit to prevent template output.
• Authentication gates and canonical redirects can inspect conditional tags at this stage.
• I do not include an alternative template there because template_include provides the proper filter contract.

template_include should return the final absolute template path without rendering it inside the callback.

• The incoming path is WordPress's hierarchy result and should remain the fallback.
• A plugin may replace it only for a narrowly matched request after confirming its template file exists.
• Because it is a filter, every branch must return a path and avoid echoing content.

I register REST routes on rest_api_init with a namespace, path, methods, and explicit callbacks.

• The namespace should include a stable vendor and version such as acme/v1.
• methods can use WP_REST_Server constants, while callback receives a WP_REST_Request.
• permission_callback is required and should express access policy separately from input handling.

The schema describes accepted input, validation rejects unacceptable values, and sanitization normalizes accepted ones.

• args can declare type, required, default, enum, and custom validate_callback or sanitize_callback.
• Validation should answer whether a value is allowed without silently changing its meaning.
• A sanitizer may trim or normalize a value, but the endpoint must still enforce domain rules in its service layer.

It should return true for authorized requests or a WP_Error that explains the denied access.

• For protected content I normally check a capability such as current_user_can('edit_post', $post_id).
• Returning __return_true is appropriate only for intentionally public data, not as a way to silence registration warnings.
• Authentication establishes identity, while permission_callback decides whether that identity may perform this operation.

A logged-in browser can use WordPress cookies, but state-changing REST requests also need a REST nonce.

• The client sends the wp_rest nonce in the X-WP-Nonce header, commonly through apiFetch middleware.
• WordPress verifies it to associate the request with the logged-in user and protect against CSRF.
• Without a valid nonce, cookie authentication is treated as unauthenticated rather than granting cookie privileges.

I return data or WP_REST_Response on success and WP_Error for expected failures.

• rest_ensure_response() normalizes arrays or objects into the REST response pipeline.
• WP_REST_Response lets the endpoint set status, headers, and links explicitly.
• WP_Error should carry a stable code, safe message, and status in error data so clients receive meaningful HTTP semantics.

admin-ajax.php dispatches actions by the action request field and the user's login state.

• wp_ajax_{action} handles authenticated users.
• wp_ajax_nopriv_{action} must also be registered when logged-out visitors may call the feature.
• Both callbacks should terminate with wp_send_json_success(), wp_send_json_error(), or wp_die() rather than falling through.

The nonce protects request intent, while the capability check protects authority.

• check_ajax_referer() rejects missing or invalid action-specific nonces and reduces CSRF risk.
• current_user_can() verifies that the current account may change the targeted resource.
• A valid nonce is not a role or permission and can be exposed to users who lack the requested capability.

I prefer REST for a resource-oriented API with typed inputs and reusable HTTP semantics, and keep AJAX for narrow legacy integrations.

• REST provides route discovery, methods, schemas, permission callbacks, and standard status handling.
• It is easier to consume from React, external clients, or tests without encoding every operation as one action parameter.
• admin-ajax.php remains reasonable when an existing admin feature already uses its hooks and no reusable API is needed.