DEV Community: Anatoliy Dovgun

You're a Tenant, Not the Owner: 6 Doors in Someone Else's wp-admin, and How Not to Be a Bad Neighbor

Anatoliy Dovgun — Thu, 01 Oct 2026 09:20:55 +0000

wp-admin isn't a blank canvas — it's a shared apartment building, and every active plugin is a tenant with a key. This is the etiquette guide nobody hands you, one rule per hook, from a real 4wp.dev deep dive.

This is part of the 4wp.dev Hooks series — one WordPress hook category, explained in production depth. Full catalog: https://4wp.dev/hooks/category/admin/ on 4wp.dev.

The Premise

wp-admin isn't yours. The owner is WordPress core, and every active plugin is a tenant with its own key to a shared apartment. The six hooks in this category are literally six doors you've been handed: you can walk in and set up your own corner, but dozens of other tenants live there too, and how you behave determines how comfortable it is for everyone — including the person who walks in there every day, the site administrator.

The Problem With a Bad Tenant

Typical signs of bad neighborly behavior in wp-admin: your plugin's notice shows up on every single admin screen instead of just the relevant one; the footer text gets overwritten without checking whether someone already left something there — and two plugins keep erasing each other's line; a menu item uses a slug that's already taken by another plugin, so one of the two simply doesn't show up; wp_mail_from gets silently hijacked, and an email that was supposed to come from a support service arrives with the "no-reply@" address of a completely different plugin.

None of these situations technically break the site. They break trust: the administrator sees a mess in their own dashboard and has no idea which plugin is responsible.

Rules of a Good Neighbor — One Per Hook

admin_init — move in quietly

add_action( 'admin_init', function() {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }
    register_setting( 'forwp_settings_group', 'forwp_api_key' );
} );

Don't run heavy code or checks without a reason — this hook fires on EVERY load of every admin screen, for every user, not just administrators.

admin_menu — don't block someone else's door

add_action( 'admin_menu', function() {
    // A unique, prefixed slug — so you don't collide with another plugin.
    add_menu_page(
        'My Plugin',
        'My Plugin',
        'manage_options',
        'forwp-my-plugin', // not just 'settings' or 'dashboard'
        'forwp_render_settings_page'
    );
} );

A slug like settings or dashboard is a guaranteed conflict sooner or later. Prefix it with your plugin's own name.

wp_mail_from — sign with your own name

add_filter( 'wp_mail_from', function( $original_email ) {
    // Only change the address for emails our own plugin sends,
    // don't hijack everything that goes through wp_mail() globally.
    if ( ! forwp_is_our_mail_context() ) {
        return $original_email;
    }
    return 'notifications@example.com';
} );

Globally overriding the sender address without checking context is a common reason an email from a completely different plugin suddenly arrives from the wrong address.

admin_footer_text — check if the wall is already taken

add_filter( 'admin_footer_text', function( $text ) {
    // Don't silently overwrite — add your own text while keeping what was already there.
    return $text . ' | Powered by My Plugin';
} );

A common reason one plugin's footer text "disappears" is that another plugin simply replaces the whole string instead of appending to what's already there.

admin_notices — don't shout down the whole hallway

add_action( 'admin_notices', function() {
    $screen = get_current_screen();
    if ( ! $screen || 'toplevel_page_forwp-my-plugin' !== $screen->id ) {
        return; // Show it only on our own screen, not everywhere.
    }
    echo '<div class="notice notice-success is-dismissible"><p>Settings saved.</p></div>';
} );

A notice with no screen check and no is-dismissible class is exactly why administrators dread plugin updates: the banner stays on every page until someone manually cleans up the code.

manage_posts_columns — rearrange the furniture, don't throw out what isn't yours

add_filter( 'manage_posts_columns', function( $columns ) {
    // Add our own column without removing what others put there.
    $columns['forwp_status'] = 'Status';
    return $columns;
} );

Removing someone else's columns from the array without a clear reason is like throwing a neighbor's furniture out of the hallway just because it was in your way.

When It's Better to Bring In a Specialist

These rules become especially critical when wp-admin needs to be "branded" for a client — stripping the WordPress logo, showing only your own footer text, hiding menus that aren't relevant to a given user role. That's classic agency or freelance work, and doing it carefully — without breaking the client's other plugins in the process — is exactly where WordPress development services earn their keep: an experienced WordPress developer knows which hooks are safe to fully override, and where you should only append.

FAQ

Why does the admin footer text keep appearing and disappearing?
Most often, two or more plugins are filtering admin_footer_text, and each returns its own string instead of appending to what it received. The last registered filter "wins" and erases the others.

Why does my admin notice show up on the media library screen when it's only relevant to my plugin's settings?
Because admin_notices fires on every admin screen by default. You need an explicit check of the current screen via get_current_screen(), otherwise the banner shows up everywhere.

Is it safe to remove someone else's columns via manage_posts_columns?
Technically yes, but without a clear reason it's bad practice — the column might have been added intentionally for a client's needs or another plugin. Only remove what genuinely duplicates your own plugin's functionality.

How do I avoid a slug conflict in admin_menu?
Always prefix the slug with a unique plugin identifier (forwp-settings, not just settings). It's the simplest and most reliable way to avoid colliding with other plugins or the theme.

Does wp_mail_from change the address for every email on the site, or just mine?
By default, for every email sent through wp_mail(), including emails from other plugins and WordPress core itself. If you only want to change the address for your own emails, you must check the context inside the filter.

When is it worth hiring a WordPress developer for a client's white-label wp-admin?
When you need to hide or rebrand the dashboard for a client in a way that won't break their other plugins or get in the way of future updates. That's exactly the level of nuance (context checks, prefixing, appending carefully instead of replacing) where experience with these specific hooks saves hours of rework.

Summary

A full breakdown of each of the 6 hooks in this category — with examples and a hands-on IDE — is on the Admin Hooks page, and the whole set is also available as one PDF to keep.

Originally published on 4wp.dev.

Headless WordPress with WPGraphQL and Next.js: From First Query to Production

Anatoliy Dovgun — Wed, 30 Sep 2026 13:55:27 +0000

Most WPGraphQL tutorials end at the first query. This one goes further: a small Next.js (App Router) blog on top of headless WordPress, taken all the way to a production-ready setup.

We'll build a paginated list, a single post page, one custom field, shared fragments, then lock the endpoint down and wire cache revalidation to the Publish button.

If you want the "why" first — trade-offs of GraphQL vs REST and schema design — read the GraphQL for Headless WordPress overview on 4wp.dev.

The Setup

WordPress with WPGraphQL installed. The endpoint is https://cms.example.com/graphql.
WPGraphQL for ACF only if you expose ACF fields. Not needed for this walkthrough.
WPGraphQL Smart Cache for persisted queries and cache invalidation (step 5 and 6).
Next.js with the App Router. No GraphQL client library: server components and fetch are enough.

One helper does all requests. It sends queries as GET, which matters later for caching:

// lib/wp.ts
const WP_GRAPHQL_URL = process.env.WP_GRAPHQL_URL!;

export async function wpQuery<T>(
  query: string,
  variables: Record<string, unknown> = {},
  tags: string[] = []
): Promise<T> {
  const url = new URL(WP_GRAPHQL_URL);
  url.searchParams.set('query', query);
  url.searchParams.set('variables', JSON.stringify(variables));

  const res = await fetch(url, { next: { revalidate: 300, tags } });
  if (!res.ok) throw new Error(`WPGraphQL responded ${res.status}`);

  const json = await res.json();
  if (json.errors?.length) throw new Error(json.errors[0].message);
  return json.data as T;
}

Step 1: The First Query — a Paginated Post List

WPGraphQL uses cursor pagination: ask for first N nodes, then pass endCursor back as after for the next page.

query Posts($first: Int!, $after: String) {
  posts(first: $first, after: $after) {
    pageInfo {
      hasNextPage
      endCursor
    }
    nodes {
      slug
      title
      date
      excerpt
    }
  }
}

// app/blog/page.tsx
import Link from 'next/link';
import { wpQuery } from '@/lib/wp';
import { POSTS_QUERY } from '@/lib/queries';

export default async function BlogPage({
  searchParams,
}: {
  searchParams: Promise<{ after?: string }>;
}) {
  const { after } = await searchParams;
  const { posts } = await wpQuery<PostsData>(
    POSTS_QUERY,
    { first: 10, after: after ?? null },
    ['posts']
  );

  return (
    <main>
      {posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>{post.title}</Link>
        </article>
      ))}
      {posts.pageInfo.hasNextPage && (
        <Link href={`/blog?after=${encodeURIComponent(posts.pageInfo.endCursor)}`}>
          Older posts
        </Link>
      )}
    </main>
  );
}

