Best Practices

This final page is a capstone checklist — a condensed reference pulling together the most important habits from every previous lesson in this track. Bookmark this page: it's meant to be revisited any time you start a new theme, plugin, or WordPress project.

1. Never Edit Core or a Parent Theme Directly

WordPress core files get overwritten on every update, and so does anything inside a parent theme when it updates. Any direct edit made there is silently destroyed the next time an update runs. Instead, customize appearance through a child theme, and customize behavior through a plugin — see Directory Structure and Theme Development Basics for how themes are organized.

// A child theme's style.css header — this is all it takes
// to inherit a parent theme safely:
/*
 Theme Name: My Child Theme
 Template: parent-theme-folder-name
*/

• Never modify files inside wp-admin/, wp-includes/, or a purchased/downloaded parent theme
• Use a child theme for template and style overrides
• Use a small custom plugin for behavior that isn't tied to appearance

2. Prefer Hooks Over Modifying Behavior Directly

If you ever find yourself wanting to edit a plugin's file to change what it does, stop and look for a hook it exposes first — nearly every well-built plugin fires actions and filters exactly so other code can adjust its behavior without touching its source. See Hooks: Actions & Filters for the full mechanics of add_action() and add_filter().

<?php
// Instead of editing the plugin's file, hook into a filter it provides:
add_filter('woocommerce_product_title', function($title) {
    return strtoupper($title);
});

• Check the plugin's documentation or source for available hooks before editing anything
• Hook-based changes survive plugin updates; direct edits don't

3. Always Sanitize Input and Escape Output

Never trust $_POST or $_GET directly. Clean data with functions like sanitize_text_field() before saving it, and escape it with esc_html(), esc_attr(), or esc_url() right before printing it — the full pattern is in Security Best Practices.

<?php
$name = sanitize_text_field($_POST['name'] ?? ''); // in
echo esc_html($name); // out

• Sanitize on the way in, before saving
• Escape on the way out, right before echoing into HTML
• Always verify a nonce for any state-changing form submission

4. Use $wpdb->prepare() for Custom SQL

Never string-concatenate user input into a query. Any custom SQL run through $wpdb must pass through prepare(), as covered in The WordPress Database.

<?php
$wpdb->get_results(
    $wpdb->prepare("SELECT * FROM {$wpdb->posts} WHERE post_status = %s", 'publish')
);

• Use %s, %d, and %f placeholders instead of concatenation
• Prefer built-in functions like WP_Query or get_posts() when they already cover the need

5. Enqueue Scripts and Styles Properly

Never hardcode a <script> or <link> tag directly into a template. Use wp_enqueue_script() and wp_enqueue_style() so WordPress can manage dependencies and versioning, as covered in Enqueuing Scripts & Styles.

<?php
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('theme-style', get_stylesheet_uri());
});

• Always hook onto wp_enqueue_scripts rather than printing tags manually
• Reuse already-registered handles like jquery instead of loading your own copy

6. Use Custom Post Types and Taxonomies for Structured Content

Don't stuff every kind of content into regular posts and pages. If something has its own shape — books, products, team members — give it its own custom post type and taxonomy, as covered in Custom Post Types & Taxonomies.

<?php
register_post_type('book', [
    'label' => 'Books',
    'public' => true,
    'supports' => ['title', 'editor', 'thumbnail'],
]);

• Structured content types keep the database and admin organized as a site grows
• Taxonomies (categories/tags for your custom type) let content be filtered and related properly

7. Set show_in_rest => true Upfront

When registering a custom post type, set show_in_rest => true even if there's no immediate plan to use the REST API — it's what makes the type available to the block editor and to /wp-json/wp/v2/, as covered in The REST API. Retrofitting this later, after a headless frontend or mobile app already exists, is far more work than just flipping the flag on from the start.

<?php
register_post_type('book', [
    'public' => true,
    'show_in_rest' => true, // easy now, painful to add later
]);

• Enable REST/block-editor access upfront on every custom post type
• Costs nothing today, saves a migration headache tomorrow

8. Keep Everything Updated, Install Only Trusted Plugins

Plugin security is the single most common source of real-world WordPress vulnerabilities. Keep core, the active theme, and every plugin updated, remove anything unused, and only install plugins from the official WordPress.org repository or other clearly reputable sources.

• Enable automatic updates for core where possible
• Review a plugin's last-updated date and support activity before installing it
• Deactivate and delete plugins that are no longer in use — an inactive plugin is still an attack surface