WP/PHP/Thrivase Flashcards
(500 cards)
Q: What’s the main WordPress folder structure?
A: wp-admin, wp-content, wp-includes, plus root files like wp-config.php.
The main WordPress folder structure is organized into three primary directories and several root files, each with specific roles:
wp-admin: Contains all files for the admin dashboard, including admin-ajax.php (AJAX handling), admin.php (core admin logic), and subfolders like css, js, and images for admin styling and scripts.
wp-content: Houses user-customizable content, with subfolders:
- themes (stores theme files like twentytwentythree),
- plugins (holds plugin files like hello-dolly),
- uploads (media files, organized by year/month, e.g., 2025/02),
- and optional mu-plugins (must-use plugins).
wp-includes: Includes core WordPress PHP files and libraries, such as class-wp-query.php (query handling), functions.php (general functions), and subfolders like js and css for front-end assets.
Root Files: Key files in the WordPress root include wp-config.php (database settings, salts), index.php (entry point loading core), wp-blog-header.php (initializes environment), wp-settings.php (sets up WordPress), and wp-load.php (bootstraps for external scripts).
This structure separates core functionality, admin tools, and user content, enabling customization while protecting the system.
Q: What does wp-config.php configure?
A: Database connection, salts, debug settings.
The wp-config.php file configures essential WordPress settings, primarily:
Database Connection: Defines database credentials—DB_NAME (database name), DB_USER (username), DB_PASSWORD (password), DB_HOST (host, e.g., localhost), and DB_CHARSET (character set, e.g., utf8).
Authentication Salts: Sets unique keys and salts (e.g., AUTH_KEY, SECURE_AUTH_SALT) to secure cookies and passwords.
Table Prefix: Specifies the database table prefix via $table_prefix (default wp_) for multiple installations or security.
Debugging: Enables debugging with WP_DEBUG (e.g., define(‘WP_DEBUG’, true)), plus WP_DEBUG_LOG and WP_DEBUG_DISPLAY for logging and display options.
Other Settings: Can override memory limits (WP_MEMORY_LIMIT), disable auto-updates (define(‘AUTOMATIC_UPDATER_DISABLED’, true)), or set site URLs (WP_HOME, WP_SITEURL).
Located in the WordPress root, it’s a critical, editable file that doesn’t ship with defaults—generated during installation or manually created.
Q: What’s the role of index.php in the root?
A: Entry point—loads WordPress core.
The index.php file in the WordPress root serves as the primary entry point for all front-end requests, initiating the WordPress loading process. It contains minimal code—typically just a few lines—that kickstarts the system:
It defines the WP_USE_THEMES constant as true to enable theme usage.
It includes wp-blog-header.php via a require statement (e.g., require __DIR__ . ‘/wp-blog-header.php’;), which then loads the core WordPress environment, including wp-load.php, wp-settings.php, and the template loader.
This triggers the entire WordPress bootstrap: database connection, core functions, plugins, themes, and finally, rendering the requested page (e.g., via The Loop).
As the default file for web servers (e.g., Apache, Nginx), it handles all URL requests (e.g., example.com/ or example.com/about) by routing them through WordPress’s rewrite system.
In essence, index.php acts as the gateway, delegating to other files to process and display content, making it indispensable for WordPress’s operation.
Q: What’s wp-content?
A: Stores themes, plugins, uploads.
The wp-content directory in WordPress is the central hub for all user-generated and customizable content, located in the root folder (e.g., /wp-content). It’s where WordPress stores:
themes: Subdirectory (wp-content/themes) containing theme folders (e.g., twentytwentythree), each with files like style.css, index.php, and functions.php for site appearance and functionality.
plugins: Subdirectory (wp-content/plugins) holding plugin folders (e.g., hello-dolly), each with PHP files (e.g., hello-dolly.php) to extend WordPress features.
uploads: Subdirectory (wp-content/uploads) storing media files (e.g., images, PDFs), organized by year and month (e.g., 2025/02/image.jpg), managed via the Media Library.
mu-plugins: Optional subdirectory (wp-content/mu-plugins) for “must-use” plugins, auto-activated PHP files (e.g., my-mu-plugin.php) that can’t be disabled from the admin.
Other Possible Folders: languages (for translations), cache (added by caching plugins), or custom folders created by plugins/themes.
Unlike wp-includes or wp-admin, wp-content is fully editable by users, preserved during core updates, and critical for site customization—making it the heart of a WordPress site’s unique identity.
Q: What’s wp-includes?
A: Core WordPress functions and libraries.
The wp-includes directory in WordPress, located in the root folder (e.g., /wp-includes), contains the core PHP files and libraries that power WordPress’s functionality, forming the backbone of its system. Key aspects include:
Core Functions: Houses essential files like functions.php (general utilities like wp_die()), class-wp-query.php (query handling), and plugin.php (hook system), defining WordPress’s built-in capabilities.
Classes and Objects: Includes object-oriented files such as class-wp-user.php (user management), class-wp-post.php (post handling), and class-wpdb.php (database access via $wpdb).
Subdirectories: Contains folders like js (JavaScript libraries, e.g., jquery), css (styles for core features), and fonts (default font assets), supporting both front-end and back-end rendering.
Utility Files: Features files like formatting.php (e.g., sanitize_text_field()), shortcodes.php (shortcode API), and media.php (media handling), used across themes and plugins.
Immutable: Unlike wp-content, it’s part of the core installation, overwritten during updates, and not meant for direct user edits—custom code goes elsewhere (e.g., functions.php).
In short, wp-includes is the engine room of WordPress, providing the reusable, foundational code that drives posts, users, queries, and more, ensuring consistent operation across all sites.
Q: What’s wp-admin?
A: Admin dashboard files and functionality.
The wp-admin directory in WordPress, located in the root folder (e.g., /wp-admin), contains all the files and scripts responsible for powering the WordPress admin dashboard, accessible via example.com/wp-admin. Key details include:
Core Admin Files: Includes admin.php (main admin logic), admin-ajax.php (handles AJAX requests), and admin-post.php (processes form submissions), serving as the backbone of admin functionality.
Subdirectories:
- css (stylesheets for admin UI, e.g., dashboard.css),
- js (JavaScript for admin features, e.g., post.js),
- images (admin icons and graphics),
- includes (helper files like update-core.php for updates).
User Interface: Drives pages like Posts (edit.php), Pages (page-new.php), Settings (options-general.php), and Users (users.php), rendered via PHP templates and processed server-side.
Access Control: Protected by authentication (login via wp-login.php), requiring user credentials and permissions (e.g., current_user_can(‘edit_posts’)).
Immutable Core: Part of WordPress core, overwritten during updates—customizations belong in plugins or themes, not here.
In essence, wp-admin is the administrative heart of WordPress, managing content, settings, and site administration, distinct from the public-facing wp-content and core logic in wp-includes.
Q: What’s The Loop?
A: Displays posts using have_posts() and the_post().
The Loop is WordPress’s fundamental mechanism for retrieving and displaying posts or other content from the database within a theme’s templates. It operates as a PHP control structure that iterates over a set of posts, leveraging global post data. Key details include:
Core Functions:
- have_posts(): Returns true if there are posts to display, false if none remain, checking the main query or a custom WP_Query.
- the_post(): Advances the loop, setting up the current post’s data (e.g., ID, title) in the global $post object.
Structure: Typically written as:
if (have_posts()) {
while (have_posts()) {
the_post();
the_title(); // Outputs title
the_content(); // Outputs content
}
} else {
echo ‘No posts found.’;
}
Purpose: Used in templates like index.php, single.php, or archive.php to render dynamic content (posts, pages, CPTs) based on the current query.
Customization: Can be modified with WP_Query for specific content (e.g., new WP_Query([‘post_type’ => ‘portfolio’])), requiring wp_reset_postdata() afterward.
Context: Relies on WordPress’s query system ($wp_query)—outside The Loop, functions like the_title() won’t work without setup.
In short, The Loop is the heartbeat of WordPress’s content display, bridging the database and front-end output, essential for any theme development and a likely interview topic.
Q: What’s the difference between a post and a page?
A: Posts are chronological, pages are static.
In WordPress, posts and pages are distinct content types with different purposes, behaviors, and characteristics:
Posts:
- Purpose: Chronological content, typically for blog articles, news, or updates.
- Behavior: Displayed in a reverse-chronological feed (e.g., homepage, archives), tied to The Loop’s main query.
- Features: Support categories, tags, post dates, and author metadata; appear in RSS feeds and archives.
- Database: Stored in wp_posts with post_type as post.
- Example: “My Latest Blog Entry” on a blog page.
Pages:
- Purpose: Static, standalone content, such as “About Us” or “Contact”.
- Behavior: Not part of the blog feed; manually placed via menus or links, often hierarchical (parent/child pages).
- Features: Lack categories/tags by default, no inherent date/author display, designed for timeless info.
- Database: Stored in wp_posts with post_type as page.
- Example: “Our Team” page in navigation.
Key Difference: Posts are time-based and aggregated; pages are static and independent—interviewers might ask this to test your grasp of content structure in WordPress.
Q: What’s the database table for posts?
A: wp_posts.
The database table for posts in WordPress is wp_posts, though the prefix can vary based on the $table_prefix setting in wp-config.php (default is wp_). Key details:
Purpose: Stores all post-type content, including posts, pages, custom post types (CPTs), attachments, and revisions.
Structure: Key columns include:
- ID (unique identifier),
- post_title (title),
- post_content (main content),
- post_type (e.g., post, page, attachment),
- post_status (e.g., publish, draft),
- post_date (publication date),
- post_author (user ID).
Related Tables: Connected to wp_postmeta (custom fields), wp_terms (categories/tags via wp_term_relationships), and wp_comments (comments).
Usage: Queried by WordPress core (e.g., via WP_Query) to retrieve content for The Loop or custom queries.
In short, wp_posts is the central hub for all post-like data, critical for understanding WordPress’s content management—interviewers might probe this to test database knowledge.
Q: What’s the wp_options table for?
A: Stores site settings (e.g., site title).
The wp_options table in WordPress stores site-wide settings and configuration data, acting as a key-value store for options that control how the site behaves and appears. Key details:
Purpose: Holds persistent, global settings accessible via functions like get_option() and update_option().
Structure: Key columns include:
- option_id (unique identifier),
- option_name (key, e.g., siteurl),
- option_value (value, e.g., https://example.com),
- autoload (yes/no—loads automatically on page load if yes).
Examples:
- siteurl (site URL),
- home (homepage URL),
- blogname (site title),
- posts_per_page (posts per page),
- active_plugins (array of enabled plugins).
Usage: Managed via the Settings API or direct DB access ($wpdb), with autoloaded options cached for performance.
Scope: Applies to the entire site (or network in multisite via wp_sitemeta)—custom options can be added by themes/plugins.
In essence, wp_options is WordPress’s settings repository, vital for site configuration and a likely interview topic for understanding data persistence.
Q: What does get_header() do?
A: Includes header.php from the theme.
The get_header() function in WordPress includes the header.php file from the active theme’s directory, injecting the header section (typically the HTML <head> and top site elements) into a template. Key details:
Purpose: Loads reusable header content (e.g., <html>, <head>, navigation) at the start of a page’s output.
How It Works:
- Searches for header.php in wp-content/themes/your-theme/.
- If not found, falls back to the parent theme (in child theme setups) or skips silently.
Optional Parameter: Accepts a $name (e.g., get_header(‘custom’)) to load header-custom.php for specific contexts.
Usage: Commonly used in templates like index.php, single.php, or page.php to maintain consistent headers.
Example:
// In index.php
<?php get_header(); ?>
<main>Main content here</main>
If header.php has <head><title>My Site</title></head>, this outputs above <main>.
Context: Relies on the theme’s template hierarchy and global WordPress environment.
In short, get_header() streamlines theme development by modularizing the header—interviewers might test this to assess your grasp of WordPress templating.
Q: What’s the default theme directory?
A: wp-content/themes.
The default theme directory in WordPress is wp-content/themes, located within the WordPress root folder. Key details:
Purpose: Stores all theme folders (e.g., twentytwentythree, my-custom-theme), each containing files like style.css, index.php, and functions.php that define the site’s appearance and behavior.
Structure: Each theme folder is a self-contained unit—WordPress scans this directory to list available themes in the admin under Appearance > Themes.
Default Behavior: WordPress ships with default themes (e.g., twentytwentythree) pre-installed here, and activating a theme links it to the site’s front-end rendering.
Path: Full path example: /var/www/wordpress/wp-content/themes.
Customization: Users add or edit themes here, preserved during core updates (unlike wp-includes or wp-admin).
In essence, wp-content/themes is the heart of WordPress theming—interviewers might ask this to test your understanding of file structure and theme management.
Q: What’s the admin URL?
A: /wp-admin (e.g., example.com/wp-admin).
The admin URL in WordPress is example.com/wp-admin/, where example.com is the site’s domain, providing access to the administrative dashboard. Key details:
Purpose: Directs users to the login page (wp-login.php) and, upon authentication, the admin interface for managing content, settings, and more.
Default Path: Appended to the site’s root URL (e.g., http://localhost/mysite/wp-admin/ for local setups).
Components:
- Initial redirect to wp-login.php for login (e.g., example.com/wp-login.php).
- Post-login, lands at wp-admin/index.php (dashboard).
Customization: Can be altered via plugins (e.g., WPS Hide Login) or wp-config.php settings for security, but defaults to /wp-admin/.
Access: Requires user credentials and appropriate permissions (e.g., administrator role).
In short, /wp-admin/ is the gateway to WordPress’s back-end—interviewers might ask this to confirm your familiarity with site administration.
Q: What’s a permalink?
A: A permanent URL for a post or page.
A permalink in WordPress is a permanent, user-friendly URL assigned to an individual post, page, or custom post type, designed to remain consistent even as content is updated. Key details:
Purpose: Provides a stable, readable link for content (e.g., example.com/my-first-post/ instead of example.com/?p=123).
Structure: Configurable via Settings > Permalinks in the admin dashboard, with options like:
- Plain: example.com/?p=123 (default, not SEO-friendly).
- Post Name: example.com/my-first-post/ (common choice).
- Category: example.com/category/my-post/.
Components: Built from the post slug (e.g., my-first-post), stored in wp_posts.post_name, often derived from the title and sanitized (e.g., spaces to hyphens).
Rewrite System: Managed by WordPress’s .htaccess or server rules (e.g., Nginx) to map pretty URLs to internal queries.
Usage: Output via the_permalink() or get_permalink() in templates.
In essence, permalinks enhance SEO and usability—interviewers might ask this to test your grasp of WordPress’s URL handling and content accessibility.
Q: What’s the front-end in WordPress?
A: The public-facing site visitors see.
The front-end in WordPress refers to the public-facing portion of the website that visitors see and interact with, rendered by the active theme and driven by WordPress’s core functionality. Key details:
Purpose: Displays content like posts, pages, and custom post types to users, distinct from the admin back-end.
Components:
- Theme Files: Templates (index.php, single.php) in wp-content/themes dictate layout and style.
- The Loop: Fetches and displays content (e.g., via the_title(), the_content()).
- Assets: CSS (style.css), JS, and media from wp-content/uploads.
Rendering: Processed server-side by PHP, outputting HTML, CSS, and JS (e.g., example.com/ or example.com/about/).
Customization: Controlled by themes, plugins, and hooks (e.g., wp_head, wp_footer)—no admin login required to view.
Example: A blog post at example.com/my-post/ with a header, content, and footer.
In short, the front-end is WordPress’s visitor interface—interviewers might ask this to ensure you understand the user-facing vs. admin distinction.
Q: What’s the back-end in WordPress?
A: The admin dashboard for managing content.
The back-end in WordPress refers to the administrative interface and underlying systems that manage the site’s content, settings, and functionality, accessible only to authenticated users. Key details:
Purpose: Allows administrators, editors, and other roles to create, edit, and configure the site—distinct from the public front-end.
Components:
- Admin Dashboard: Reached via example.com/wp-admin/, powered by files in wp-admin (e.g., admin.php, edit.php).
- Database: Managed via $wpdb, storing content (wp_posts), options (wp_options), etc.
- Core Files: wp-includes provides functions (e.g., update_option()) for back-end logic.
Features: Includes Posts, Pages, Media, Users, Settings, Plugins, and Themes management, rendered server-side with PHP.
Access: Requires login (wp-login.php) and permissions (e.g., current_user_can(‘manage_options’) for admins).
Example: Adding a post at example.com/wp-admin/post-new.php.
In essence, the back-end is WordPress’s control center—interviewers might ask this to test your understanding of site administration vs. the visitor-facing front-end.
Q: What’s functions.php?
A: Theme file for custom code (hooks, functions).
The functions.php file in WordPress is a theme-specific PHP file located in the active theme’s directory (e.g., wp-content/themes/twentytwentythree/functions.php), used to define custom functions, hooks, and settings that enhance or modify the theme’s behavior. Key details:
Purpose: Acts as a plugin-like file for the theme, allowing developers to add functionality without altering core WordPress files.
Common Uses:
- Hooks: Registers actions (add_action(‘wp_footer’, ‘my_func’)) and filters (add_filter(‘the_content’, ‘my_filter’)).
- Custom Functions: Defines reusable code (e.g., function my_custom_output() {}).
- Theme Setup: Configures features like add_theme_support(‘post-thumbnails’) or register_nav_menus().
Execution: Automatically loaded by WordPress on every page load (front-end and back-end) when the theme is active.
Scope: Specific to the active theme—child themes can override parent functions.php by including their own.
Example:
function my_footer_text() {
echo ‘<p>Custom footer!</p>’;
}
add_action(‘wp_footer’, ‘my_footer_text’);
In short, functions.php is the theme’s customization hub—interviewers might ask about it to test your ability to extend WordPress functionality.
Q: What’s the WordPress Codex?
A: Official documentation (now Developer Docs).
The WordPress Codex is the original online manual and documentation repository for WordPress, historically hosted at codex.wordpress.org, providing detailed guides, function references, and tutorials for developers, themers, and users. Key details:
Purpose: Served as the go-to resource for understanding WordPress internals, APIs, and best practices (e.g., how to use WP_Query, create themes).
Content: Included:
- Function Reference: Details on functions like get_the_title() or add_action().
- Guides: Step-by-step instructions (e.g., “Creating a Plugin”).
- Examples: Code snippets for common tasks.
Evolution: Largely replaced by the WordPress Developer Documentation (developer.wordpress.org) after 2018, which modernized and expanded the content—Codex is now semi-archived but still referenced.
Access: Open-source, community-edited (wiki-style), though less maintained today.
Example: Codex page for the_title() explained its usage and parameters.
In essence, the Codex was WordPress’s foundational knowledge base—interviewers might mention it to gauge your familiarity with official resources, though they’ll likely point to developer.wordpress.org now.
Q: What’s wp-blog-header.php?
A: Loads core WordPress environment.
The wp-blog-header.php file in WordPress, located in the root directory (e.g., /wp-blog-header.php), is a core file that serves as the central loader for the WordPress environment on front-end requests, bridging the initial index.php entry point to the full system. Key details:
Purpose: Initializes WordPress by loading essential components needed to process and display a page.
Role:
- Included by index.php via require __DIR__ . ‘/wp-blog-header.php’;.
- Loads wp-load.php (sets up constants, database connection), which then includes wp-settings.php (configures hooks, plugins, themes).
Execution: Triggers the main query ($wp_query), applies rewrite rules, and sets up the template loader to render the page (e.g., via The Loop).
Significance: Acts as the glue between the HTTP request and WordPress’s dynamic output—without it, the front-end wouldn’t function.
Not Editable: Part of the core, overwritten on updates—custom code goes elsewhere (e.g., functions.php).
In short, wp-blog-header.php is the engine starter for WordPress’s front-end—interviewers might ask about it to test your understanding of the bootstrap process.
Q: What does ABSPATH define?
A: Absolute path to WordPress root.
ABSPATH in WordPress is a PHP constant that defines the absolute server file system path to the WordPress root directory, ensuring scripts reference the correct location regardless of server setup. Key details:
Purpose: Provides a reliable base path for including files (e.g., require ABSPATH . ‘wp-settings.php’;) and securing WordPress by restricting direct access.
Definition: Set in wp-load.php (included by wp-blog-header.php) using PHP’s __DIR__ or similar, typically something like /var/www/wordpress/ on a server.
Usage:
- Core files use it to load dependencies (e.g., wp-includes/functions.php).
- Often checked to prevent direct file execution:
if (!defined(‘ABSPATH’)) {
exit; // Block access if not loaded via WordPress
}
Immutable: Automatically defined during WordPress startup—not editable in wp-config.php or elsewhere by users.
Example: On a local setup, ABSPATH might be C:/xampp/htdocs/mysite/.
In essence, ABSPATH anchors WordPress’s file operations—interviewers might ask this to test your grasp of WordPress’s file system and security mechanisms.
Q: What’s the plugins folder?
A: wp-content/plugins—stores plugin files.
The plugins folder in WordPress is a directory located at wp-content/plugins within the root folder, dedicated to storing all plugin files that extend or enhance WordPress functionality. Key details:
Purpose: Houses individual plugin directories (e.g., wp-content/plugins/hello-dolly), each containing PHP files (like hello-dolly.php), assets (CSS, JS), and optional subfolders, enabling features like SEO, forms, or custom tools.
Structure: Each plugin folder typically includes a main PHP file with a header comment (e.g., Plugin Name: Hello Dolly) that WordPress reads to list it in the admin under Plugins.
Management: Plugins are activated/deactivated via the Plugins dashboard (wp-admin/plugins.php), which scans this folder—activation runs the plugin’s code via hooks or custom logic.
Customization: User-added or third-party plugins live here, preserved during core updates, unlike wp-includes or wp-admin.
Example: wp-content/plugins/akismet contains akismet.php for spam protection.
In short, the plugins folder is WordPress’s extensibility hub—interviewers might ask about it to assess your understanding of how plugins integrate with the core system.
Q: What’s the mu-plugins folder?
A: wp-content/mu-plugins—must-use plugins.
The mu-plugins folder in WordPress, short for “must-use plugins,” is an optional directory located at wp-content/mu-plugins, designed to store PHP plugin files that are automatically activated and cannot be disabled from the admin dashboard. Key details:
Purpose: Houses plugins that must run on every page load, typically for critical site-wide functionality (e.g., security, performance tweaks) enforced by developers or site admins.
Behavior:
- Files (e.g., my-mu-plugin.php) are auto-loaded by WordPress during initialization (via wp-settings.php), before regular plugins.
- No activation toggle—unlike wp-content/plugins, they’re always active unless removed from the folder.
Structure: Contains standalone PHP files (e.g., custom-functions.php)—no subdirectories are scanned unless explicitly included by a file within.
Creation: Not present by default; must be manually created under wp-content—WordPress recognizes it if it exists.
Example: A file wp-content/mu-plugins/security.php adding a custom login check.
In short, mu-plugins ensures mandatory plugin execution—interviewers might ask this to test your knowledge of plugin management and WordPress’s loading order.
Q: What does wp-load.php do?
A: Bootstraps WordPress for external scripts.
The wp-load.php file in WordPress, located in the root directory (e.g., /wp-load.php), is a core script that bootstraps the WordPress environment by loading essential configuration and core files, enabling WordPress functionality for both front-end and external scripts. Key details:
Purpose: Sets up the foundation for WordPress to run by defining constants, connecting to the database, and preparing the system for further processing.
Actions:
- Loads wp-config.php (database credentials, salts, settings).
- Defines ABSPATH (absolute path to root).
- Includes wp-settings.php (loads core functions, plugins, themes).
- Establishes the database connection via $wpdb.
Usage:
- Included by wp-blog-header.php for front-end requests (via index.php).
- Used directly in custom scripts (e.g., require ‘/path/to/wp-load.php’;) to access WordPress functions outside templates.
Security: Often guarded with if (!defined(‘ABSPATH’)) exit; to prevent direct access.
Example: A cron script might use require ABSPATH . ‘wp-load.php’; to run wp_mail().
In essence, wp-load.php is the entry point for initializing WordPress—interviewers might ask this to probe your understanding of the startup sequence and custom integrations.
Q: What’s the wp-settings.php file?
A: Initializes WordPress settings and hooks.
The wp-settings.php file in WordPress, located in the root directory (e.g., /wp-settings.php), is a core script that configures and initializes the WordPress environment after basic setup, loading essential components to make the system fully operational. Key details:
Purpose: Sets up WordPress’s runtime by defining constants, loading core files, initializing plugins, themes, and hooks, and preparing the global $wp_query object.
Actions:
- Includes wp-includes files (e.g., functions.php, class-wp.php) for core functionality.
- Loads active plugins from wp-content/plugins and must-use plugins from wp-content/mu-plugins.
- Initializes the active theme (via wp-content/themes).
- Sets up global objects like $wpdb (database), $wp (main instance), and $wp_rewrite (permalinks).
- Fires early hooks like plugins_loaded and init.
Execution: Included by wp-load.php (via wp-blog-header.php from index.php) during every page load, front-end or back-end.
Not Editable: Part of the core, overwritten on updates—custom code belongs in functions.php or plugins.
Example Impact: Without it, no plugins, themes, or queries would run—e.g., add_action(‘init’, ‘my_func’) wouldn’t work.
In short, wp-settings.php is the orchestrator of WordPress’s startup—interviewers might ask this to test your grasp of the initialization process and dependency loading.
), appends $after (e.g.,
), and $echo (true by default) controls output vs. return. Usage: while (have_posts()) { the_post(); the_title('', '
'); // Outputs:My Post
} Contrast: Unlike get_the_title(), it echoes instead of returning the string—use get_the_title() if you need to manipulate the title first. In short, the_title() is a quick way to display post titles in templates—interviewers might ask this to test your understanding of WordPress’s content output functions.' . esc_html($title) . '
'; } Contrast: Unlike the_title(), which echoes the title, get_the_title() returns it—ideal for processing (e.g., concatenation, conditionals). Example: $title = get_the_title(123); gets title of post ID 123. In essence, get_the_title() offers flexibility for title handling—interviewers might ask this to test your grasp of WordPress’s data retrieval vs. output functions.My post content
} Contrast: Unlike get_the_content(), which returns the content as a string, the_content() echoes it—use get_the_content() for manipulation. Example: Displays formatted text, images, or embedded media from the post editor. In short, the_content() is the go-to for rendering post bodies—interviewers might ask this to test your understanding of WordPress’s content display mechanics.' . esc_html($excerpt) . '
'; } Contrast: Unlike the_excerpt(), which outputs directly, get_the_excerpt() returns the string—ideal for processing before display. In short, get_the_excerpt() offers flexibility for handling post summaries—interviewers might ask this to test your understanding of WordPress’s content retrieval functions.- ';
while (have_posts()) : the_post();
echo '
- ' . get_the_title() . ' '; endwhile; echo '
- Intro to PHP
- PHP Arrays
- PHP Loops
Thanks for visiting my site!
'; } add_action('wp_footer', 'my_custom_footer_message'); // In a template (e.g., footer.php), WordPress includes: do_action('wp_footer'); // Executes all hooked functions© ' . date('Y') . ' My Site
'; } add_filter('the_content', 'add_copyright'); // In a template (e.g., single.php), WordPress includes: the_content(); // Outputs post content plus copyright Hello, world!© 2025 My Site
Updated on: ' . date('F j, Y') . '
'; return $notice . $content; } add_filter('the_content', 'add_content_notice'); // In a template (e.g., single.php): while (have_posts()) : the_post(); the_content(); // Outputs modified content endwhile;Updated on: February 27, 2025
Hello, world!Parent theme footer
'; } add_action('wp_footer', 'parent_footer_message', 15); // In a child theme’s functions.php: remove_action('wp_footer', 'parent_footer_message', 15); // In footer.php: wp_footer(); // No "Parent theme footer" outputNotice
' . $content; } add_filter('the_content', 'parent_content_notice', 15); // In a child theme’s functions.php: remove_filter('the_content', 'parent_content_notice', 15); // In single.php: the_content(); // Outputs content without the notice Hello, world!Early footer message
'; } add_action('wp_footer', 'early_footer', 5); // Low priority, runs first function late_footer() { echo 'Late footer message
'; } add_action('wp_footer', 'late_footer', 15); // High priority, runs last // In footer.php: wp_footer(); // Outputs both messages in orderEarly footer message
Late footer message
Footer message
'; } add_action('wp_footer', 'custom_footer_message'); // In a template (e.g., footer.php): if (has_action('wp_footer')) { echo 'Footer has actions!
'; wp_footer(); // Runs hooked actions } else { echo 'No footer actions.
'; }Footer has actions!
Footer message
Notice
'; } add_filter('the_content', 'add_content_notice'); // In a template (e.g., single.php): if (has_filter('the_content')) { echo 'Notice
First
'; } add_action('wp_footer', 'first_message', 5); // Early function second_message() { echo 'Second
'; } add_action('wp_footer', 'second_message', 15); // Late // In footer.php: wp_footer(); // Outputs messages in priority orderFirst
Second
This is a: ' . esc_html( $post_type ) . '
'; } } Result: Outputs the post type (e.g., "This is a: post") for each post in The Loop. $post_id = 42; $post_type = get_post_type( $post_id ); if ( $post_type ) { echo 'Post ID ' . $post_id . ' is a: ' . esc_html( $post_type ); } else { echo 'Post not found or invalid ID.'; } Result: Outputs the post type for post ID 42 (e.g., "Post ID 42 is a: page") or an error message.'; } }
Genres: '; the_terms( get_the_ID(), 'genre', '', ', ', '' ); echo '
';' . get_the_title() . '
'; } wp_reset_postdata(); }'; }
All Books Archive
'; } elseif ( is_post_type_archive() ) { echo 'Some CPT Archive
'; }Welcome to My Site
', '' ); the_content(); endwhile; else : echo 'No content found.
'; endif; ?>Welcome to My Site
', '' ); the_content(); endwhile; else : echo 'No content found.
'; endif; ?>This is a page!
This is not a page.
This is a single post!
', 'after_title' => '
', ) ); } add_action( 'widgets_init', 'my_theme_register_sidebars' ); ?>Welcome to the Blog!
Welcome to the Site!
'primary' ) ); ?>Welcome to Our Homepage!
Explore Our Site!
'primary' ) ); ?>; ?>/images/logo.png)
Custom single post layout from child theme!
404 - Page Not Found
Oops! It looks like we can’t find the page you’re looking for.
Try searching below or return to the homepage:
Hello world! Link
?> And here’s an example in a template with a custom field: array(), 'i' => array(), 'a' => array( 'href' => true ), ); echo wp_kses( $custom_field, $allowed_html ); } ?> In this example, wp_kses() filters $unsafe_input, keeping onlyInvalid email format.
'; } } } add_action( 'template_redirect', 'my_email_form_handler' ); ?> And here’s an example with a test string: example.com \n"; $clean_email = sanitize_email( $dirty_email ); echo esc_html( $clean_email ); // Outputs: user@example.com ?> In this example, sanitize_email() takes a messy input (" user@example.com \n") and outputs a clean email ("user@example.com") by removing spaces, tags, and newlines. Pair it with is_email() to confirm it’s a valid email before saving (e.g., to user meta). Use it for input sanitization, not output escaping.Security check failed!
'; } } } add_action( 'template_redirect', 'my_form_handler' ); ?> The output of wp_nonce_field() looks like this in HTML: In this example, wp_nonce_field( 'my_form_action', 'my_nonce_field' ) adds a nonce field named my_nonce_field to the form, tied to the action my_form_action. On submission, wp_verify_nonce() checks the nonce’s validity. If it fails (e.g., due to tampering or timeout), the action is blocked. This enhances security for custom forms.Data saved: ' . esc_html( $clean_data ) . '
My Admin Page
Sorry, you don’t have permission to edit posts.
'; } } // Add a shortcode to display the restricted content add_shortcode( 'restricted_content', 'my_restricted_content' ); ?> And here’s an example in a template file:Safe URL: ' . esc_html( $safe_url ) . '
'; // Outputs: Safe URL: http://example.com/ ?> And here’s an example restricting protocols: Link'; // Outputs: Link (invalid protocol removed) ?> In these examples, esc_url() cleans $raw_url or $unsafe_url, stripping "; $clean_string = wp_strip_all_tags( $dirty_string ); echo esc_html( $clean_string ); // Outputs: Hello world! ?> Hello\nWorld"; $clean_no_breaks = wp_strip_all_tags( $dirty_with_breaks, true ); echo esc_html( $clean_no_breaks ); // Outputs: HelloWorld ?> In this example, wp_strip_all_tags() removes all tags (, , And here’s an example with enqueueing and a test string: alert("hacked");'; $safe_string = esc_js( $unsafe_string ); wp_add_inline_script( 'my-script', 'var safeValue = "' . $safe_string . '"; console.log(safeValue);' ); } add_action( 'wp_enqueue_scripts', 'my_enqueue_scripts' ); ?> The output in the browser would be: // Console output: He said \"Hello\" \u003Cscript\u003Ealert(\"hacked\")\u003C\/script\u003E In this example, esc_js() ensures $dynamic_value or $unsafe_string is safely embedded in JavaScript. For instance, He said "Hello" "; $safe_text = esc_textarea( $unsafe_text ); ?> In this example, esc_textarea() takes $unsafe_text and escapes it, ensuring "; $cleaned = sanitize_meta( 'my_custom_field', $raw_input, 'post' ); echo esc_html( $cleaned ); // Outputs: Hello World! $code_input = "abc-123!@#"; $cleaned_code = sanitize_meta( 'user_code', $code_input, 'user' ); echo esc_html( $cleaned_code ); // Outputs: ABC-123 ?> In this example: - 'my_custom_field' is registered with sanitize_text_field, so sanitize_meta() strips tags and extra spaces from "Hello ", yielding "Hello World!". - 'user_code' uses a custom callback to allow only uppercase letters, numbers, and dashes, transforming "abc-123!@#" to "ABC-123". - The $object_type (e.g., 'post') ensures the correct registration context. Use sanitize_meta() to apply registered sanitization rules explicitly, though it’s often automatic with update_post_meta() for registered keys.
- ';
foreach ( $meta_keys as $key ) {
// Skip hidden keys (starting with underscore)
if ( strpos( $key, '_' ) === 0 ) {
continue;
}
echo '
- ' . esc_html( $key ) . ' '; } echo '
No custom meta keys found.
'; } ?>
In this example, meta_form() is called within the default postcustom metabox, generating a form with a nonce, key dropdown (populated by get_post_custom_keys()), and value textarea. The save function processes this data when submitted. It’s a legacy tool—use custom metaboxes with add_meta_box() for modern development—but it’s still available for manual meta entry.
- ';
foreach ( $custom_fields as $key => $values ) {
if ( strpos( $key, '_' ) === 0 ) continue; // Skip hidden keys
echo '
- ' . esc_html( $key ) . ': ' . esc_html( implode( ', ', $values ) ) . ' '; } echo '
' . esc_html( $atts['text'] ) . '
'; } add_shortcode( 'myshortcode', 'my_shortcode_func' ); // In a template (e.g., page.php) get_header(); ?>Custom Text
} ?>Nested
contentGreetings!
. - It works on custom field content, enabling shortcodes where the_content() isn’t applied. - Nested shortcodes (e.g., [wrapper]) require do_shortcode( $content ) in the callback to process inner shortcodes. Use it to render shortcodes in non-standard contexts; it’s not needed in the_content() (already filtered).