Cursors are opaque strings. Don't build page numbers from them; "Older posts / Newer posts" is the natural UI for cursor pagination.

Step 2: The Single Post Page

One query returns the post, its author, categories, and featured image. In REST this would be several calls or a heavy _embed.

query PostBySlug($slug: ID!) {
  post(id: $slug, idType: SLUG) {
    title
    date
    content
    author {
      node {
        name
      }
    }
    categories {
      nodes {
        name
        slug
      }
    }
    featuredImage {
      node {
        sourceUrl
        altText
        mediaDetails {
          width
          height
        }
      }
    }
  }
}

// app/blog/[slug]/page.tsx
import { notFound } from 'next/navigation';
import { wpQuery } from '@/lib/wp';
import { POST_BY_SLUG_QUERY } from '@/lib/queries';

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const { post } = await wpQuery<PostData>(POST_BY_SLUG_QUERY, { slug }, [`post:${slug}`]);

  if (!post) notFound();

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

content is rendered HTML from WordPress. That's fine when WordPress is the only trusted author of that HTML. If you need to render blocks as your own components, look at WPGraphQL Content Blocks, which exposes Gutenberg blocks as structured data.

Step 3: A Custom Field in the Schema

add_action( 'graphql_register_types', function () {
    register_graphql_field( 'Post', 'readingTime', array(
        'type'        => 'Int',
        'description' => __( 'Estimated reading time in minutes.', 'forwp' ),
        'resolve'     => function ( $post ) {
            $text  = wp_strip_all_tags( get_post_field( 'post_content', $post->databaseId ) );
            $words = count( preg_split( '/\s+/u', trim( $text ), -1, PREG_SPLIT_NO_EMPTY ) );

            return max( 1, (int) ceil( $words / 200 ) );
        },
    ) );
} );

preg_split with the u flag instead of str_word_count: the latter doesn't count Cyrillic and other non-Latin words. Add readingTime to the query from step 2, and it's there.

Step 4: Fragments — One Shape, Many Queries

The list, the single page, and a "related posts" block all need a post card. Define that shape once:

// lib/queries.ts
export const POST_CARD = /* GraphQL */ `
  fragment PostCard on Post {
    slug
    title
    date
    excerpt
    readingTime
  }
`;

export const POSTS_QUERY = /* GraphQL */ `
  query Posts($first: Int!, $after: String) {
    posts(first: $first, after: $after) {
      pageInfo {
        hasNextPage
        endCursor
      }
      nodes {
        ...PostCard
      }
    }
  }
  ${POST_CARD}
`;

When the card design changes, you edit one fragment, not five queries. Keep fragments next to the components that render them, and each component asks for exactly what it displays.

Step 5: Production Limits

The default WPGraphQL setup is developer-friendly, not production-safe. Before launch:

Public introspection off. GraphQL → Settings → Enable Public Introspection stays unchecked. Logged-in developers still get the schema in GraphiQL.
Query depth limit on. Same settings page, Enable Query Depth Limiting, with a max depth your real queries fit into (10–15 is typical).
Cap page size. Nobody should fetch 1,000 posts in one request:

add_filter( 'graphql_connection_max_query_amount', fn () => 50 );

Persisted queries. With WPGraphQL Smart Cache, your frontend queries are saved as GraphQL documents on the server, and the allow-list rule makes the server execute only those. The frontend sends a query ID instead of the full query string, so the URL stays short, and arbitrary queries are rejected.

Step 6: Caching and Revalidation

Because requests go out as GET, they're cacheable by URL: at the CDN, by Smart Cache's network cache, and by Next.js itself. The revalidate: 300 in the helper is a safety net. The real trigger is publishing.

In Next.js, a route handler invalidates by tag:

// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache';

export async function POST(req: Request) {
  if (req.headers.get('x-revalidate-secret') !== process.env.REVALIDATE_SECRET) {
    return new Response('Unauthorized', { status: 401 });
  }

  const { slug } = await req.json();
  revalidateTag('posts');
  if (slug) revalidateTag(`post:${slug}`);

  return Response.json({ revalidated: true });
}

In WordPress, call it when a post is published, updated, or unpublished:

add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) {
    if ( 'post' !== $post->post_type || ( 'publish' !== $new_status && 'publish' !== $old_status ) ) {
        return;
    }

    wp_remote_post( FORWP_FRONTEND_URL . '/api/revalidate', array(
        'headers'  => array(
            'Content-Type'        => 'application/json',
            'x-revalidate-secret' => FORWP_REVALIDATE_SECRET,
        ),
        'body'     => wp_json_encode( array( 'slug' => $post->post_name ) ),
        'blocking' => false,
    ) );
}, 10, 3 );

publish → publish fires on updates too, so edits to a live post invalidate the cache as well.

Common Mistakes in Practice

N+1 in custom resolvers. A field that runs its own query per node multiplies database calls by list size. For related objects, return a deferred load through WPGraphQL's loaders so IDs are batched across the whole list:

register_graphql_field( 'Post', 'featuredCase', array(
    'type'    => 'Post',
    'resolve' => function ( $post, $args, $context ) {
        $case_id = (int) get_post_meta( $post->databaseId, 'forwp_featured_case', true );

        return $case_id ? $context->get_loader( 'post' )->load_deferred( $case_id ) : null;
    },
) );

No pagination on connections. "GraphQL handles it" until one query returns every post with content. Always pass first, and cap it server-side.

Business logic inside resolvers. Resolvers should be thin and call the same service layer your REST endpoints use. Otherwise two data paths drift apart.

POST for everything. It works in development and makes caching hard in production. Use GET plus persisted queries for public reads.

Pre-Launch Checklist

[ ] Public introspection is off.
[ ] Query depth limit is on and tested against real frontend queries.
[ ] graphql_connection_max_query_amount is capped.
[ ] Frontend queries are persisted, the allow-list is on.
[ ] Public reads go as GET and hit a cache.
[ ] Publish/update/unpublish triggers revalidation.
[ ] Custom resolvers batch related lookups through loaders.
[ ] A missing slug returns a real 404, not an empty page.

FAQ

Do I need Apollo Client or urql with Next.js?

Not for server components. Plain fetch with Next.js caching covers reads. A client library earns its place when you have heavy client-side state, optimistic updates, or subscriptions.

Should I send GraphQL requests as GET or POST?

GET for public reads, so responses are cacheable by URL. POST for mutations and authenticated requests.

How do I expose ACF fields?

Install WPGraphQL for ACF and enable Show in GraphQL on the field group. The fields appear on the post type in the schema.

How do drafts and previews work with this setup?

Previews need authenticated requests and bypass the cache. That flow is covered in the preview and authentication parts of the headless series.

Can I render Gutenberg blocks as React components?

Yes, with WPGraphQL Content Blocks: it returns blocks as typed data instead of one HTML string, and you map each block type to a component.

Enqueue Hooks: Four Hooks, Four Different Zones — and How Not to Mix Them Up

Anatoliy Dovgun — Thu, 24 Sep 2026 05:35:47 +0000

On the surface, these five hooks all do the same thing — load CSS/JS. But four of them sound almost identical while each one runs in a different zone of the site. Mix them up, and block styles leak onto the front end where nobody asked for them, or the Gutenberg editor is left with no styling at all.

Which zone each hook covers

Hook	Front end	Admin	Block editor
`wp_enqueue_scripts`	✅	—	—
`admin_enqueue_scripts`	—	✅	—
`enqueue_block_editor_assets`	—	—	✅
`enqueue_block_assets`	✅	—	✅

Front end — the standard hook for anything a site visitor sees:

add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_style( 'theme-main', get_stylesheet_uri() );
    wp_enqueue_script( 'theme-main', get_template_directory_uri() . '/assets/main.js', array(), '1.0', true );
} );

Admin — a separate hook that only runs inside wp-admin:

add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {
    wp_enqueue_style( 'my-plugin-admin', plugins_url( 'admin.css', __FILE__ ) );
} );

Block editor only — styles and JS for the editing screen that never reach the front end:

add_action( 'enqueue_block_editor_assets', function() {
    wp_enqueue_script( 'my-block-editor', plugins_url( 'editor.js', __FILE__ ) );
} );

Editor and front end at once — a single hook that fires in both places. This is exactly where CSS belongs when a block needs to look the same in the editor and on the live site:

