WordPress-specific interview questions covering theme and plugin development, the block editor, REST API, security, and performance.
Show the key distinction: "Actions let me run code at a specific moment, like sending an email after a post is published. Filters let me modify data in transit, like changing the post title before it renders."
Actions execute code at specific points without returning a value — they fire and forget. Filters modify data by passing it through a chain of callbacks and returning the altered result. Both use the same underlying hook system (WP_Hook class). add_action/add_filter register callbacks; do_action/apply_filters trigger them. Priority controls execution order. Strong candidates discuss: remove_action/remove_filter for overriding third-party behaviour, the importance of accepting and returning the correct number of arguments in filters, and naming conventions for custom hooks.
Fundamental WordPress knowledge. Candidates who cannot clearly distinguish actions from filters will struggle with any non-trivial WordPress development. Ask them to name hooks they use regularly and why.
Frame the decision clearly: "If it is a distinct thing with its own fields and templates, it is a post type. If it is a way to group existing things, it is a taxonomy. A recipe is a post type; cuisine is a taxonomy."
Custom post types represent distinct content types (e.g., events, products, portfolios). Taxonomies classify and group content (e.g., event categories, product tags). Register post types with register_post_type() and taxonomies with register_taxonomy(), both hooked to init. Key decisions: rewrite slugs for SEO-friendly URLs, capability_type for custom permissions, show_in_rest for block editor and REST API support, has_archive for listing pages. Strong candidates discuss: when to use existing post types with custom taxonomies versus creating new post types, and the importance of setting show_in_rest to true for Gutenberg compatibility.
Tests content modelling ability. Candidates who create custom post types for everything when a taxonomy would suffice are over-engineering. Those who shoehorn everything into posts and categories lack architectural thinking.
Show modern practice: "I use block.json with a render.php callback for dynamic blocks. The block.json handles asset registration automatically, and server-side rendering ensures the block works even if JS fails."
Modern blocks use block.json for metadata (name, title, category, attributes, supports), with JavaScript for the edit component and either JS or PHP for the render. block.json enables automatic asset enqueuing, server-side registration via register_block_type(), and integration with the block directory. The older approach registered blocks entirely in JavaScript with registerBlockType(). Strong candidates discuss: static vs dynamic blocks, InnerBlocks for nested content, block variations and patterns, the @wordpress/scripts build toolchain, and when server-side rendering is preferable.
Tests current WordPress development skills. Candidates still building everything with shortcodes or Classic Editor widgets are behind. Those who understand the block editor architecture and can build custom blocks are more valuable for modern WordPress projects.
Lead with security: "Every custom endpoint gets a permission_callback — never return true blindly. I validate and sanitise every argument, use current_user_can for role checks, and return WP_Error with proper status codes on failure."
Register custom endpoints with register_rest_route() in the rest_api_init hook. Key parameters: namespace, route, methods, callback, and permission_callback. The permission_callback is critical — it must return true or a WP_Error to control access. Common patterns: checking current_user_can() for authenticated endpoints, using nonces for cookie-authenticated requests, and validating/sanitising input with validate_callback and sanitize_callback on args. Strong candidates discuss: registering custom fields on existing endpoints with register_rest_field(), authentication methods (cookies, application passwords, JWT), and rate limiting for public endpoints.
Tests API development skills in WordPress. Candidates who omit the permission_callback or return true for all routes are creating security vulnerabilities. Those who understand proper authentication and input validation build secure APIs.
Show the triad: "Sanitise on input with sanitize_text_field, escape on output with esc_html, and verify intent with nonces. I use $wpdb->prepare() for any custom SQL and always check current_user_can before privileged actions."
Core principles: sanitise input (sanitize_text_field, sanitize_email, wp_kses), escape output (esc_html, esc_attr, esc_url, wp_kses_post), and verify intent (wp_nonce_field/wp_verify_nonce for forms, check_ajax_referer for AJAX). Additional practices: use $wpdb->prepare() for custom queries, validate user capabilities before actions, keep WordPress and plugins updated, disable file editing (DISALLOW_FILE_EDIT), use proper file permissions, and implement Content Security Policy headers. Strong candidates distinguish between sanitisation (cleaning input) and escaping (safe output) and know which function to use where.
Critical for any WordPress developer. Candidates who use raw $_POST data without sanitisation or echo unescaped user content are security risks. The distinction between sanitisation and escaping is a good litmus test — many developers confuse them.
Lead with measurement: "I install Query Monitor, check the queries panel for slow or duplicate queries, then check the hooks panel for expensive actions. Object caching with Redis usually gives the biggest single improvement."
Systematic approach: start with Query Monitor plugin to identify slow queries, excessive hooks, and HTTP API calls. Common issues: N+1 queries from WP_Query in loops, missing object caching (add Redis or Memcached), unoptimised images, too many plugins, no page caching, and render-blocking assets. Solutions: implement persistent object cache, add page-level caching (WP Super Cache, WP Rocket, or a reverse proxy), use transients for expensive operations, lazy-load images, optimise autoloaders, and reduce query counts. Strong candidates discuss: the difference between page caching and object caching, when to use transients versus the object cache, and database query optimisation with custom indexes.
Senior question. Developers who jump to installing a caching plugin without diagnosing the root cause are treating symptoms. Those who can read Query Monitor output and systematically address database, caching, and asset loading issues are production-ready.
Show practical judgement: "For a marketing site where the client needs full layout control, I use a block theme with theme.json design tokens. For a complex application site with dynamic logic, a classic theme with targeted block support gives more control."
Classic themes use PHP template files (header.php, single.php, archive.php) with the template hierarchy. Block themes use HTML template files with block markup and theme.json for global styles and settings. Block themes enable Full Site Editing — users can modify headers, footers, and templates visually. Choose classic themes for complex dynamic logic or when clients need minimal editor access. Choose block themes for content-heavy sites where editorial flexibility matters. Strong candidates discuss: theme.json for design tokens, template parts for reusable sections, the template hierarchy in both systems, and hybrid approaches using block template parts within classic themes.
Tests awareness of modern WordPress direction. Candidates who only know classic themes are not keeping up. Those who understand both approaches and can articulate when each fits show mature WordPress expertise.
Show structure: "Main file bootstraps with Composer autoload. Classes are namespaced and split by concern. Activation creates tables with dbDelta. I use register_deactivation_hook to clean up cron events and uninstall.php to remove all data."
Good plugin architecture: a main plugin file that bootstraps the plugin, PSR-4 autoloading via Composer, classes organised by responsibility (Admin, Public, API, Models), and clear separation between WordPress hook registration and business logic. Activation hooks (register_activation_hook) handle database table creation and default options. Deactivation hooks clean up scheduled events. Uninstall hooks or uninstall.php remove all plugin data. For database changes: use dbDelta() for table creation/updates with proper charset and collation. Strong candidates discuss: using the singleton pattern sparingly, dependency injection where practical, and the WordPress coding standards.
Senior plugin development question. Candidates who dump everything in functions.php or a single plugin file will produce unmaintainable code. Those who use namespaces, autoloading, and proper activation/deactivation lifecycle management build professional plugins.
Frame the trade-off: "Multisite simplifies management when sites are similar — shared updates, shared users, one dashboard. But it creates a blast radius: a bad plugin update takes down every site. I recommend it for tightly related sites and separate installs for independent projects."
Multisite is appropriate when sites share users, themes, and plugins under one admin — for example, a university with departmental sites or a franchise with location pages. Separate installations suit sites with different hosting requirements, independent update cycles, or distinct plugin sets. Multisite implications: plugins can be network-activated or per-site, themes are network-enabled then activated per-site, and the database uses separate tables per site (with a shared users table). Strong candidates discuss: switch_to_blog()/restore_current_blog() for cross-site queries, the wp_is_large_network() performance consideration, domain mapping, and the risk that one plugin breaking affects all sites.
Tests architectural judgement. Candidates who recommend Multisite for unrelated sites or who have never used it both lack experience. Those who understand the shared-risk model and can articulate when centralised management outweighs the coupling are strong.
Be honest about trade-offs: "Headless gives me a modern frontend stack and great performance. But I lose the block editor preview, most plugin frontends, and I now manage two deployments. I only recommend it when the frontend requirements genuinely outgrow PHP templating."
Headless WordPress uses WordPress as a CMS backend (via REST API or WPGraphQL) with a separate frontend framework (Next.js, Nuxt, Astro). Benefits: modern frontend tooling, better performance with static generation, freedom from PHP templating, and separation of concerns. Trade-offs: lose the block editor preview, lose plugin frontend features (forms, SEO plugins, page builders), increased complexity with two deployments, and higher development cost. Strong candidates discuss: when headless is justified (performance-critical sites, multi-channel content, team expertise in React/Vue) and when traditional WordPress is better (content-heavy sites relying on plugin ecosystems, smaller budgets, editorial UX).
Tests whether candidates follow trends thoughtfully. Those who push headless for every project are ignoring the cost. Those who dismiss it entirely are not keeping up. Best answers match the architecture to the project requirements and team capabilities.
Show awareness of the cost: "Meta queries JOIN the postmeta table for every key. I move filterable data into taxonomies where possible and set no_found_rows to true on queries that do not need pagination to skip the COUNT query."
WP_Query builds SQL from arguments like post_type, posts_per_page, tax_query, and meta_query. Meta queries are slow by default because postmeta has no composite indexes — querying by multiple meta keys generates JOINs that scale poorly. Tax queries are generally faster because term_relationships is indexed. Optimisation: use taxonomy-based filtering over meta queries where possible, add custom database indexes for frequently queried meta keys, use fields => ids when you only need post IDs, and set no_found_rows => true when you do not need pagination totals. Strong candidates discuss: pre_get_posts for modifying the main query, the difference between main query and secondary queries, and when to use get_posts() versus new WP_Query().
Tests database awareness in WordPress. Candidates who use meta_query for everything without understanding the performance cost will build slow sites. Those who know when to use taxonomies versus meta and how to optimise queries demonstrate real experience.
Walk through a concrete example: "For a custom post type 'event' with slug 'annual-gala', WordPress looks for single-event-annual-gala.php, then single-event.php, then single.php, then singular.php, then index.php."
WordPress follows a hierarchy from most specific to least specific. For a single post: single-{post_type}-{slug}.php → single-{post_type}.php → single.php → singular.php → index.php. For archives: archive-{post_type}.php → archive.php → index.php. For taxonomies: taxonomy-{taxonomy}-{term}.php → taxonomy-{taxonomy}.php → taxonomy.php → archive.php → index.php. Template parts (get_template_part) allow reuse. Child themes override parent templates by filename. Strong candidates mention: template_include filter for programmatic overrides, is_singular()/is_archive() for conditional logic, and how block themes change the hierarchy with HTML template files.
Fundamental WordPress knowledge. Candidates who cannot explain the template hierarchy will struggle to debug why the wrong template is rendering. Ask them to trace the hierarchy for a specific content type they have worked with.
Be pragmatic: "ACF for client projects where speed matters and the plugin dependency is acceptable. Custom meta boxes for plugins or themes I distribute, because I cannot require ACF as a dependency."
ACF (Advanced Custom Fields): fastest development time, great UI, field groups with conditional logic, repeaters, flexible content. Downside: plugin dependency and potential vendor lock-in. Custom meta boxes: native WordPress, no dependencies, full control, but more code for complex field types. Built-in Custom Fields screen: too basic for anything beyond simple key-value pairs. The choice depends on: project budget (ACF is faster), long-term maintenance (native is more durable), and field complexity (ACF repeaters are hard to replicate natively). Strong candidates discuss: storing ACF data in postmeta and the serialisation gotcha, the register_meta() function for REST API exposure, and Carbon Fields or CMB2 as alternatives.
Tests practical WordPress experience. Candidates who cannot work without ACF may lack understanding of the underlying meta system. Those who refuse to use ACF on principle are ignoring a tool that saves significant development time. Look for nuanced judgement.
Prefer hooks over overrides: "I customise checkout with woocommerce_checkout_fields to add or modify fields and woocommerce_checkout_update_order_meta to save them. Template overrides are a last resort because they break on WooCommerce updates."
WooCommerce provides extensive hooks for every part of the purchase flow: woocommerce_before_cart, woocommerce_checkout_process, woocommerce_payment_complete, etc. Template overrides: copy WooCommerce template files to your theme under woocommerce/ directory. Checkout customisation: add fields with woocommerce_after_order_notes, validate with woocommerce_checkout_process, save with woocommerce_checkout_update_order_meta. For payment gateways: extend WC_Payment_Gateway. Strong candidates discuss: the risk of template overrides becoming stale on WooCommerce updates, using hooks instead of overrides where possible, the WooCommerce REST API for headless commerce, and HPOS (High-Performance Order Storage) compatibility.
Tests ecommerce WordPress skills. Candidates who modify WooCommerce core files or rely heavily on template overrides will create maintenance nightmares. Those who understand the hook-first approach and HPOS compatibility build future-proof stores.
Show production awareness: "I disable WP-Cron and use a real server cron hitting wp-cron.php every minute. This ensures tasks run on time regardless of traffic. For heavy background processing, I use Action Scheduler."
WP-Cron is triggered by page visits, not by the system clock. On each request, WordPress checks if any scheduled events are due and runs them. Limitations: events do not fire if there is no traffic, multiple near-simultaneous visitors can trigger the same event, and cron tasks add latency to the triggering request. Workarounds: disable WP-Cron in wp-config (DISABLE_WP_CRON) and set up a real server cron that hits wp-cron.php at regular intervals. For heavy tasks: use Action Scheduler (used by WooCommerce) which queues jobs in the database and processes them in batches. Strong candidates mention: wp_schedule_event for recurring tasks, wp_schedule_single_event for one-off tasks, and the importance of checking if an event is already scheduled before adding it.
Tests understanding of WordPress internals. Candidates who do not know WP-Cron is visitor-triggered will schedule critical tasks that silently fail on low-traffic sites. Those who know to use a real cron and Action Scheduler demonstrate production readiness.
Show the safety pattern: "I always use $wpdb->prepare() with typed placeholders. For custom tables, I use $wpdb->prefix to support multisite. I reach for $wpdb only when WP_Query or get_posts cannot express what I need."
Use $wpdb when WordPress API functions cannot express the query you need — complex joins, aggregations, bulk operations, or custom tables. Safety: always use $wpdb->prepare() with placeholders (%s, %d, %f) to prevent SQL injection. Use $wpdb->prefix for table names to support multisite. Common methods: $wpdb->get_results(), $wpdb->get_var(), $wpdb->get_row(), $wpdb->insert(), $wpdb->update(), $wpdb->delete(). Strong candidates discuss: when get_posts/WP_Query is insufficient, creating custom tables versus using postmeta, using dbDelta() for table creation, and the WPDB class methods for different return types.
Tests database skills in WordPress context. Candidates who never use $wpdb may not know how to solve complex data problems. Those who use it without prepare() are a security risk. Look for candidates who know when the WordPress API is insufficient and can write safe SQL.
Cover the essentials: "Every string gets __() or _e() with the text domain. I generate POT files with wp i18n make-pot, and use wp_set_script_translations for any translatable JavaScript strings."
Wrap all user-facing strings in translation functions: __() for returning translated strings, _e() for echoing them, esc_html__() and esc_attr__() for escaped translated strings, _n() for singular/plural, and _x() for context-dependent translations. Each plugin/theme declares a text domain matching its slug. Translation files (.po for source, .mo for compiled) go in the languages directory. Modern workflow: use wp i18n make-pot to extract strings, translate with Poedit or GlotPress, and ship .mo files. Strong candidates mention: the difference between load_plugin_textdomain() and load_theme_textdomain(), JSON translation files for JavaScript (wp_set_script_translations), and that WordPress.org handles translations via GlotPress for plugins in the directory.
Baseline internationalisation skill. Candidates who hardcode English strings throughout will produce themes and plugins that cannot be translated. Those who know the full workflow including JavaScript translations demonstrate thoroughness.
Show the decision framework: "If I am customising less than 30% of a quality parent theme, a child theme saves time and gets updates. Beyond that, I build from scratch because the child becomes harder to maintain than a custom theme."
Child themes inherit functionality from a parent theme and allow customisation without modifying the parent — safe for parent theme updates. Use child themes when: customising a commercial theme, making minor modifications to an existing theme, or learning theme development. Build from scratch when: requirements are unique, no suitable parent exists, or the child overrides so much that the parent is mostly dead weight. Pitfalls: parent theme updates can break child theme overrides if template structure changes, performance overhead of loading two themes, and debugging is harder when behaviour is split across parent and child. Strong candidates mention: style.css Template header for declaring the parent, wp_enqueue_style for properly loading parent styles (not @import), and that functions.php files are additive (child loads before parent).
Tests practical theme development judgement. Candidates who always use child themes may not be able to build from scratch. Those who never use them may be reinventing work unnecessarily. Look for the ability to assess which approach fits the project.
Show the relationship: "Without Redis, transients hit the database. With Redis, they are stored in memory and never touch the DB. I use transients for any expensive operation with a known TTL — like caching an API response for 1 hour."
Transients: key-value store with optional expiration, stored in the options table by default but upgraded to object cache when a persistent cache backend (Redis, Memcached) is available. Options: permanent key-value store, autoloaded on every request (if autoload is yes), no expiration. Object Cache: per-request in-memory cache by default, but persistent backends make it survive across requests. Use transients for: expensive API calls, complex query results, and data that can be stale for a known period. Use options for: settings and configuration that rarely change. Use object cache for: any data you want cached with automatic invalidation. Strong candidates explain: when persistent object cache is present, transients bypass the database entirely, making them equivalent to the object cache with an expiration wrapper.
Tests caching knowledge in WordPress. Candidates who do not know about transients will repeat expensive operations on every page load. Those who understand the relationship between transients and the object cache can design efficient caching strategies.
Always use serialisation-safe tools: "I export with wp db export, transfer files with rsync, and run wp search-replace for URL changes. Never use sed on a WordPress database dump — it breaks serialised data."
Migration involves: database export/import, file transfer (wp-content), and URL replacement. The critical challenge: WordPress stores serialised PHP data in the database (widget settings, plugin options, theme mods). Simple find-and-replace on SQL dumps breaks serialised strings because the byte-length prefix becomes incorrect. Solutions: WP-CLI search-replace (handles serialised data correctly), migration plugins (All-in-One WP Migration, Duplicator), or manual export with wp db export followed by wp search-replace. Strong candidates mention: wp-config.php adjustments for the new environment, file permission issues, the wp_options siteurl and home rows, and testing after migration.
Practical WordPress operations skill. Candidates who use SQL find-and-replace will corrupt serialised data and spend hours debugging mysterious breakages. Those who know WP-CLI search-replace or equivalent tools handle migrations reliably.
Emphasise the database caveat: "add_role writes to the database, so I only call it in register_activation_hook or behind a version check. Running it on every request is a wasted database write."
WordPress has five default roles (Administrator, Editor, Author, Contributor, Subscriber), each with a set of capabilities. Capabilities are checked with current_user_can(). Add custom roles with add_role() and modify capabilities with add_cap()/remove_cap(). Critical: these functions write to the database, so wrap them in activation hooks or version checks — do not call them on every page load. Use the Members plugin or custom code for management. Strong candidates discuss: mapping capabilities to custom post types via capability_type and map_meta_cap, the user_has_cap filter for dynamic capability checks, and removing roles/capabilities cleanly on plugin deactivation.
Tests understanding of WordPress access control. Candidates who call add_role on init without guards are wasting database writes. Those who understand capability mapping for custom post types can build proper permission models.
Show a practical setup: "WP_DEBUG and WP_DEBUG_LOG on in development. Query Monitor for database and hook debugging. Xdebug with VS Code for stepping through complex issues. WP-CLI for database and plugin management."
Debugging: WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY constants in wp-config.php. Query Monitor plugin for database queries, hooks, HTTP requests, and PHP errors. Xdebug for step-through debugging. error_log() for quick logging. Local development: LocalWP (easiest), Docker with WordPress image, DAMP/LAMP stack, or wp-env (official). Strong candidates mention: SAVEQUERIES constant for query logging, wp-cli for command-line operations, browser DevTools for frontend debugging, and Health Check plugin for troubleshooting without affecting other users.
Baseline professional WordPress development. Candidates who debug by adding var_dump and refreshing are missing essential tools. Those who know Query Monitor, Xdebug, and WP-CLI have a professional debugging workflow.
Clarify the three concepts: "Patterns are starter layouts you insert and customise freely. Synced patterns stay linked across the site. Template parts are structural blocks like headers that define the site shell."
Block patterns are predefined arrangements of blocks that users can insert and then modify freely — the inserted blocks are independent copies. Reusable blocks (synced patterns in WordPress 6.3+) stay linked: editing one updates all instances. Template parts are structural pieces (headers, footers) used in block themes via the Site Editor. Register custom patterns with register_block_pattern() or place PHP files in the patterns/ directory of a block theme. Strong candidates discuss: pattern categories for organisation, using theme.json to control which core patterns appear, the difference between synced and unsynced patterns, and how patterns accelerate content creation for editors.
Tests modern WordPress block editor knowledge. Candidates who confuse these three concepts will give incorrect guidance to content editors. Those who can register custom patterns and explain the synced/unsynced distinction demonstrate current block editor expertise.
Show automation: "I use wp search-replace in deployment scripts for URL updates, wp cron event run to test scheduled tasks, and wp scaffold block to generate block boilerplate. Anything repeatable gets scripted with WP-CLI."
WP-CLI is essential for: bulk operations (wp post delete, wp user create), database management (wp db export, wp search-replace), plugin/theme management (wp plugin install, wp plugin update), scaffolding (wp scaffold plugin, wp scaffold block), cron management (wp cron event list, wp cron event run), and maintenance (wp cache flush, wp rewrite flush). Significantly easier than UI: bulk user imports, search-replace across serialised data, running cron events on demand, and scripting repeatable deployment steps. Strong candidates describe: using WP-CLI in deployment scripts, custom WP-CLI commands for project-specific tasks, and piping WP-CLI output to other tools.
Tests professional workflow maturity. Candidates who do everything through the admin UI are slower and less reliable for operations tasks. Those who integrate WP-CLI into their workflow can automate deployments, manage environments, and handle bulk operations efficiently.
Show defensive coding: "I use wp_remote_get with a timeout, check is_wp_error and the status code, cache successful responses in a transient, and fall back to stale cached data if the API fails."
Use wp_remote_get()/wp_remote_post() for HTTP requests — never use file_get_contents or raw cURL in WordPress. Check responses with wp_remote_retrieve_response_code() and wp_remote_retrieve_body(). Cache responses with transients to avoid repeated API calls. Handle failures: check is_wp_error(), implement exponential backoff for retries, show cached stale data when the API is down, and log errors for monitoring. Strong candidates discuss: setting appropriate timeouts, sanitising API response data before use, using wp_safe_remote_get() for user-supplied URLs, and the pre_http_request filter for mocking in tests.
Senior integration question. Candidates who use file_get_contents for HTTP requests are ignoring the WordPress HTTP API and its benefits (consistent SSL handling, proxy support, transport abstraction). Those who cache responses and handle failures gracefully build reliable integrations.
Show the pattern: "have_posts() checks if there are posts left, the_post() advances to the next one and sets up global post data. Inside I use the_title(), the_content(), the_permalink(). After a custom query, I call wp_reset_postdata()."
The Loop is the PHP code WordPress uses to iterate over queried posts and display them. The basic structure: if (have_posts()) while (have_posts()) the_post() — this sets up the global $post variable for each iteration. Inside the loop, template tags like the_title(), the_content(), the_excerpt(), the_permalink(), the_post_thumbnail(), and the_date() output post data. The loop works with both the main query and custom WP_Query instances. Strong candidates explain: the difference between the main loop (driven by the URL) and secondary loops (custom WP_Query), why wp_reset_postdata() is needed after a secondary loop, and the difference between the_title() (echoes) and get_the_title() (returns).
Fundamental WordPress concept. Candidates who cannot explain The Loop will struggle with any theme development. Ask them the difference between the_ functions and get_the_ functions — it reveals whether they understand echoing versus returning.
Explain the why: "The enqueue system handles dependencies and prevents duplicates. If two plugins both need jQuery, it loads once. Hardcoded script tags would load it twice and break things."
Use wp_enqueue_style() and wp_enqueue_script() hooked to wp_enqueue_scripts (frontend) or admin_enqueue_scripts (admin). Each asset gets a handle (unique name), source URL, dependencies array, version string, and media type (CSS) or footer flag (JS). The enqueue system prevents duplicate loading, manages dependencies automatically, and allows other plugins and themes to dequeue or modify assets. Never hardcode link or script tags — it causes duplicate loading, breaks dependency order, and prevents child themes from overriding. Strong candidates mention: wp_register_style/script for registering without enqueuing, wp_localize_script or wp_add_inline_script for passing PHP data to JavaScript, and using the $ver parameter for cache busting.
Baseline WordPress development skill. Candidates who hardcode script and style tags in header.php will create conflicts with plugins and child themes. Those who understand the enqueue system build compatible themes and plugins.
Cover both eras: "I register sidebars with register_sidebar, display them with dynamic_sidebar. Since WordPress 5.8, widget areas accept blocks — so users can put paragraphs, images, or any block in the sidebar, not just legacy widgets."
Sidebars are widget-ready areas registered with register_sidebar() in functions.php, hooked to widgets_init. They define before_widget, after_widget, before_title, and after_title HTML wrappers. Display them in templates with dynamic_sidebar(). Since WordPress 5.8, the widget editor uses blocks — users can add any block to widget areas, not just traditional widgets. Classic widgets still work alongside blocks. Strong candidates explain: the difference between sidebars (the area) and widgets (the content placed in them), that a theme can have multiple sidebars (header, footer, sidebar), and that the block-based editor provides much more flexibility but some themes still use the classic widget screen via the Classic Widgets plugin.
Tests knowledge of WordPress widget system. Candidates who only know the classic widget approach are behind on the block-based transition. Those who understand both and can explain the migration path demonstrate current WordPress knowledge.
Show the flow: "Register locations with register_nav_menus, the admin creates menus and assigns them to locations, and the theme outputs them with wp_nav_menu. I use a custom Walker class when I need specific HTML structure for the navigation."
Register menu locations with register_nav_menus() in functions.php, hooked to after_setup_theme. This tells WordPress the theme supports menus at named locations (primary, footer, etc.). Administrators create menus in Appearance → Menus, adding pages, posts, categories, custom links, and arranging them with drag-and-drop. Display in templates with wp_nav_menu() passing the theme_location argument. Key parameters: container (wrapper HTML), menu_class (CSS class on the ul), depth (nesting level), fallback_cb (what to show if no menu is assigned), and walker (custom Walker_Nav_Menu for advanced HTML output). Strong candidates mention: that block themes use the Navigation block instead of wp_nav_menu(), menu items can have CSS classes for styling active states, and the wp_nav_menu_items filter for programmatically adding items.
Entry-level theme development question. Candidates who hardcode navigation links will produce themes that clients cannot edit. Those who understand the menu registration and display flow build themes that are genuinely user-friendly.
Show the benefit: "theme.json replaces a dozen add_theme_support calls with one file. I define colour palettes and font sizes there, and WordPress generates CSS variables and restricts the editor to those choices — consistent design without custom CSS."
theme.json is a configuration file that controls the block editor experience and global styles. Settings: define colour palettes, font families, font sizes, spacing presets, layout widths, and which block features are enabled or disabled (custom colours, gradients, padding). Styles: set default typography, colours, and spacing for the entire site and individual blocks. It replaces add_theme_support() calls and editor-style.css with a single declarative file. theme.json generates CSS custom properties automatically. Strong candidates explain: the schema version, that theme.json works in both classic and block themes, the settings versus styles distinction, and that it controls what options editors see in the block editor sidebar.
Tests modern WordPress knowledge. Candidates who do not know theme.json are missing the central configuration mechanism for block editor themes. Those who understand it can build themes that give editors controlled flexibility.
Keep it simple: "update_post_meta to save, get_post_meta with true for a single value. I prefix keys with the plugin or theme name to avoid collisions. For querying, I use meta_query in WP_Query but keep in mind it is slower than taxonomy queries."
Post meta (custom fields) stores key-value pairs associated with a post in the wp_postmeta table. Store with update_post_meta($post_id, $key, $value), retrieve with get_post_meta($post_id, $key, true). The third parameter (true) returns a single value instead of an array. Delete with delete_post_meta(). Meta can be any serialisable value — strings, numbers, or arrays (WordPress serialises them automatically). Common uses: storing extra data like event dates, product prices, or custom settings that do not fit standard post fields. Strong candidates mention: that meta keys starting with underscore are hidden from the Custom Fields UI, the meta_key and meta_value parameters in WP_Query for querying by meta, and that ACF and similar plugins store their data as post meta.
Fundamental WordPress data storage concept. Candidates who cannot explain post meta will struggle with any custom data requirements. Those who understand the API and the performance implications of meta queries versus taxonomies make better architecture decisions.
Show both approaches: "In a classic theme, I create a PHP file with the Template Name header — it appears in the Page Attributes dropdown. In a block theme, I add an HTML template file to the templates/ directory and it shows up in the Site Editor."
Page templates are PHP files that provide alternative layouts for individual pages. Create one by adding a Template Name comment header at the top of a PHP file in the theme directory: /* Template Name: Full Width */. The template then appears as a dropdown option in the page editor. Use cases: landing pages without sidebars, contact pages with special layouts, portfolio grids, or any page that needs a different structure from the default. In block themes, templates are HTML files in the templates/ directory. Strong candidates explain: that page templates only apply to the Page post type by default (Template Post Type header extends this), the naming convention page-{slug}.php for automatic template assignment, and that block themes define templates differently using HTML with block markup.
Entry-level theme development question. Candidates who do not know how to create page templates will produce inflexible themes. Those who understand both classic and block theme template approaches demonstrate versatility.
Show the transition: "Shortcodes work everywhere and are simple to implement — add_shortcode with a callback that returns HTML. For new features, I prefer custom blocks because users get a visual preview. But shortcodes are still the right choice for dynamic content in places blocks cannot reach."
Shortcodes are bracketed tags like [gallery] that WordPress replaces with dynamic content. Register with add_shortcode(tag, callback) — the callback receives attributes and optional enclosed content, and returns HTML. Self-closing: [button url="/"]. Enclosing: [highlight]text[/highlight]. Shortcodes predate the block editor and are still widely used in plugins. When to use blocks instead: blocks provide a visual editing experience with a live preview, which is better for most use cases. Shortcodes are still appropriate for: backwards compatibility, simple inline dynamic content, and contexts where the block editor is not available (widgets, text areas, custom fields). Strong candidates mention: that shortcodes should always return output (not echo it), the do_shortcode() function for processing shortcodes in custom locations, and that the block editor has a Shortcode block for embedding shortcodes.
Entry-level WordPress question. Candidates who cannot create a basic shortcode lack fundamental plugin development skills. Those who also understand when blocks are a better choice show awareness of the evolving WordPress landscape.
Cover the full workflow: "Enable with add_theme_support, register custom sizes with add_image_size, display with the_post_thumbnail. After adding sizes to an existing site, I regenerate thumbnails with WP-CLI: wp media regenerate."
Enable featured image support with add_theme_support('post-thumbnails') in functions.php. Register custom image sizes with add_image_size(name, width, height, crop). WordPress generates the registered sizes when an image is uploaded. Display in templates with the_post_thumbnail(size) inside The Loop, or get_the_post_thumbnail_url(post_id, size) for the URL. Default sizes: thumbnail, medium, large, full. Strong candidates explain: that sizes are generated at upload time (not on the fly), the regenerate thumbnails process needed after adding new sizes, the srcset attribute WordPress adds automatically for responsive images, and how to control which sizes appear in the media inserter with the image_size_names_choose filter.
Basic theme development knowledge. Candidates who hardcode image dimensions or do not register proper sizes will produce themes with poorly sized images. Those who understand the thumbnail generation pipeline and responsive srcset output build performant image-heavy sites.
Draw the distinction: "Options are for site-wide settings — one value for the whole site. Post meta is for per-post data — different values for each post. I use the Settings API to build admin pages that save options with proper nonce verification."
The Options API stores site-wide key-value settings in the wp_options table. Store with update_option(key, value), retrieve with get_option(key, default), delete with delete_option(key). Options are for global settings (site title, permalink structure, plugin settings), not per-post data — that is what post meta is for. Options with autoload set to yes are loaded into memory on every page load for fast access. Strong candidates explain: that plugins should prefix option names to avoid collisions, the Settings API (register_setting, add_settings_section, add_settings_field) for building admin settings pages, that serialised arrays and objects can be stored as a single option, and the performance difference between autoloaded and non-autoloaded options.
Fundamental WordPress data storage question. Candidates who confuse options with post meta or who store per-post data in options have a data architecture gap. Those who understand autoloading and the Settings API build efficient, well-structured plugins.