WordPress Developer interview questions

WordPress combines PHP application code, a database, themes, plugins, and uploaded media to serve a site.

• WordPress core provides the request handling, admin area, content APIs, users, and common services.
• A theme controls presentation, while plugins add or change behavior without editing core.
• MySQL or MariaDB stores content and settings, while wp-content/uploads normally stores media files.

The three directories separate administration, core libraries, and site-owned extensions and assets.

• wp-admin contains files used by the dashboard and administrative requests.
• wp-includes contains most WordPress core functions, classes, and bundled libraries.
• wp-content holds themes, plugins, and uploads, so custom work belongs there rather than in core directories.

WordPress stores content, users, comments, taxonomy relationships, and configuration in related database tables.

• wp_posts holds posts, pages, attachments, and custom post type records, with extra fields in wp_postmeta.
• wp_terms and related taxonomy tables represent categories, tags, and custom taxonomies.
• wp_options stores site-wide settings, while wp_users and wp_usermeta store accounts and user-specific data.

WordPress loads its environment, interprets the URL, runs the main query, selects a template, and sends the rendered response.

• Rewrite rules turn a friendly URL into query variables that describe the requested content.
• WordPress builds the main WP_Query and sets conditional state such as is_page() or is_archive().
• The template loader follows the active theme hierarchy, where PHP and template tags produce the HTML response.

The root index.php is the front controller that starts WordPress for normal front-end requests.

• Web server rewrite rules direct many public URLs to this single entry point.
• It loads wp-blog-header.php, which bootstraps WordPress and starts template output.
• The theme also has an index.php, but that file is the final classic-template fallback, not the application entry point.

Query variables are values WordPress uses to describe which content a request should retrieve.

• A request may resolve to values such as post_type, name, page_id, category_name, or paged.
• WP_Query reads these values to build the main database query and establish request context.
• Public custom query variables can be added with the query_vars filter when a feature genuinely needs them.

A minimal classic theme needs style.css and index.php to be recognized and render content.

• style.css contains the theme header with fields such as Theme Name and also may contain styles.
• index.php is the fallback when no more specific template exists.
• A real theme normally adds functions.php, header.php, footer.php, and specific hierarchy templates for maintainability.

The template hierarchy is the ordered set of theme files WordPress checks for the current request.

• A single post can match single-{post-type}-{slug}.php, single-{post-type}.php, single.php, singular.php, then index.php.
• More specific files let a theme customize one content context without conditional logic in a universal template.
• The hierarchy ends at index.php in a classic theme, so the request can still render when specific files are absent.

Conditional tags report what kind of request WordPress resolved so a theme can choose context-specific output.

• Functions such as is_front_page(), is_single(), and is_archive() return boolean values for common request types.
• They inspect the established query context, so most of them should be used only after WordPress has run the main query.
• I use them for small variations and prefer the template hierarchy when an entire view needs different markup.

front-page.php targets the site's front page, while home.php targets the posts index.

• If a static page is configured as the homepage, front-page.php can render that page.
• If another page is configured for posts, home.php renders the blog listing there.
• When the front page shows latest posts, front-page.php takes priority over home.php if both exist.

single.php handles individual posts, page.php handles Pages, and singular.php can be their shared fallback.

• A standard blog post normally resolves through single.php after more specific single templates.
• A Page normally resolves through custom page templates and page-specific files before page.php.
• singular.php is checked when a singular post, page, or custom post type lacks a more specific matching template.

WordPress can select archive templates by archive type before falling back to archive.php and index.php.

• category.php, tag.php, and taxonomy.php cover built-in or custom term archives, with more specific variants available.
• author.php and date.php cover author and date archives.
• archive-{post_type}.php handles a custom post type archive when that post type enables an archive.

A child theme inherits a parent theme and keeps custom changes separate from parent updates.

• Its style.css declares the parent directory in the Template header.
• Its templates can override matching parent templates, while its functions.php loads in addition to the parent's file.
• I use one to customize a maintained third-party theme, but not as a substitute for a plugin when behavior is theme-independent.

I use WordPress template-loading functions instead of copying shared markup between files.

• get_header(), get_footer(), and get_sidebar() load the corresponding theme sections.
• get_template_part() loads reusable pieces such as content-card.php and supports named variants.
• These functions let child themes override parts and give plugins WordPress lifecycle hooks around template loading.

The Loop iterates over posts returned by the current WP_Query and sets each one as the current post.

• have_posts() checks whether another result is available, and the_post() advances to it.
• Inside the loop, template tags such as the_title(), the_content(), and the_permalink() use current-post context.
• The main theme loop usually renders the content selected by WordPress for that request.

the_post() advances the query and prepares global post data for template tags.

• have_posts() only tests whether another result exists and does not move the query pointer.
• the_post() makes functions such as the_title() refer to the current result.
• Omitting it can leave the loop stuck or make template tags read stale context.

I call wp_reset_postdata() after a secondary WP_Query loop that used the_post().

• A custom loop changes the global $post used by many template tags.
• Resetting restores the current post from the main query so later tags show the expected content.
• wp_reset_query() is broader and is rarely needed for an ordinary secondary WP_Query.

Hooks are named extension points that let code run or change values without editing WordPress core.

• Actions notify callbacks that an event or stage has occurred.
• Filters pass a value through callbacks and use the returned value.
• Plugins and themes register callbacks with add_action() or add_filter(), which keeps custom behavior loosely connected to core.

An action performs work at a hook, while a filter receives a value and must return the resulting value.

• An action callback might register a post type on init or print markup in wp_footer.
• A filter callback might change excerpt_length or modify a title before display.
• Forgetting to return the value from a filter can replace it with null and break later behavior.

Priority controls callback order, and accepted arguments controls how many hook parameters the callback receives.

• Lower priority numbers run earlier, while callbacks with the same priority follow registration order.
• The default priority is 10, which is usually suitable unless ordering is required.
• The fourth parameter must match how many provided values the callback intends to accept.