add_action( 'enqueue_block_assets', function() {
    wp_enqueue_style( 'my-block-style', plugins_url( 'block.css', __FILE__ ) );
} );

A common mistake is reaching for enqueue_block_assets when you actually need enqueue_block_editor_assets (or vice versa): the style either shows up somewhere it shouldn't, or fails to show up where it should.

`admin_enqueue_scripts` and performance: check `$hook_suffix`

The hook passes $hook_suffix — an identifier for the current admin screen — for exactly this reason: so you don't load files everywhere.

// Bad: this CSS/JS loads on EVERY wp-admin screen —
// every post, every settings page, the media library.
add_action( 'admin_enqueue_scripts', function() {
    wp_enqueue_style( 'my-plugin-admin', plugins_url( 'admin.css', __FILE__ ) );
} );

// Good: only on the plugin's own screen.
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {
    if ( 'toplevel_page_my-plugin' !== $hook_suffix ) {
        return;
    }
    wp_enqueue_style( 'my-plugin-admin', plugins_url( 'admin.css', __FILE__ ) );
} );

This is one of the most common reasons wp-admin feels slow: every plugin loads its files on every screen "just in case," when they're only needed on one.

`script_loader_tag`: a targeted fix, not a blanket filter

When you need to add async/defer to a specific script, the worst approach is filtering every tag without checking $handle — that can break the load order of scripts you don't own (jQuery dependencies, for example). The right way is to target by handle:

add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
    if ( 'my-plugin-widget' !== $handle ) {
        return $tag;
    }
    return str_replace( ' src', ' defer src', $tag );
}, 10, 3 );

The filter only applies to scripts registered through wp_enqueue_script() — one more reason not to print <script> tags by hand (more on that in the Head & Meta article).

Summary

Before you write add_action, answer one question first: where exactly does this file need to load — front end, admin, editor, or editor and front end at once. Picking the right hook here solves 80% of problems with missing or leaking styles. A full breakdown of every hook with examples and a hands-on IDE is on the Enqueue Hooks category page, and the whole set is also available as one PDF.

A Hook That Fires Twice — and How Not to Trigger an Infinite Loop When Saving a Post

Anatoliy Dovgun — Tue, 22 Sep 2026 20:29:23 +0000

The Problem

A typical case: a developer hooks logic onto save_post — update a counter, sync an external service, recalculate something based on the post's fields. The code runs... and immediately runs again. And again. save_post fires multiple times for a single save — on autosave, on revision creation, and finally on the actual post. If the "quick" fix is to call wp_update_post() inside that handler to patch something, it triggers save_post a second time, which calls wp_update_post() again, which fires save_post again. The result is recursion that either hangs the save, duplicates the action, or crashes WordPress outright with "Allowed memory size exhausted" — or just an endless spinner in the admin.

Why This Is Dangerous

This isn't some edge case — it's one of the most common reasons a "simple" post save suddenly hangs the admin. The problem is compounded by the fact that the same hook often carries logic from several plugins at once: an SEO plugin, a caching plugin, your own custom code — and recursion in just one of them can bring down the save for all of them. On large sites with thousands of posts it's also a direct load on the database: every extra wp_update_post() call means another UPDATE and another full run of the entire save hook chain.

Step-by-Step Solution

Step 1 — Guard checks: filter out autosaves and revisions immediately

Without this, every save_post handler runs at least twice as often as it needs to:

add_action( 'save_post', function( $post_id, $post, $update ) {
    // Skip autosaves, revisions, and other post types right away.
    if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
        return;
    }
    if ( 'post' !== $post->post_type ) {
        return;
    }
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    // Your code here.
}, 10, 3 );

Step 2 — If you need to update the post itself inside save_post: break the recursion manually

Calling wp_update_post() inside save_post is the classic cause of an infinite loop. The fix is to remove the handler for the duration of the call and add it back right after:

// Bad — infinite recursion: save_post calls wp_update_post(),
// which fires save_post again, and so on in a loop.
add_action( 'save_post', function( $post_id ) {
    wp_update_post( array(
        'ID'         => $post_id,
        'post_title' => forwp_generate_title( $post_id ),
    ) );
} );

// Good — remove the handler before updating, add it back immediately after.
add_action( 'save_post', 'forwp_normalize_title', 10, 3 );

function forwp_normalize_title( $post_id, $post, $update ) {
    if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
        return;
    }

    remove_action( 'save_post', 'forwp_normalize_title', 10 );

    wp_update_post( array(
        'ID'         => $post_id,
        'post_title' => forwp_generate_title( $post_id ),
    ) );

    add_action( 'save_post', 'forwp_normalize_title', 10, 3 );
}

Step 3 — The right hook for the right task

The four hooks in this category look interchangeable, but each is meant for a specific moment:

Hook	When it fires	Best for
`transition_post_status`	Before the save, exactly when the status changes	Reacting to a specific transition (draft → publish, publish → trash)
`wp_insert_post`	Right after the database write, before the cache is cleared	Quick actions immediately after insertion — logging, notifications
`save_post`	After `wp_insert_post`, more stable, the default choice for most plugins	General metadata-handling logic on save
`before_delete_post`	Right before deletion, while the post still exists	Cleaning up related data — the last chance before the record is gone for good

// React specifically to publishing, not to every draft save.
add_action( 'transition_post_status', function( $new_status, $old_status, $post ) {
    if ( 'publish' === $new_status && 'publish' !== $old_status ) {
        forwp_notify_subscribers( $post->ID );
    }
}, 10, 3 );

// Clean up related data before deletion — while the post still exists in the database.
add_action( 'before_delete_post', function( $post_id, $post ) {
    forwp_cleanup_related_records( $post_id );
}, 10, 2 );

A common mistake is reaching for save_post where transition_post_status is actually what's needed: then the "on publish" logic runs on every draft save instead of only on the real status transition.

When It's Better to Bring In a Specialist

These three steps cover most typical situations. But there are cases where debugging recursion yourself costs more than bringing in a specialist: production with active traffic, where a looping save_post blocks editing for the entire editorial team; a site with a dozen plugins already hooked onto the same action, where new code conflicts in ways that are hard to trace; or bulk post imports, where every extra save_post cycle multiplies across thousands of records into hours of unnecessary database load. In these cases, a WordPress developer with real hands-on experience in save/CRUD hooks usually finds the recursion point in minutes, not hours — this is the case where WordPress development services end up cheaper than self-guided debugging in production.

FAQ

Why does save_post fire multiple times for one save?
WordPress creates a revision and may run an autosave before the final post write — each of these also triggers save_post. Without wp_is_post_autosave()/wp_is_post_revision() checks, your code runs on every one of them, not just on the real save.

How do I know it's actual infinite recursion and not just slow code?
The classic sign is a fatal error — "Allowed memory size exhausted" or "Maximum execution time exceeded" — appearing specifically on post save, and it shows up only when a CRUD hook like save_post calls a function that itself triggers that same hook (wp_update_post(), wp_insert_post()).

Can several of these hooks be used together?
Yes, and that's normal — they cover different moments. A typical setup: transition_post_status reacts to publishing, save_post updates metadata, before_delete_post cleans up related records. Conflicts don't come from combining them, but from missing guard checks in each one.

What's the difference between wp_insert_post and save_post if both fire "on save"?
wp_insert_post fires earlier, right after the database write, before the post cache is cleared. save_post fires slightly later and is considered the more stable default choice for most plugins — which is why it's the most commonly used of the four.

Does before_delete_post also fire when a post is moved to trash?
No. It only fires on permanent deletion, not on trash. Reacting to a move to trash needs a separate hook (wp_trash_post) — this one is specifically the last moment before the record is physically removed from the database.

When should I hire a WordPress developer instead of figuring it out myself?
When recursion or a hook conflict shows up in production with real users, during bulk imports, or when several plugins are already filtering the same CRUD hooks. The cost of an hour of editorial downtime usually outweighs the cost of a specialist who can pinpoint and break the loop precisely.

Summary

A full breakdown of each of the 4 hooks in this category — with examples and a hands-on IDE — is on the Save & CRUD Hooks page, and the whole set is also available as one PDF to keep.

The Window of Opportunity: When Each WordPress Bootstrap Hook Is Open, and When It’s Already Closed

Anatoliy Dovgun — Tue, 15 Sep 2026 07:40:00 +0000

The Problem

register_post_type() called in plugins_loaded — and the site crashes with a fatal error, because taxonomies aren't ready yet. Or add_theme_support( 'post-thumbnails' ) called in init — no error, thumbnails just quietly never show up, because WordPress has already passed the point where a theme declares feature support. Or a plugin's text domain gets loaded after translatable strings have already been output, and the translation simply doesn't take.

// Too early: register_post_type() in plugins_loaded — taxonomies and other
// plugins' dependencies aren't ready yet, fatal error or unpredictable behavior.
add_action( 'plugins_loaded', function() {
    register_post_type( 'portfolio', array( 'public' => true ) );
} );

// Too late: WordPress has already passed the point where a theme
// declares feature support — the call is simply ignored, no error at all.
add_action( 'init', function() {
    add_theme_support( 'post-thumbnails' );
} );

Both examples are correct code in the wrong hook.

Why This Is Dangerous

This isn't always a reproducible bug. Whether it fires or not often depends on plugin load order, theme version, or whether object caching is active. The classic situation: "works on my local," but on the client's production it silently doesn't — with nothing in the error log. It's hard to debug precisely because the symptom points nowhere near the cause: a missing featured image thumbnail looks like a theme problem, when the real issue is a hook called one step too late.

Step-by-Step Solution — 5 Windows, in Order

Each of these five hooks opens a narrow window for a specific class of actions. Miss your window, and the action either fails outright (closed too early) or silently does nothing (closed for good).

Step 1 — muplugins_loaded: the earliest window, before any regular plugin

// The earliest point in the entire WordPress lifecycle — before plugins, before the theme.
// Used for network-wide/security settings that can't be disabled from wp-admin
// (mu-plugins don't even have a "Deactivate" button).
add_action( 'muplugins_loaded', function() {
    if ( ! defined( 'FORWP_SECURITY_BASELINE' ) ) {
        define( 'FORWP_SECURITY_BASELINE', true );
    }
} );

Step 2 — plugins_loaded: plugins are loaded, the theme isn't yet

// The right place for a text domain and for checking dependencies between
// plugins — the plugins themselves are already loaded, so class_exists() is safe here.
add_action( 'plugins_loaded', function() {
    load_plugin_textdomain( 'my-plugin', false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );

    if ( ! class_exists( 'WooCommerce' ) ) {
        return; // Dependency missing — disable the feature instead of throwing a fatal error.
    }
} );

Step 3 — after_setup_theme: the one correct place to declare theme feature support

add_action( 'after_setup_theme', function() {
    add_theme_support( 'post-thumbnails' );
    add_theme_support( 'title-tag' );
    register_nav_menus( array(
        'primary' => __( 'Primary Menu', 'my-theme' ),
    ) );
} );

Step 4 — init: the environment is ready, safe to register content

add_action( 'init', function() {
    register_post_type( 'portfolio', array(
        'public' => true,
        'label'  => 'Portfolio',
    ) );
} );

Step 5 — wp_loaded: everything is loaded, the request hasn't been parsed yet

// The last safe moment before request-specific logic begins — plugins and the
// theme are fully loaded, but WordPress hasn't parsed the actual request yet.
add_action( 'wp_loaded', function() {
    if ( isset( $_GET['forwp_debug'] ) && current_user_can( 'manage_options' ) ) {
        forwp_dump_registered_post_types();
    }
} );

Hook	Window open for	Too early (before this hook)	Too late (after this hook)
`muplugins_loaded`	Network-wide/security settings that can't be disabled from the admin	No earlier hook exists — this is the start	Plugins have already begun loading — too late for "non-toggleable" code
`plugins_loaded`	Text domain loading, checking dependencies between plugins	No plugins exist yet — `class_exists()` is always false	The theme has already begun loading, some checks lose their point
`after_setup_theme`	`add_theme_support()`, `register_nav_menus()`	The theme isn't hooked up yet	WordPress has already passed the point of registering theme features — silently ignored
`init`	`register_post_type()`, `register_taxonomy()`, shortcodes	Taxonomies/dependencies aren't ready — fatal error	Still possible later, but some systems (permalinks) may have already gone around it
`wp_loaded`	Logic that needs a fully ready environment, before the request is parsed	Plugins or the theme haven't finished loading everything	The request is already being parsed — too late for environment setup

When It's Better to Bring In a Specialist

Five hooks look like a simple table when you have one plugin and one theme. On a real project with dozens of plugins, each hanging code off its own bootstrap hook, a load-order bug becomes nearly impossible to reproduce on your own: it works in one environment and breaks in another, with no error message anywhere. Auditing load order is exactly the case where a WordPress developer with hands-on experience in the bootstrap sequence finds the cause in minutes, because they've seen this exact picture dozens of times before. This is one of the clearest cases where WordPress development services pay for themselves — the trial-and-error cost of hunting this kind of bug alone is usually far higher than the cost of a specialist's consultation.

FAQ

Why does register_post_type() sometimes throw a fatal error, and other times just "not work"?
It depends on how early the hook fires. In plugins_loaded, taxonomies and other plugins' dependencies aren't ready yet — a fatal error is possible. In init, everything is in place — it's just too late for some related systems (permalinks, for example, may have already gone around it).

Can I call add_theme_support() in init instead of after_setup_theme?
Technically the call won't throw an error, but part of WordPress has already checked for theme feature support before init and didn't see it — the feature simply doesn't activate. after_setup_theme is the one reliable place for this.

Why does muplugins_loaded even exist if there's already plugins_loaded?
muplugins_loaded fires earlier and, more importantly, applies to code placed in mu-plugins — code that can't be disabled from the admin. That's a fundamentally different level of trust and control, which is why it gets its own, earliest hook.

Is there a hook between plugins_loaded and after_setup_theme?
Yes, setup_theme — but it isn't documented in the catalog yet (a known gap). For most tasks this doesn't matter, since after_setup_theme covers nearly every typical theme-setup scenario.

Why does the same code work locally but break in production?
Most often — a different plugin load order between environments, different theme versions, or object caching masking the problem on one server while it surfaces on another. The symptom is the same either way: code running in the wrong window.

When is it worth hiring a WordPress developer to audit load order?
When the project scales up — a new plugin or theme update suddenly "breaks" functionality that used to work, with nothing obvious in the logs. That's a typical sign of a load-order conflict, and an experienced developer checks the bootstrap chain first, before looking anywhere else.

Summary

A full breakdown of each of the 5 hooks in this category — with examples and a hands-on IDE — is on the Bootstrap Hooks page, and the whole set is also available as one PDF to keep.

AI Workflow Automation in WordPress: Where the 4WP Plugins Are Headed

Anatoliy Dovgun — Sun, 13 Sep 2026 21:25:04 +0000

I've probably worn out my welcome by now with this old-school habit of mine — explaining DDD or SDD, or pushing for TDD (which, in practice, almost nobody actually uses, except people with... particular tastes, or the ones who just wanted to try something backwards 😏), and plenty more besides.

I'm a believer in architectural approaches — OOP, SOLID, the Essential Principles, DRY — but never all of them, all at once. And nothing beats WordPress Hooks for me: Actions and Filters work small miracles.

But today's list has a new entry: AI — and it can help enormously, on one condition: that we actually explain things to it, and point it at what's specific to the WordPress ecosystem.

That's the whole thesis of this post: WordPress specifics, explained once and well — not to a person this time, but to a model.

"AI workflow automation" gets used for two very different things in WordPress right now: a chatbot bolted onto wp-admin, and a site an agent can actually operate — reading its content, calling its plugins, taking permissioned actions, the way a logged-in editor would. This post is about the second kind, and specifically about where it's headed across the 4WP plugin ecosystem.

A note before anything else: not everything below is shipped. Some of it is architecture that already exists — the Abilities API, MCP. Some of it is work we started this week. The rest is direction, written down as a roadmap, not a feature announcement. We'd rather show the plan honestly than dress up intentions as done deals.

What "AI workflow automation" means for a plugin, not a chatbot

A chatbot answers questions about a site. Workflow automation does things on it — drafts a FAQ entry from a support transcript, flags a notification rule that no longer matches real traffic, restructures internal links across a content set — with a human approving the consequential steps. The difference is permissions and scope: a well-built automation only touches what it's explicitly allowed to, and only through the same contracts a human editor would use.

That's why this isn't built as "add an AI tab to each plugin." It's built on two primitives already documented for the 4WP ecosystem:

Abilities API — a plugin declares, with a permission callback, what an AI workflow is allowed to read or do.
MCP (Model Context Protocol) — how an agent outside wp-admin (Claude Desktop, Cursor, a CI bot) reaches those same abilities.

An ability written once works identically whether it's triggered in-editor or by an external agent. See AI & WordPress for the Connectors/AI Client layer, and MCP for WordPress for the external-agent side.

Where this is headed, plugin by plugin

None of these are shipped features today — they're the concrete shape AI workflow automation takes once an ability exists for each plugin's domain:

4WP SEO Helper — first in line. The planned AI-assist layer reuses the existing SEO inventory and Dynamics history: an agent (in-editor or via MCP) proposes a meta/title change, the same permission check that gates a human edit gates the agent's.
4WP FAQ — an agent drafts a FAQ entry from a support ticket or transcript; a human reviews before it's published to the FAQ registry, not auto-published.
4WP Notifications — a workflow watches for a pattern (a spike, a repeated failure) and raises a notification rule instead of a human noticing it three days later.
4WP Drive — extends the existing Google Docs → post pipeline: an agent normalizes front-matter and flags what's ready for editorial review, on top of the import that already works.
4WP Smart Link — AI-assisted internal linking suggestions across a Query Loop or content set, surfaced for approval rather than applied blind.
4WP MCP Abilities — the connective tissue underneath all of the above: this is where abilities get registered and exposed to MCP clients in the first place.
4WP AI Assistant (built for LMS4WP) — the pattern already proven once, in one product. The next step is generalizing it into the shared 4wp-bundle layer so any 4WP plugin can register abilities the same way.

The no-code path: n8n and external automation

Not every team wants custom code for this. The same abilities a plugin exposes over MCP can, in principle, sit behind an n8n workflow instead of a bespoke agent — a scheduled or webhook-triggered n8n run that calls a WordPress ability is a legitimate AI workflow automation for WordPress, just without a developer writing the calling code.

This isn't hypothetical: we published a first n8n template — an AI Agent node (LLM + memory + tools) wired to the 4WP FAQ and 4WP Notifications REST endpoints instead of a closed, vendor-specific action list. Same agent shape you'll see in proprietary "AI agent for WordPress" plugins, but open, importable, and pointed at your own site's contracts rather than a black box.

What's actually happening this week

To be direct about status: AI Connector work starts now, inside the plugins, not just as a content topic. Resources for scaling it across every plugin at once are limited, so the realistic path is incremental — landing first where the abilities are already partly modeled (SEO Helper), then expanding plugin by plugin as capacity allows. If a specific plugin above matters more to your workflow than the order suggests, that's useful signal — say so.

Why build it on Abilities + MCP instead of one AI feature per plugin

The same rule that governs every 4WP plugin applies here: model the domain, then wire the integration. An AI provider is a detail behind a contract (Connectors), a capability is a permission-checked operation (Abilities), and an external agent — or an n8n workflow, or a CI bot — is just another consumer of that contract (MCP). That's what agentic workflows for WordPress look like in practice once you stop treating "AI" as a bolt-on feature and start treating it as another caller of the same permission-checked contracts a human uses.

Quick FAQ

Does this replace the developer building the plugin? No — an ability still has to be modeled and permission-checked by a developer; the agent only calls what's already been deliberately exposed.

Do I need n8n to use AI workflow automation with WordPress? No. The native path is Abilities + MCP, no-code or not. n8n is one possible caller on top of that same layer, useful for teams that don't want to write the calling code themselves.

AI & WordPress — Connectors, Abilities API, AI Client in depth.
MCP for WordPress — the external-agent side of this.
AI Workflows hub.

4WP-Booking: How One Dental Clinic’s Request Became a Domain-Driven WordPress Booking Platform

Anatoliy Dovgun — Wed, 09 Sep 2026 13:41:13 +0000

Let's use a real case — a dental clinic and its appointment booking — to walk through what client-centricity, domain thinking, and scalability actually look like in WordPress development.

Let's dive into WordPress development — domain first, integration second.

Most WordPress booking plugins start the same way: a client needs to connect their site to a specific tool, so a developer wires up that one API and ships it. It works — until the second client shows up with a different calendar system, and the "quick integration" has to be rebuilt from scratch.

4WP-Booking started from exactly that kind of request — a dental practice that needed native, on-site appointment scheduling connected to Clinic Cards, the CRM it already ran on. But instead of shipping a "Clinic Cards plugin," we treated the request as a design problem first and an integration second. This article walks through why, using Domain-Driven Design and a lightweight Software Design Document process — the same methodologies we apply across every plugin built on 4wp-bundle.

The request behind the plugin

The trigger for 4WP-Booking was a real, live clinic: Dr. Hrechkovskyi's dental practice in Lutsk. Patients needed to pick a service, a doctor, or a date, see real availability, and book directly from the clinic's WordPress site — without a phone call, and without the clinic's staff re-entering anything into Clinic Cards by hand.

That's a completely reasonable, narrow request. The trap is answering it narrowly. If "booking" is modeled as "talk to the Clinic Cards API," every future requirement — a second CRM, a different industry, a client who uses Google Calendar instead of a clinic system — turns into a rewrite. If "booking" is modeled as its own domain, with Clinic Cards as one way of fulfilling it, the plugin can grow without breaking.

That distinction is the whole argument for Domain-Driven Design, and it's why we reached for it here instead of just shipping an API wrapper.

Modeling booking as a domain, not an API call

DDD starts from a simple premise: the business model should drive the architecture, not the other way around. Before writing anything, we asked what "booking" actually means, independent of Clinic Cards:

An appointment is an entity — it has an identity, a status, and a lifecycle (requested, confirmed, completed, cancelled) that persists regardless of which calendar system stores it.
A time slot and a service are value objects — defined entirely by their attributes, not by identity.
The provider — Clinic Cards today, something else tomorrow — is a detail the domain depends on, not the thing the domain is built around.

Framed this way, Clinic Cards stops being the foundation of the plugin and becomes an implementation of a contract. WordPress itself plays the same supporting role: it renders the calendar, exposes the shortcode and Gutenberg block, and stores configuration — but the booking logic doesn't know it's running inside WordPress, and it doesn't know it's talking to Clinic Cards. That separation is what "domain logic stays independent and portable" means in practice, and it's the reason the same approach scales to every plugin in the 4WP ecosystem, not just this one.

Sketching the SDD before writing a line of integration code

Where DDD answers how the domain is modeled, a Software Design Document answers how the system gets built — architecture, data flow, and build order, captured before implementation rather than discovered during it. For 4WP-Booking, that meant working through five questions up front:

Requirements — What's the MVP? Book by service, by doctor, or by date; capture patient name, phone, email; nothing more.
Architecture — How do the pieces talk to each other? A WordPress-facing surface (block, shortcode, optional Elementor widget), a booking domain layer, and a provider layer behind an interface.
Data model — Where do appointments, providers, and credentials live, and what depends on what?
Data flow — How does a click on "9:00 AM, Dr. Kozak" become a confirmed slot in Clinic Cards and a confirmation on screen?
Implementation order — Build the provider contract first, the Clinic Cards implementation second, the WordPress surfaces last — so the parts most likely to change (the UI) depend on the parts least likely to change (the domain), and not the reverse.

Roughly, the shape that came out of that process looks like this:

WordPress surface → Shortcode · Gutenberg block · Elementor widget

(interchangeable, no domain knowledge)

Booking domain → Appointment · Service · Availability

(framework-agnostic, provider-agnostic)

Provider contract → a single interface every calendar

integration must satisfy

Providers → Clinic Cards (live)

Google Calendar (planned)

Calendly (planned)

Nothing above this diagram's provider layer needs to change when a new provider is added. That's the point of designing the document before the integration: it turns "add Calendly support" from an architectural risk into a scheduling decision.

Why the provider stayed pluggable

Clinic Cards is a strong first provider for a reason — it's purpose-built for clinics, which was exactly what the originating request needed. But the WordPress booking market is much bigger than clinics, and two names dominate general-purpose scheduling: Google Calendar, which almost every business already uses, and Calendly, which has become the default "just send me a link" tool for services and consultations.

Because the provider sits behind a contract rather than being hard-coded into the domain, both are roadmap items rather than rewrites. The domain doesn't need to know whether "check availability" means calling Clinic Cards' schedule endpoint or reading free/busy blocks from a Google Calendar — it only needs an answer that fits the same shape. That's the practical payoff of doing the domain modeling and the design document first: the second and third integrations get cheaper instead of more expensive.

API keys, and why the server holds them

One WordPress-specific decision is worth calling out on its own: where credentials live. 4WP-Booking keeps every provider API key — the Clinic Cards token today, a Google or Calendly credential tomorrow — on the server side, inside WordPress. The browser never sees it. Every call to the provider's API is made from WordPress itself, not from the visitor's session, which matters as soon as more than one provider (and more than one client's credentials) is in play. It's a small architectural rule, but it's the kind of rule that's easy to skip when a plugin is built as a one-off integration and much harder to skip when it's designed as a domain with a provider contract from the start.

Why this is a "WordPress Methodologies" story, not just a plugin note

DDD explains how to model the domain. SDD explains how to plan the build. Neither replaces the other, and neither is specific to booking — they're the same methodologies we use across the 4WP plugin family, from 4WP Smart Link to 4WP FAQ to 4WP Weather, all built on the shared 4wp-bundle foundation. The pattern holds regardless of the vertical: identify the domain independent of the first integration, document the structure before building it, and keep the provider — CRM, calendar, weather API, whatever it is — behind a contract instead of woven through the plugin.

That discipline is also why a client request that starts this specific — "connect my WordPress site to Clinic Cards" — is worth treating as a platform decision rather than a one-off script. It costs more up front than an API wrapper would. It costs a lot less the second time a client asks for something adjacent.

When it's worth bringing in an architect

Not every booking integration needs this much ceremony. A single site, a single provider, no plans to reuse the plugin elsewhere — that's a legitimate case for a lighter-weight, direct integration, and DDD's own guidance is to skip the heavier patterns for exactly that kind of simple, low-complexity build.

But the moment a project needs to support more than one provider, more than one client with different requirements, or a booking flow with real business rules attached (cancellation policies, deposits, multi-staff scheduling), it's worth having a developer who thinks in domains and design documents, not just endpoints — someone who can own the provider contract and the data model as the integration list grows, rather than patching a new if branch in for every new calendar service. That's the difference between a plugin that supports Calendly next quarter and one that has to be rebuilt to support it.

Where 4WP-Booking stands today

4WP-Booking is live and open source on GitHub, and its Clinic Cards integration is running in production on Dr. Hrechkovskyi's clinic site today. It's currently working through the WordPress.org plugin review process, with submission planned once the current plugin ahead of it in the queue clears verification. Google Calendar and Calendly support are next on the roadmap — and thanks to the provider contract the domain was built around, adding them is a matter of implementing the interface, not redesigning the plugin.

Sources

SOLID in the WordPress Ecosystem: What 4wp.dev's Plugins Actually Prove

Anatoliy Dovgun — Sun, 06 Sep 2026 10:03:17 +0000

WordPress makes it easy to write code that works and easy to write code that lasts, and those are not the same skill. Hooks, filters, custom post types, widgets — the platform hands you enough rope to build something maintainable or something that collapses the moment a second developer touches it. SOLID is the discipline that decides which one you get. Not as academic dogma imported from enterprise Java, but as five habits that map cleanly onto things WordPress developers already do every day.

We’ve written up all five principles in depth on 4wp.dev/architectures/solid. This isn’t a repeat of that material — it’s the harder question: does our own plugin catalog actually hold up against it? Where does it, and where are we still watching ourselves?

Single Responsibility — the one we had to learn from our own mistake
SRP says a class, a module, a plugin should have one reason to change. The honest WordPress version of this failure mode is the “kitchen sink” plugin — the one that does SEO, and a slider, and contact forms, and social icons, because it was easier to bolt features onto something that already existed than to ship something new.

We named this risk directly on our own SRP page, using 4wp-bundle as the cautionary example: if it ever grew to carry responsive controls, FAQ management, Gutenberg extensions, and settings all in one codebase, that’s exactly the violation. The actual answer wasn’t a paragraph of theory — it’s the catalog itself. 4WP-Booking, 4WP-FAQ, 4WP Smart Link, 4WP Weather, 4WP Drive, 4WP Notifications — each is a separate plugin with a separate reason to change, sharing only infrastructure through 4wp-bundle, not features. That split isn’t a marketing decision. It’s SRP applied at the product level, not just the class level, and it’s the reason a bug in the booking flow can never be a reason to redeploy the FAQ registry.

Open/Closed — the principle WordPress ships for free
OCP — open for extension, closed for modification — is arguably the one principle WordPress gets right by default. do_action() and apply_filters() are OCP in procedural form: WooCommerce alone ships 700+ action hooks and 400+ filter hooks, and its whole extension ecosystem exists without a single third party editing WooCommerce’s own source.

Our own clearest example is 4WP-Booking. The plugin was built around a provider contract from day one — Clinic Cards today, Google Calendar and Calendly on the roadmap — specifically so that adding a new booking provider is an extension, not a rewrite. Nothing in the booking domain has to change for a new provider to plug in behind the same contract. That’s the same shape as a hook, just at the architecture layer instead of the callback layer.

Liskov Substitution — the one that’s easiest to fake and hardest to actually keep
LSP requires that anything substitutable for a base type actually behaves like it — same contract, no surprise exceptions, no broken assumptions. WordPress breaks this constantly: a WP_Widget subclass that throws where the parent returns cached output, a custom post type wrapper that crashes on get_permalink(). The interface looks satisfied. The behavior isn’t.

4WP Smart Link is our sharpest internal test of this, even though it’s a runtime pattern rather than a class hierarchy — worth being precise about, since LSP is usually framed as inheritance. The plugin decides between anchor mode (wrap the block in tag:< a > ) and host mode (attach the click via data-forwp-smart-link-url) depending on whether inner interactive elements need to keep priority. Whichever mode fires, the outward contract — “this block is now clickable, and its inner links still work” — holds identically. Nothing downstream needs to know which mode ran. That’s the substitutability guarantee LSP is actually protecting, applied to a strategy choice instead of a class swap.

Interface Segregation — don’t make every plugin implement methods it’ll never use
ISP says no client should depend on methods it doesn’t use. Our own page frames this well for Gutenberg: a simple Quote block only needs to render, a Cover block needs render, transform, and style variations — forcing both through one bloated block contract is the violation, and forcing a lightweight SEO plugin to implement Has_Cron because some other plugin needs scheduled tasks is the same mistake at the plugin level.

4WP-FAQ is the clean version of this: the registry (the FAQ entry itself, as a CPT) doesn’t know or care how it’s displayed, and the two display blocks — 4WP FAQ List and 4WP FAQ Card — each consume only what they need from the registry, not a shared monolithic “FAQ manager” interface that both would have to partially ignore.

Dependency Inversion — the one that makes the roadmap possible
DIP says high-level modules should depend on abstractions, not concrete implementations — a Mailer_Interface instead of a hard-coded wp_mail() call, so you can swap providers without touching business logic.

This is, again, 4WP-Booking‘s core architectural bet. The booking domain doesn’t depend on Clinic Cards — it depends on a provider contract that Clinic Cards happens to implement first. That’s the entire reason Google Calendar and Calendly can be added later as roadmap items instead of rewrites. DIP isn’t an abstraction for its own sake here; it’s the specific mechanism that turns “add a new integration” from a risk into a scheduling decision.

Where this actually lands
SOLID overlaps with itself constantly — Booking’s provider contract is simultaneously an OCP and a DIP story, and that’s not sloppy analysis, it’s what these principles look like when they’re actually load-bearing instead of decorative. The honest version of this article isn’t “we nailed all five” — it’s that four of the five show up as deliberate architecture in shipped plugins, and the fifth (SRP) shows up as a mistake we named on our own site before we fixed it in the catalog. That’s the difference between citing SOLID and being accountable to it.

Full breakdowns of each principle, with more WordPress-specific examples and common violations: 4wp.dev/architectures/solid.

Sources

SOLID overview — 4wp.dev
Single Responsibility Principle — 4wp.dev
Open/Closed Principle — 4wp.dev
Liskov Substitution Principle — 4wp.dev
Interface Segregation Principle — 4wp.dev
Dependency Inversion Principle — 4wp.dev
4WP-Booking · 4WP Smart Link · 4WP-FAQ · 4wp-bundle

The Whale Metaphor: How OOP's Four Pillars Actually Work in WordPress

Anatoliy Dovgun — Sat, 29 Aug 2026 20:51:45 +0000

In the age of AI engineering and vibe coding, almost nobody mentions OOP anymore. But what if children were never taught prefixes, roots, and suffixes — the architecture of words — or how a sentence is properly built? Will AI agents really be enough for the specialists of tomorrow, if those specialists never learned the grammar underneath?

Dive into OOP in WordPress development practice → (original source, featuring the four whales example)

Most WordPress developers learn Object-Oriented Programming the hard way: by staring at WP_Widget, WP_Query, or WP_Post and reverse-engineering why core is built the way it is. Textbooks explain encapsulation, abstraction, inheritance, and polymorphism with abstract diagrams that rarely survive contact with real code.

Here's a different way to think about it — using a whale.

A whale keeps its vital organs protected inside its body, dives into depths where the mechanics of survival are invisible from the surface, passes traits down to its calf, and adapts its behavior differently depending on the environment it's in. Swap "whale" for "class," and you've basically described the four pillars of OOP. Let's walk through each one with WordPress-specific code, then look at how the same principles scale from a five-page brochure site to an enterprise platform.

Why OOP Matters in WordPress at All

WordPress was procedural for most of its early life, and plenty of plugins still are. But once your project outgrows a handful of files, procedural code starts fighting you: global state leaks everywhere, the same logic gets copy-pasted into three different hooks, and a single typo in a variable name three files away breaks something unrelated.

OOP fixes this by grouping data and behavior together into objects instead of scattering functions and passing arrays between them. WordPress core made this bet a long time ago — WP_Widget, WP_Query, and WP_Post are all classes — and the four principles below are the foundation that makes classes trustworthy enough to build on. They're also the on-ramp to SOLID, the next level of discipline for larger codebases.

Encapsulation: The Protected Whale

A whale's vital organs sit safely inside its body, reachable only through a small number of controlled openings. Encapsulation applies the same idea to a class: internal data is hidden from the outside world, and only a deliberate, controlled interface is exposed.

class UserProfile {
    private $data;

    public function __construct($data) {
        $this->data = $data;
    }

    public function get_display_name() {
        return $this->data['display_name'];
    }

    private function get_password_hash() {
        return $this->data['password'];
    }
}

Notice what's public and what isn't. get_display_name() is a safe, read-only window into the object. get_password_hash() stays private — nothing outside the class can reach it, even by accident. That's the entire point: encapsulation isn't about hiding things for secrecy, it's about making it impossible to misuse an object's internals from the outside.

In a WordPress plugin, this is the difference between a settings class that validates and sanitizes every value it stores, versus a plugin that lets any file in the codebase poke directly into a raw options array. One of those breaks when someone forgets to call sanitize_text_field(). The other can't.

Abstraction: The Deep Whale

A whale dives into depths where its physiology does things — pressure regulation, oxygen management — that are irrelevant to anyone watching from a boat. All you need to know is: it dives, it surfaces, it breathes. Abstraction works the same way in code: it hides complexity behind a simple, stable interface.

abstract class Payment_Gateway {
    abstract public function process($amount);
}

class Stripe extends Payment_Gateway {
    public function process($amount) {
        return $this->stripe_api->charge($amount);
    }
}

Anything calling process($amount) doesn't need to know that Stripe's implementation involves API authentication, currency conversion, and webhook handling. The abstract class defines the contract — "every payment gateway must be able to process an amount" — and each concrete class fills in the messy details.

This matters enormously in WordPress e-commerce or membership plugins, where you might support Stripe today and PayPal or a local payment processor tomorrow. If the rest of your plugin talks to Payment_Gateway instead of talking to Stripe directly, swapping or adding a gateway means writing one new class — not hunting through the codebase for every place that assumed Stripe.

Inheritance: Mother and Calf

A calf inherits traits from its mother without needing to relearn how to swim from scratch. Inheritance lets a child class receive properties and methods from a parent, then extend or specialize them.

class Base_Widget extends WP_Widget {
    protected function cache($output) {
        set_transient($this->id, $output);
    }
}

class Popular_Posts extends Base_Widget {
    public function widget($args, $instance) {
        $posts = get_posts(['orderby' => 'comment_count']);
        $this->cache($this->render($posts));
    }
}

Base_Widget extends WordPress's own WP_Widget and adds one useful shared behavior: caching. Popular_Posts then extends Base_Widget and gets caching for free, without reimplementing it. If you build five widgets this way, you write the caching logic exactly once.

This is also where a lot of WordPress developers get their first real taste of OOP, because WP_Widget practically forces the pattern on you. But the same idea applies to custom post type controllers, REST API endpoint classes, or any group of components that share a common backbone but differ in specifics.

A word of caution: inheritance is powerful but easy to overuse. Deep inheritance chains (a class extending a class extending a class extending a class) get brittle fast — a change to a distant parent can silently break every descendant. Use it when the "is-a" relationship is genuinely true (a Popular_Posts widget is a widget), and reach for composition when it isn't.

Polymorphism: The Many Forms

Whales adapt their behavior to different environments while remaining recognizably whales. Polymorphism is the OOP version: different objects share the same interface, but each implements it in its own way.

interface Notifiable {
    public function send($msg);
}

class Email_Notifier implements Notifiable {
    public function send($msg) {
        wp_mail($this->email, 'Alert', $msg);
    }
}

function notify(Notifiable $n, $m) {
    $n->send($m);
}

The notify() function doesn't know or care whether it's talking to an Email_Notifier, a Slack_Notifier, or an SMS_Notifier — as long as each one implements send(), they're interchangeable. This is what makes plugin architectures extensible: you can add a brand-new notification channel by writing a new class that implements Notifiable, and every place in your codebase that already calls notify() picks it up automatically, with zero changes to existing code.

The Same Principles, Different Scale

What makes these four pillars genuinely useful — rather than just academic — is that they scale up and down with the size of the project.

On a small brochure site or blog, you don't need an elaborate class hierarchy. A single, well-encapsulated class is often enough:

class Theme_Options {
    private $options = [];

    public function get($key) {
        return $this->options[$key] ?? null;
    }

    public function save($key, $value) {
        $this->options[$key] = sanitize_text_field($value);
        update_option('my_theme_options', $this->options);
    }
}

This one class handles a contact form's settings or a set of theme options. Encapsulation keeps the stored data safe from careless direct writes, and if you later need a specialized version — say, a widget with extra behavior — inheriting from WP_Widget gets you there without rebuilding anything from scratch.

At the enterprise end, the same four principles are doing exactly the same job, just at higher stakes: encapsulated data models that can't be corrupted by a stray script, abstracted payment or search providers that can be swapped without a rewrite, inherited base classes that keep dozens of custom post types consistent, and polymorphic interfaces that let a plugin ecosystem grow without every new feature requiring changes to old code.

Where This Leads: From Four Pillars to SOLID

Encapsulation, abstraction, inheritance, and polymorphism aren't four unrelated rules to memorize — they're the raw material that a more advanced set of rules is built from: SOLID.

The connection is direct, not theoretical. A well-encapsulated UserProfile class, one that exposes only what callers actually need, is already halfway to Single Responsibility — a class that guards its own data tends to guard its own job, too. The Payment_Gateway abstraction is a working example of Dependency Inversion: the rest of the plugin depends on the abstract contract, not on Stripe specifically, which is also what makes it Open for extension, closed for modification. Base_Widget extending WP_Widget only holds up as long as every subclass can stand in for its parent without surprising callers — that's Liskov Substitution, and it's exactly where careless inheritance chains start to break. And the Notifiable interface is a small, focused contract rather than a bloated one — the seed of Interface Segregation.

In other words, once encapsulation, abstraction, inheritance, and polymorphism feel natural, you're not learning SOLID from zero — you're learning the names for things you're already halfway doing. That's the next stop: SOLID Principles in WordPress →, five rules that take these four pillars and turn them into architecture that survives years of feature requests without a rewrite.

But it starts here — with a whale, its calf, and four ideas that WordPress core has been quietly demonstrating in WP_Widget, WP_Query, and WP_Post all along.

Open/Closed Principle in WordPress Architecture

Anatoliy Dovgun — Sun, 01 Mar 2026 15:26:58 +0000

WordPress plugins rarely collapse because of complexity.

They collapse because of change.

New payment gateway.

New notification channel.

New integration.

New business rule.

And suddenly — you are modifying the same class again.

That’s exactly what the Open/Closed Principle (OCP) is designed to prevent.

What Open/Closed Principle Really Means

Software entities should be open for extension, but closed for modification.

It does not mean your code never changes.

It means:

Core behavior remains stable.

New functionality is added by extension — not by editing existing logic.

If every new feature requires touching old code, your architecture is fragile.

A Typical WordPress Anti-Pattern

php
class PaymentProcessor {
    public function process(string $method, float $amount): void {
        if ($method === 'paypal') {
            // PayPal logic
        }

        if ($method === 'stripe') {
            // Stripe logic
        }

        if ($method === 'bank') {
            // Bank transfer logic
        }
    }
}

Works fine.

Until business says:

Add Apple Pay
Add crypto
Add installment payments

Each time → modify the same class.

That’s not closed for modification.

That’s conditional chaos.

A Better Architectural Direction

Introduce abstraction.

interface PaymentMethod { public function process(float $amount): void; }
Concrete implementations:

class PayPalPayment implements PaymentMethod {}
class StripePayment implements PaymentMethod {}
class BankTransferPayment implements PaymentMethod {}

Processor:

class PaymentProcessor {
    public function __construct(private PaymentMethod $method) {}

    public function process(float $amount): void {
        $this->method->process($amount);
    }
}

Now:

Adding Apple Pay = new class.
No modification of existing logic.

That’s Open/Closed in practice.

Why WordPress Developers Struggle with OCP

WordPress encourages:

Feature flags inside giant classes
Conditionals inside hooks
Direct API calls
Procedural branching logic

But scalable systems require extension-based thinking.

If your architecture grows by adding if statements — it won’t scale.

Where to Apply OCP in WordPress

Use it for:

Payment gateways
Notification systems (email, SMS, Slack)
Export formats (CSV, PDF, JSON)
Caching strategies
Storage drivers

Any place where variation is expected.

Why It Matters

Open/Closed Principle enables:

Safer refactoring
Replaceable infrastructure
Testable components
Plugin-style extensibility
Long-term maintainability

If your plugin is constantly rewritten, OCP is missing.

Final Thought

Most WordPress plugins are built to work.

Few are built to evolve.

Open/Closed Principle is what makes the difference.

Full breakdown:
https://4wp.dev/architectures/solid/open-closed-principle/

Single Responsibility Principle for OOP WordPress Developers

Anatoliy Dovgun — Sat, 28 Feb 2026 17:55:21 +0000

If you want to grow as an OOP WordPress developer, understanding the Single Responsibility Principle (SRP) is not optional — it’s foundational.

SRP is the first principle from the well-known SOLID design principles. It states:

A class should have only one reason to change.

That sounds simple. In practice — especially in WordPress — it’s often ignored.

The Real Problem in WordPress Projects

Many WordPress developers still build:
Massive utility classes
God-like service objects
Theme functions.php monsters
Plugins that do “everything”

This leads to:

Tight coupling
Hard-to-test code
Fear of refactoring
Fragile architecture

For an OOP WordPress developer, this becomes a career bottleneck.

What Single Responsibility Really Means

SRP does NOT mean:

One method per class
Ultra-micro classes
Artificial splitting

SRP means:

A class should have one clear responsibility in the business domain.

For example:

Bad:

class OrderManager { public function createOrder() {} public function sendEmail() {} public function generateInvoicePDF() {} public function logActivity() {} }

Good:

class OrderCreator {} class OrderMailer {} class InvoiceGenerator {} class ActivityLogger {}

Each class now has one reason to change.

Applying SRP in WordPress Architecture

For a professional OOP WordPress developer, SRP applies to:

1. Plugin Structure

Separate:

Controllers
Services
Repositories
Integrations

Instead of:

MyPlugin.php (3000 lines)

Use:

src/ ├── Application/ ├── Domain/ ├── Infrastructure/

2. Hooks & WordPress Actions

Avoid this:

add_action('init', function () { register_post_type(...); sendEmails(); syncWithAPI(); });
Instead, delegate:

add_action('init', [PostTypeRegistrar::class, 'register']);

3. Theme Development

In modern block themes and FSE:

Templates define structure
Patterns define reusable UI
PHP handles domain logic

Mixing all of this breaks SRP.

Why This Matters for an OOP WordPress Developer

If you want to:

Work on enterprise WordPress projects
Pass technical interviews
Build scalable products
Refactor safely
Collaborate in teams

SRP is your baseline.

Without it, you are just writing procedural code wrapped in classes.

Common SRP Mistakes in WordPress

Fat service classes
Overloaded helpers
Static utility dumping grounds
Mixed domain + infrastructure logic
Business logic inside template files

If this sounds familiar — your architecture needs refactoring.

Read the Full Architecture Breakdown

This article is a short overview.

*For a deeper architectural breakdown, examples, and structured explanation, read the original post:
*
👉 https://4wp.dev/architectures/solid/single-responsibility/

Final Thought

Being an OOP WordPress developer is not about using classes.
It’s about understanding responsibility boundaries.
Master SRP — and the rest of SOLID becomes easier.

4WP.dev — Modular WordPress Architecture, Gutenberg Custom Blocks, SEO & Automation

Anatoliy Dovgun — Sat, 14 Feb 2026 23:05:31 +0000

“When you have one plugin — it’s great. When you have several — even better. When they are actively used — perfect. But then the real pain begins…”
— Full-stack WordPress developer with open two eyes

I have 12+ plugins and over 30+ projects where use it and know how management it from one place:

Site: https://4wp.dev/plugin/
GitHub: https://github.com/4wpdev/4wpdev

A simple example: one WordPress project uses multiple plugins. Then more projects reuse them. Over time the ecosystem grows — modules increase, dependencies expand, logic overlaps, responsibilities blur, performance fluctuates, updates introduce risks, and maintenance becomes unpredictable.

4WP.dev is a modular WordPress development framework designed to solve this problem and scale complex Gutenberg-based projects efficiently.

DEV Community: Anatoliy Dovgun

You're a Tenant, Not the Owner: 6 Doors in Someone Else's wp-admin, and How Not to Be a Bad Neighbor

The Premise

The Problem With a Bad Tenant

Rules of a Good Neighbor — One Per Hook

When It's Better to Bring In a Specialist

FAQ

Summary

Headless WordPress with WPGraphQL and Next.js: From First Query to Production

The Setup

Step 1: The First Query — a Paginated Post List

Step 2: The Single Post Page

Step 3: A Custom Field in the Schema

Step 4: Fragments — One Shape, Many Queries

Step 5: Production Limits

Step 6: Caching and Revalidation

Common Mistakes in Practice

Pre-Launch Checklist

FAQ

Do I need Apollo Client or urql with Next.js?

Should I send GraphQL requests as GET or POST?

How do I expose ACF fields?

How do drafts and previews work with this setup?

Can I render Gutenberg blocks as React components?

Further Reading

Enqueue Hooks: Four Hooks, Four Different Zones — and How Not to Mix Them Up

Which zone each hook covers

admin_enqueue_scripts and performance: check $hook_suffix

script_loader_tag: a targeted fix, not a blanket filter

Summary

A Hook That Fires Twice — and How Not to Trigger an Infinite Loop When Saving a Post

The Problem

Why This Is Dangerous

Step-by-Step Solution

When It's Better to Bring In a Specialist

FAQ

Summary

The Window of Opportunity: When Each WordPress Bootstrap Hook Is Open, and When It’s Already Closed

The Problem

Why This Is Dangerous

Step-by-Step Solution — 5 Windows, in Order

When It's Better to Bring In a Specialist

FAQ

Summary

AI Workflow Automation in WordPress: Where the 4WP Plugins Are Headed

What "AI workflow automation" means for a plugin, not a chatbot

Where this is headed, plugin by plugin

The no-code path: n8n and external automation

What's actually happening this week

Why build it on Abilities + MCP instead of one AI feature per plugin

Quick FAQ

Related

4WP-Booking: How One Dental Clinic’s Request Became a Domain-Driven WordPress Booking Platform

The request behind the plugin

Modeling booking as a domain, not an API call

Sketching the SDD before writing a line of integration code

Why the provider stayed pluggable

API keys, and why the server holds them

Why this is a "WordPress Methodologies" story, not just a plugin note

When it's worth bringing in an architect

Where 4WP-Booking stands today

SOLID in the WordPress Ecosystem: What 4wp.dev's Plugins Actually Prove

The Whale Metaphor: How OOP's Four Pillars Actually Work in WordPress

Open/Closed Principle in WordPress Architecture

What Open/Closed Principle Really Means

A Typical WordPress Anti-Pattern

A Better Architectural Direction

Why WordPress Developers Struggle with OCP

Where to Apply OCP in WordPress

Why It Matters

Final Thought

Single Responsibility Principle for OOP WordPress Developers

That sounds simple. In practice — especially in WordPress — it’s often ignored.

What Single Responsibility Really Means

Applying SRP in WordPress Architecture

Why This Matters for an OOP WordPress Developer

Common SRP Mistakes in WordPress

Read the Full Architecture Breakdown

4WP.dev — Modular WordPress Architecture, Gutenberg Custom Blocks, SEO & Automation

`admin_enqueue_scripts` and performance: check `$hook_suffix`

`script_loader_tag`: a targeted fix, not a blanket filter