DEV Community: Anatoliy Dovgun

SDLC Explained for WordPress Developers: The 4wp.dev Umbrella, 7 Phases, 60 Years

Anatoliy Dovgun — Fri, 06 Nov 2026 21:58:50 +0000

From the 4wp.dev team. We build WordPress plugins and write about WordPress engineering. This is how we see SDLC, and the interactive version of this article lives on 4wp.dev: 👉 scroll through sixty years of weather on 4wp.dev/sdlc

SDLC was born in the 1960s. It is still relevant in the AI era.

SDLC (Software Development Life Cycle) is the process every WordPress project goes through, whether you call it that or not: someone wants something, you clarify it, design it, build it, test it, deploy it and maintain it. Many WordPress developers know this process by heart and have never used the letters. Developers say "task", "flow", "release". Managers, tech leads and hiring teams say SDLC.

At 4wp.dev we draw SDLC as an umbrella: the phases are its ribs, and every era of software is new weather. We call it the SDLC Umbrella, and the rest of this article walks under it. This article explains the software development life cycle in a WordPress developer's language.

What Is SDLC?

SDLC stands for Software Development Life Cycle: the phases software goes through from an idea to the day it is switched off. Sources split it into five to eight phases and name them differently. The order stays the same.

The 7 Phases of SDLC (the 7 Ribs of the 4wp.dev Umbrella)

Plan: why we build it, what it is worth, what the risks are.
Requirements: what exactly it must do.
Design: how it will be built.
Build: the code.
Test: proof that it works.
Deploy: getting it live.
Maintain: keeping it alive, then feeding the next Plan.

SDLC vs Methodologies: Waterfall, Agile, Scrum, Kanban

SDLC is not a methodology. Waterfall, Agile, Scrum and Kanban are different ways of walking through the same phases. SDLC is what they all walk through.

Think of the phases as the ribs of an umbrella. Remove one and the canopy fails:

Skip Requirements and you build the wrong thing well.
Skip Design and every new feature fights the old ones.
Skip Test and your users test for you.
Skip Maintain and the site slowly rots under plugin, core and PHP updates.

A Short History of SDLC: Sixty Years of Weather

1968: the software crisis. At the NATO Software Engineering Conference in Garmisch, Germany, participants discussed what became known as the "software crisis": projects late, over budget and unreliable. The answer was engineering discipline, and with it a defined cycle.
1970: Waterfall. Winston W. Royce published "Managing the Development of Large Software Systems". Its sequential diagram later got the name Waterfall, although Royce himself warned that running it strictly one way was risky.
2001: Agile. The Agile Manifesto did not remove the phases. It made the cycle short and repeated it. A sprint is a small SDLC.
2009: DevOps. The term spread after the first DevOpsDays in Ghent. Deploy and Maintain became continuous: see CI/CD for WordPress.
2020s: AI. Coding tools made Build cheap. The other six phases did not get cheaper.

The weather changes. The cycle stays. That line closes our 40-second video on 4wp.dev/sdlc, where the umbrella stands through rain, lightning and falling stones.

SDLC From Three Sides: Client, Project, Developer

Phase	Client asks	Project asks	Developer asks
Plan	Why are we doing this, and what is it worth?	Scope, budget, deadline, risks.	Is it feasible on WordPress? Existing plugin, custom plugin or theme code?
Requirements	What must the site do for my users?	Turn wishes into a list that can be accepted or rejected.	Roles and capabilities, content types, edge cases, integrations.
Design	How will it look and feel?	Is the solution the right size for the budget?	Data model, hooks, blocks or templates, REST routes, where each piece of code lives.
Build	When can I see it?	Progress against the plan.	Plugin and theme code, migrations, configuration.
Test	Does it work on my phone?	Is it ready to ship?	Unit and end-to-end tests, coding standards, capabilities, nonces, escaping.
Deploy	Is it live?	Release window and rollback plan.	Staging to production, WP-CLI, database, cache.
Maintain	Will it keep working?	Support cost and update schedule.	Core, plugin and PHP updates, security fixes, monitoring.

On a small WordPress project one person often wears all three hats. A freelancer is the project manager and the developer, and often helps the client decide what they want. That is where SDLC stops being a manager's word.

SDLC in WordPress Development: Phase by Phase

Every rib already has a guide on 4wp.dev:

Plan: Lean (MVP), Design Thinking.
Requirements: BDD, Ubiquitous Language.
Design: Architectures, SOLID, Domain-Driven Design, API-first, Block-first.
Build: Hooks, Gutenberg Blocks, REST API, WordPress Coding Standards.
Test: TDD, Security.
Deploy: CI/CD for WordPress, WP-CLI, Twelve-Factor App.
Maintain: Site Reliability Engineering, WP-CLI profiling.

From WordPress Developer to Tech Lead

Build is one rib out of seven. A developer who only builds competes with every tool that builds.

A developer who holds all seven asks why before writing code, pins down what "done" means, decides where the code lives, proves it works, ships it safely and keeps it alive. That developer is already doing a tech lead's job, whatever the title says.

The AI era asks for exactly this: not a developer who types fast, but a fullstack developer who thinks like an architect.

SDLC and AI: AI Took One Rib

AI coding tools write code fast. They do not decide what to build, they do not own the trade-offs, and they do not own the rollback.

Vague requirements give you vague code, only faster.
More generated code means more code to review and test.
Architecture decides whether generated code fits the system or fights it.

AI took Build. Six ribs are still yours. More on how we split the work with agents at 4wp.dev: AI Workflows for WordPress and The Price of Attention.

SDLC FAQ

What does SDLC stand for?
Software Development Life Cycle: the phases software goes through from an idea to retirement.

What are the phases of SDLC?
Plan, Requirements, Design, Build, Test, Deploy and Maintain. Some sources merge or split them, but the order stays the same.

Is SDLC the same as Waterfall?
No. Waterfall is one way to walk through the cycle: one phase after another, once. Agile, Scrum and Kanban walk through the same phases in short, repeated loops.

Is SDLC still relevant with Agile and AI?
Yes. Agile made the cycle shorter, DevOps made Deploy and Maintain continuous, and AI made Build cheaper. None of them removed a phase.

Does a solo WordPress developer need SDLC?
Yes, more than anyone. A solo developer is the planner, the architect, the tester and the support team. Knowing the phases helps you see which one you skipped.

On 4wp.dev this FAQ is wrapped in our own plugin, 4WP FAQ: it adds FAQPage JSON-LD to the core Accordion.

Forecast for 2027: Sunny ☀️

Since we are talking about weather: want it on your site today? 4WP Weather is our Gutenberg block with full settings. Elementor widget? Coming in 2027. Promise.

More From 4wp.dev

Methodologies: every way to walk under the umbrella.
Architectures and SOLID: the Design rib.
WP-CLI and REST API: the Build and Deploy ribs.
4WP Plugins: what we build with this cycle.

The SDLC Umbrella is a 4wp.dev model. Originally published on 4wp.dev/sdlc, where you can scroll through sixty years of weather and open every phase as the client, the project and the developer see it.

Anatoliy Dovgun, 4wp.dev. About WordPress, with love, from developers who love it.

The Hook That Fires Twice: Why save_post Isn't as Simple as It Looks (4wp.dev Hooks Series)

Anatoliy Dovgun — Wed, 04 Nov 2026 13:29:29 +0000

A save_post handler that works perfectly in testing and loops infinitely in production — because of one missing remove_action() call. The full contract of all 4 save/CRUD hooks, from the 4wp.dev Hooks series.

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

The Problem

A developer hooks save_post to sync a post to an external service on every save. The code works in testing — one save, one sync call. In production, the same save triggers the sync twice, sometimes three times, and occasionally the site hangs entirely on save. Nothing in the code changed between testing and production; what changed is that save_post fires more often than most people assume, and one very common pattern inside its handler — calling wp_update_post() from within it — creates a save loop that keeps calling itself.

Why This Is Dangerous

save_post fires on every post write that goes through wp_insert_post(), including autosaves, revisions, and any inline quick-edit — not just the deliberate "Publish" click a developer pictures when writing the handler. A handler that isn't guarded for autosaves does its expensive work (external API calls, cache rebuilds) far more often than intended, silently multiplying load. Worse, calling wp_update_post() inside a save_post handler without removing the action first re-triggers save_post again from inside itself — on a real project this has caused an infinite loop that only stopped when PHP's execution time limit killed the request, taking the save with it.

Step-by-Step Solution — The Contract of Each Hook

save_post (action) — guard against autosaves, revisions, and yourself

add_action( 'save_post', function( $post_id, $post, $update ) {
    // Autosaves and revisions also fire save_post — skip both.
    if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
        return;
    }
    if ( 'post' !== $post->post_type ) {
        return;
    }

    // Remove our own action before calling wp_update_post(),
    // or this handler re-triggers itself and loops.
    remove_action( 'save_post', __FUNCTION__ );
    wp_update_post( array( 'ID' => $post_id, 'post_title' => forwp_normalize_title( $post->post_title ) ) );
    add_action( 'save_post', __FUNCTION__, 10, 3 );
}, 10, 3 );

The remove_action/add_action pair around any internal wp_update_post() call is the single most important line in this whole category — skip it, and any update from inside the handler re-fires the same handler.

wp_insert_post (action) — the broader event underneath save_post

add_action( 'wp_insert_post', function( $post_id, $post, $update ) {
    if ( $update ) {
        forwp_log_post_updated( $post_id );
    } else {
        forwp_log_post_created( $post_id );
    }
}, 10, 3 );

wp_insert_post fires for the same reasons save_post does, plus programmatic inserts that don't go through the post editor at all — an import script, a REST API create, a scheduled task. If your logic needs to run regardless of how the post was created, this is the hook, not save_post.

transition_post_status (action) — logic that depends on the status change itself

add_action( 'transition_post_status', function( $new_status, $old_status, $post ) {
    if ( 'publish' === $new_status && 'publish' !== $old_status ) {
        forwp_send_publish_notification( $post->ID );
    }
}, 10, 3 );

save_post fires on every save regardless of status; transition_post_status is the correct hook specifically for "this post just became published" (or unpublished, or moved to draft) — without it, a developer usually ends up manually comparing $post->post_status against a cached previous value inside save_post, which is fragile and easy to get wrong.

before_delete_post (action) — cleanup before the record is gone for good

add_action( 'before_delete_post', function( $post_id, $post ) {
    forwp_delete_external_record( get_post_meta( $post_id, 'forwp_external_id', true ) );
}, 10, 2 );

This fires on permanent deletion (bypassing trash, or emptying it), while the post's data — including its meta — is still readable. Waiting until after the fact means the meta you needed to clean up an external reference is already gone.

When It's Better to Bring In a Specialist

The remove_action/add_action guard, the autosave/revision check, and the distinction between save_post and wp_insert_post are exactly the kind of detail that separates a working demo from a handler that survives production traffic — and exactly the kind of thing worth putting on a WordPress developer skills checklist if you're evaluating a candidate or preparing for a technical interview yourself. A developer who has actually debugged a save-loop incident in production explains it in one sentence; one who hasn't usually reaches for wp_update_post() inside save_post without a second thought.

FAQ

Why does my save_post handler run twice on a single click of "Update"?
Most commonly because WordPress also fires save_post for the autosave that happens shortly before or after a manual save, and the handler has no guard against wp_is_post_autosave(). Add that check first, before any other logic.

Is it safe to call wp_update_post() inside a save_post handler?
Only if you remove the action before the call and re-add it after — otherwise wp_update_post() triggers save_post again, and if that handler unconditionally calls wp_update_post() too, the result is an infinite loop.

What's the actual difference between save_post and wp_insert_post?
save_post fires specifically for posts saved through the standard editor flow (and its autosaves/revisions). wp_insert_post fires for the same cases plus any programmatic insert — an import, a cron job, a REST API request — so it's the more reliable hook when you need to catch every possible way a post gets created.

Why use transition_post_status instead of checking post_status inside save_post?
Because transition_post_status hands you both the old and new status directly, with no need to cache or compare values yourself. Reimplementing that comparison inside save_post is a common source of subtle bugs when a post is saved multiple times in quick succession.

Does before_delete_post fire when a post is moved to trash?
No — moving to trash uses wp_trash_post and its own hooks. before_delete_post fires specifically on permanent deletion: bypassing the trash, or emptying it.

What should be on a WordPress developer's skills checklist for these hooks specifically?
Whether they instinctively guard save_post against autosaves and revisions, whether they know to remove their own action before an internal wp_update_post() call, and whether they can explain the difference between save_post and wp_insert_post without hesitating — all three come up constantly in real production code, and all three are cheap to verify in an interview.

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.

Originally published on 4wp.dev.

The Price of Attention: Fullstack WordPress Developers in the AI Venture (4wp.dev)

Anatoliy Dovgun — Wed, 28 Oct 2026 21:55:09 +0000

Attention is a resource. A person has only so much of it.

In 1971 Herbert A. Simon wrote that "a wealth of information creates a poverty of attention". He was talking about organizations. Today it describes one person: a fullstack WordPress developer with an IDE, a terminal and a few AI tools open at once.

Fullstack Was Already a Lot

A fullstack WordPress developer moves between PHP, blocks and JavaScript, the theme, the server and the client. Each switch costs something: you reload the context of the task before you can work again.

Agents Multiply Output, Not Attention

AI tools take away typing. They do not take away the need to understand what was typed.

Agents write code, run tests and ask for permissions. Each diff is something you have to review.
Subagents run in parallel and come back with reports. Five subagents give you five reports to read, not five finished tasks.
Chats draft roadmaps, texts and replies. Each open chat is one more thread you have to keep in your head.

The tools work in parallel, but your attention does not. Every stream ends up in one place: your review.

How We Spend It at 4wp.dev

1. One main thread. Choose the task that matters now. Everything else waits or goes to an agent.

2. Delegate with a check. Give an agent a clear task and a clear finish: a test that must pass, or a WP-CLI or REST call that must return the expected result. Then you check the result, not every step. Every chapter of the 4wp.dev Abilities API course ends with exactly this kind of check.

3. Subagents for conclusions. Use a subagent when you need an answer ("where is this hook registered?"), not a dump of files to read.

4. Close what you are not using. A chat that has finished its job goes away. An open tab is a small, constant demand on your attention.

5. Notifications in batches. Messages, mail and CI can wait until the end of a block of work. The client call can wait five minutes too.

Conclusion

AI made code cheap. Attention stayed expensive. The developer's job is moving from writing to deciding and reviewing, and both take attention. Plan it as carefully as you plan a server's resources.

More on WordPress development with AI agents: 4wp.dev.

Originally published on 4wp.dev.

False Affordance in WordPress (4wp.dev Methodologies): When UI Promises What Code Doesn't Deliver

Anatoliy Dovgun — Thu, 22 Oct 2026 19:26:58 +0000

A "Show more" button on my own portfolio showed nothing, and the console stayed clean. This post is the write-up: what a false affordance is, why it slips into WordPress themes and plugins, and how to fix it in a classic PHP template and in a block theme (FSE) with a Query Loop + JS. It is part of the Methodologies series on 4wp.dev.

Related on 4wp.dev: Full Site Editing and theme.json · Component-Driven Development · Atomic Design · TDD

What a false affordance is

A false affordance is an interface element that suggests an action is possible, but the action does not actually happen. A button that does nothing. A toggle with no effect. A setting that is saved and never applied.

The term comes from Don Norman's The Design of Everyday Things: a door handle you are supposed to push is a false affordance, because the handle invites you to pull.

It sounds like a design topic, but in WordPress it is mostly an engineering one. The design shows the promise. The code is what breaks it. And it is not limited to the UI: the same thing happens in APIs, hooks and function signatures.

A Real Case: The "Show More" That Shows Nothing

I will start with my own site, because it is the most honest example I have.

On the home page of anatoliy.dovgun.com there is a Projects block: a list of projects, and under it two controls, "Show more" and "All projects →".

Before:

All projects were already rendered on the page.
"Show more" was still there.
Clicking it did one thing: the button hid itself. Nothing new appeared.
The browser console was clean. No errors, no warnings.

That last point is what makes this kind of bug dangerous. Nothing failed, so nothing reported a failure. The button simply promised an action that did not exist. It is a silent bug, and it lived on my own portfolio.

Why it happened

The block came from the prototype / UI kit as one piece: "list + Show more button". The limit (how many items are visible before "Show more") was taken from the prototype, not from the data. When the static prototype became a real query over real projects, the list changed, but the button stayed exactly as it was drawn.

So the button rendered always, regardless of the data. Nobody asked the one question that matters for this control: are there any hidden items right now?

In other words, nobody clicked through every state. The designed state ("more projects than the limit") worked in the head of whoever drew it. The real state ("all projects already visible") was never clicked. A curious QA, or a developer with open eyes, would have clicked it in the first five minutes.

The Rule

Render the control only when the action is possible.

The rule is the same everywhere. Where you apply it depends on who renders the list.

Scenario A: classic PHP template

In a classic theme or a server-rendered template, PHP renders the list and knows the total. So PHP decides. If there are no hidden items, the button is not in the HTML at all:

<?php if ( $total > $visible_limit ) : ?>
    <button class="more" type="button">Show more</button>
<?php endif; ?>
<a class="readall" href="/projects/">All projects →</a>

No hidden items, no button. Nothing is promised that cannot be delivered.

Scenario B: block theme (FSE), Query Loop + JS

In a block theme it works differently, and this is where people coming from classic templates get caught.

The Query Loop block renders the items. The "Show more" button usually lives in the template or pattern as static markup, a Custom HTML block or a button block. No PHP condition wraps it. The limit is applied in the browser by JavaScript: show the first N items, hide the rest, reveal more on click.

That means JS must own the button state, and the state must be derived from the data:

Default state is "no button". Put hidden on it in the markup. Without JS, or before JS runs, the page promises nothing.
JS counts the matching items (taking active filters into account) and shows the button only if there is something left to show.
Every click and every filter change recalculates. When nothing is left, the button hides again.

<div class="pfoot">
    <button class="more" id="more" type="button" hidden>Show more</button>
    <a class="readall" href="/projects/">All projects →</a>
</div>

const batchSize = 5;
let visibleCount = batchSize;

function renderProjects() {
    const matched = matchingItems(); // respects the active filter
    items.forEach( ( li ) => { li.hidden = true; } );
    matched.forEach( ( li, index ) => { li.hidden = index >= visibleCount; } );

    const hasMore = matched.length > visibleCount;
    more.hidden = ! hasMore;
}

more.addEventListener( 'click', () => {
    visibleCount += batchSize;
    renderProjects();
} );

If the button sits at the start of a flex row with justify-content: space-between, give the link margin-left: auto. Otherwise "All projects →" jumps to the left when the button disappears.

FSE gotcha. Once a template has been saved in the Site Editor, WordPress uses the copy stored in the database, not the file in your theme. Fix the pattern file, reload, and nothing changes. When a fix "doesn't apply" in a block theme, check whether the template was customized in the Site Editor. If it was, fix it there or reset it to the theme version. More on how block themes are put together: Full Site Editing and theme.json.

After

On the fixed version of my site:

The home page shows the first 5 projects.
"Show more" loads the next 5.
When everything is visible, the button is gone.
"All projects →" always stays. It is a real action and real navigation.

The Same Pattern Elsewhere

Once you see it, you see it everywhere:

"Read more / Show less" on cards where the text is already shown in full, for example an "Our story" timeline where the toggle only changes its own label.
Pagination that shows "Next" on the last page.
A "Load more" that silently returns zero items.
Filter chips that produce an empty list with no message.

The fix is always the same question: what happens to this control when there is no data, too little data, or an error?

Why It Happens More Now: the AI Factor

AI-generated code makes this worse, for a simple reason. Give a model a mockup and it reproduces all the UI states that are drawn: the list, the button, the link. What it does not have is the data context: is the list empty, short, missing, filtered?

The generated code looks plausible, it runs, the console is clean, so the review becomes superficial. Nobody asks what the button does when there is nothing to show, because the code "obviously" handles the button.

If you work with AI on WordPress code, add one question to every review of UI code: "What happens if there is no data?"

Not Only Design: Two Types of Interfaces

False affordances are not limited to buttons. Any interface makes promises.

External interfaces (UI):

Buttons or toggles with no effect.
Admin settings that are saved but never applied.
An admin notice "Dismiss" that comes back on the next page load.

Internal interfaces (for developers):

A hook or filter is documented, but apply_filters() is never called with that name.
A shortcode or block attribute is accepted and ignored.
A function parameter is accepted but never used.
A REST endpoint returns success but does nothing.

The second group is worse in a way: the "user" is another developer, who builds on a feature that does not exist and only finds out in production.

The Cost

Lost trust. A button that does nothing teaches users that your interface lies. They stop clicking.
Support tickets. "I clicked Show more and nothing happened" is a real ticket someone has to answer.
Reviews. On WordPress.org, a setting that does nothing is a one-star review.
Open source. Other developers build on a documented hook that never fires.

Checklist

No data → no element. Render controls conditionally: on the server in PHP templates, in JS with a hidden default in block themes.
Every control has a visible effect. If clicking it can do nothing, it should not be there.
Every documented option or hook actually works. Search for the apply_filters() / do_action() call before you document it.
Test the edge states: empty, short, exactly at the limit, long, filtered, error.
Ask the AI-review question: "What happens if there is no data?"

Testing approaches that make edge states a habit, not an afterthought: TDD and BDD on 4wp.dev.

Conclusion

A small detail with a big effect. One button on my own portfolio kept promising something, and the console never said a word.

An honest interface promises only what it delivers. Click through every state, including the boring ones, and let the data decide which controls exist.

More methodologies for WordPress teams on 4wp.dev.

False Affordance in WordPress (4wp.dev Methodologies): When UI Promises What Code Doesn't Deliver

Anatoliy Dovgun — Mon, 19 Oct 2026 16:41:44 +0000

Related on 4wp.dev: Full Site Editing and theme.json · Component-Driven Development · Atomic Design · TDD

What a false affordance is

The term comes from Don Norman's The Design of Everyday Things: a door handle you are supposed to push is a false affordance, because the handle invites you to pull.

A Real Case: The "Show More" That Shows Nothing

I will start with my own site, because it is the most honest example I have.

On the home page of anatoliy.dovgun.com there is a Projects block: a list of projects, and under it two controls, "Show more" and "All projects →".

Before:

All projects were already rendered on the page.
"Show more" was still there.
Clicking it did one thing: the button hid itself. Nothing new appeared.
The browser console was clean. No errors, no warnings.

Why it happened

So the button rendered always, regardless of the data. Nobody asked the one question that matters for this control: are there any hidden items right now?

The Rule

Render the control only when the action is possible.

The rule is the same everywhere. Where you apply it depends on who renders the list.

Scenario A: classic PHP template

In a classic theme or a server-rendered template, PHP renders the list and knows the total. So PHP decides. If there are no hidden items, the button is not in the HTML at all:

<?php if ( $total > $visible_limit ) : ?>
    <button class="more" type="button">Show more</button>
<?php endif; ?>
<a class="readall" href="/projects/">All projects →</a>

No hidden items, no button. Nothing is promised that cannot be delivered.

Scenario B: block theme (FSE), Query Loop + JS

In a block theme it works differently, and this is where people coming from classic templates get caught.

That means JS must own the button state, and the state must be derived from the data:

Default state is "no button". Put hidden on it in the markup. Without JS, or before JS runs, the page promises nothing.
JS counts the matching items (taking active filters into account) and shows the button only if there is something left to show.
Every click and every filter change recalculates. When nothing is left, the button hides again.

<div class="pfoot">
    <button class="more" id="more" type="button" hidden>Show more</button>
    <a class="readall" href="/projects/">All projects →</a>
</div>

const batchSize = 5;
let visibleCount = batchSize;

function renderProjects() {
    const matched = matchingItems(); // respects the active filter
    items.forEach( ( li ) => { li.hidden = true; } );
    matched.forEach( ( li, index ) => { li.hidden = index >= visibleCount; } );

    const hasMore = matched.length > visibleCount;
    more.hidden = ! hasMore;
}

more.addEventListener( 'click', () => {
    visibleCount += batchSize;
    renderProjects();
} );

If the button sits at the start of a flex row with justify-content: space-between, give the link margin-left: auto. Otherwise "All projects →" jumps to the left when the button disappears.

After

On the fixed version of my site:

The home page shows the first 5 projects.
"Show more" loads the next 5.
When everything is visible, the button is gone.
"All projects →" always stays. It is a real action and real navigation.

The Same Pattern Elsewhere

Once you see it, you see it everywhere:

"Read more / Show less" on cards where the text is already shown in full, for example an "Our story" timeline where the toggle only changes its own label.
Pagination that shows "Next" on the last page.
A "Load more" that silently returns zero items.
Filter chips that produce an empty list with no message.

The fix is always the same question: what happens to this control when there is no data, too little data, or an error?

Why It Happens More Now: the AI Factor

If you work with AI on WordPress code, add one question to every review of UI code: "What happens if there is no data?"

Not Only Design: Two Types of Interfaces

False affordances are not limited to buttons. Any interface makes promises.

External interfaces (UI):

Buttons or toggles with no effect.
Admin settings that are saved but never applied.
An admin notice "Dismiss" that comes back on the next page load.

Internal interfaces (for developers):

A hook or filter is documented, but apply_filters() is never called with that name.
A shortcode or block attribute is accepted and ignored.
A function parameter is accepted but never used.
A REST endpoint returns success but does nothing.

The second group is worse in a way: the "user" is another developer, who builds on a feature that does not exist and only finds out in production.

The Cost

Lost trust. A button that does nothing teaches users that your interface lies. They stop clicking.
Support tickets. "I clicked Show more and nothing happened" is a real ticket someone has to answer.
Reviews. On WordPress.org, a setting that does nothing is a one-star review.
Open source. Other developers build on a documented hook that never fires.

Checklist

No data → no element. Render controls conditionally: on the server in PHP templates, in JS with a hidden default in block themes.
Every control has a visible effect. If clicking it can do nothing, it should not be there.
Every documented option or hook actually works. Search for the apply_filters() / do_action() call before you document it.
Test the edge states: empty, short, exactly at the limit, long, filtered, error.
Ask the AI-review question: "What happens if there is no data?"

Testing approaches that make edge states a habit, not an afterthought: TDD and BDD on 4wp.dev.

Conclusion

A small detail with a big effect. One button on my own portfolio kept promising something, and the console never said a word.

An honest interface promises only what it delivers. Click through every state, including the boring ones, and let the data decide which controls exist.

More methodologies for WordPress teams on 4wp.dev.

MVC in WordPress: The Pattern Everyone Learns, Few Truly Apply

Anatoliy Dovgun — Mon, 12 Oct 2026 20:56:31 +0000

📌 Originally published on 4wp.dev → MVC Pattern in WordPress.
Long read on LinkedIn: MVC in WordPress: the pattern everyone learns, few truly apply.

Every WordPress developer has heard of MVC. Very few plugins actually follow it.

WordPress isn't an MVC framework — but its building blocks map cleanly onto Model · View · Controller once you know where to look.

👉 Interactive diagram with all examples: 4wp.dev/architectures/mvc

1. Controller — the traffic director

Receives the request, validates it, calls the Model, picks the View. No SQL. No HTML.

In WordPress, Controllers are:

hook callbacks (init, save_post)
REST API route handlers
wp_ajax_* handlers

// Controller — REST endpoint
register_rest_route( 'myplugin/v1', '/products', [
    'methods'             => 'GET',
    'permission_callback' => fn() => current_user_can( 'read' ),
    'callback'            => function ( WP_REST_Request $req ) {
        $products = get_all_products( $req->get_param( 'category' ) ); // → Model
        return rest_ensure_response( $products );
    },
] );

➡️ More Controller examples (hooks, AJAX): 4wp.dev/architectures/mvc/#mvc-detail-controller

2. Model — the data layer

Owns data and business rules. Returns clean data. Never renders HTML.

In WordPress, Models are:

Custom Post Types, taxonomies, registered meta (schema)
$wpdb data-access functions/classes
Options API settings classes

// Model — the only layer that touches options
class PluginSettings {
    private const KEY = 'myplugin_settings';

    public static function get( string $key, $default = null ) {
        return ( get_option( self::KEY, [] ) )[ $key ] ?? $default;
    }
}

➡️ CPT schema and $wpdb examples: 4wp.dev/architectures/mvc/#mvc-detail-model

3. View — the presentation layer

Renders data it receives. No queries. No business logic.

In WordPress, Views are:

theme templates (single.php, archive.php)
shortcode output
Gutenberg block save() / render templates

<!-- View — escape, display, nothing else -->
<article class="product">
    <h1><?php echo esc_html( $product['title'] ); ?></h1>
    <p class="price"><?php echo esc_html( $product['price'] ); ?></p>
</article>

➡️ Shortcode and block examples: 4wp.dev/architectures/mvc/#mvc-detail-view

4. Real plugin: 4WP Weather

4WP Weather (GitHub) is built along the same lines:

Layer	In the plugin
Controller	REST route `forwp-weather/v1/weather` — the block calls it, PHP does the remote request
Model	Provider (OpenWeatherMap), API key in Options API, transient cache
View	Gutenberg block with Small / Compact / Advanced templates

Result: the API key never reaches the browser, cache lives in one place, and the block only renders.

Another example of the 4WP approach: 4WP SEO Helper (GitHub).

5. Quick checklist

[ ] Controllers are thin: validate → call Model → return/render
[ ] Only the Model touches $wpdb, options, meta
[ ] Views contain only escaping and markup
[ ] Nonces and capability checks live in the Controller

- [ ] Templates never call `WP_Query` directly

Go deeper

- 🔌 4WP plugins

Written by Anatoliy Dovgun · 4wp.dev — FSE WordPress development.
Follow: GitHub · X · DEV · Medium · Hashnode · YouTube

The Front Door You Forgot You Built: What These 5 REST API Hooks Actually Gate (4wp.dev Hooks Series)

Anatoliy Dovgun — Fri, 09 Oct 2026 15:28:24 +0000

Every WordPress site answers REST requests at /wp-json/ whether you built an API on purpose or not. The 5 hooks that actually gate it, in the order they really fire (not the order you registered them), from the 4wp.dev Hooks series.

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

The Problem

Every WordPress install answers REST requests at /wp-json/ whether or not anyone deliberately built an API — and most sites have at least one custom field, integration, or automation hooked into it without a clear picture of which of these five hooks actually runs first, or what happens if two of them disagree about whether a request should even be allowed through. The most common version of this problem: a developer adds an authentication check in the wrong hook, and it either never runs early enough to block anything, or it overwrites an error another check already set — silently reopening a door someone else had just closed.

Why This Is Dangerous

These hooks don't fire in registration order — they fire in a fixed pipeline order regardless of when your code adds them, and getting that order wrong changes what your check can actually see or prevent. A permission check added to the wrong hook runs after the request has already been routed and partially processed, which means "blocking" it there is really just hiding the result, not preventing the work that already happened. And rest_authentication_errors specifically is a filter that receives whatever error a previous check already set — overwriting that value unconditionally silently discards someone else's rejection and can open access nobody intended to leave open. For deeper coverage of designing custom endpoints and their permission model, see Custom Endpoints & Routes and Authentication & Permissions on 4wp.dev.

Step-by-Step Solution — The Pipeline, in Order

Step 1 — rest_api_init (action) — where every custom route gets registered

add_action( 'rest_api_init', function() {
    register_rest_route( '4wp/v1', '/widgets', array(
        'methods'             => 'GET',
        'callback'            => 'forwp_get_widgets',
        'permission_callback' => '__return_true',
    ) );
} );

This fires once, early, before any specific request is being handled — it's registration, not request handling. Nothing here should depend on the current request's data; that comes later in the pipeline.

Step 2 — rest_pre_dispatch (filter) — the earliest point to short-circuit a request entirely

add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
    if ( str_starts_with( $request->get_route(), '/4wp/v1/' ) && forwp_is_maintenance_mode() ) {
        return new WP_Error( 'forwp_maintenance', 'API temporarily unavailable.', array( 'status' => 503 ) );
    }
    return $result;
}, 10, 3 );

Returning a non-null value here skips routing and the endpoint's own callback entirely — the right tool for a blanket condition (maintenance mode, a global rate limit) that should apply before any specific route's own logic runs, not a substitute for per-route permission_callback checks.

Step 3 — rest_authentication_errors (filter) — respect what's already there, or you'll undo someone else's rejection

add_filter( 'rest_authentication_errors', function( $result ) {
    // If a previous check already set an error, don't overwrite it —
    // or you silently discard someone else's rejection.
    if ( null !== $result ) {
        return $result;
    }

    if ( forwp_request_is_from_blocked_ip() ) {
        return new WP_Error( 'forwp_blocked', 'Access denied.', array( 'status' => 403 ) );
    }
    return $result;
} );

$result is null when authentication hasn't yet failed or succeeded, true/a user object on success, or a WP_Error on failure — the same three-state contract that trips people up on the authenticate hook in the Auth category. Skipping the null !== $result check here is exactly the mistake that overwrites another plugin's authentication rejection with your own permissive default.

Step 4 — rest_prepare_post (filter) — shaping the response before it leaves the server

add_filter( 'rest_prepare_post', function( $response, $post, $request ) {
    $data = $response->get_data();
    unset( $data['internal_notes'] ); // Never let an internal-only field reach the public response.
    $response->set_data( $data );
    return $response;
}, 10, 3 );

This is the last checkpoint before a post's REST representation is sent — the correct place both to add computed fields and to strip anything that shouldn't be public, rather than trying to prevent a field from being queryable in the first place.

Step 5 — rest_insert_post (action) — side effects after a REST-driven write

add_action( 'rest_insert_post', function( $post, $request, $creating ) {
    if ( $creating ) {
        forwp_notify_new_post_via_api( $post->ID );
    }
}, 10, 3 );

Fires after a post is created or updated specifically through the REST API — the $creating boolean tells you which. Logic that should run regardless of how a post was saved (API or editor) belongs on wp_insert_post instead, covered in the Save & CRUD Hooks category.

When It's Better to Bring In a Specialist

Getting the order of these five hooks wrong doesn't usually throw a visible error — it just means a permission check runs too late to matter, or a public response leaks a field nobody meant to expose. A WordPress developer who has built and audited custom REST APIs checks the whole pipeline order as one system, the same discipline covered in more depth in REST API Development on 4wp.dev — outsourcing that specific review to someone who has already made and fixed these mistakes elsewhere is usually faster than tracing a silent permission gap through five hooks yourself.

FAQ

Do these five hooks fire in the order they're registered in code?
No — they fire in a fixed pipeline order determined by the REST API's own request lifecycle (rest_pre_dispatch → authentication → routing → rest_prepare_* → rest_insert_*), regardless of when your plugin registers its callbacks.

What's the difference between rest_pre_dispatch and rest_authentication_errors for blocking a request?
rest_pre_dispatch can short-circuit a request entirely, before routing, for conditions that apply broadly (maintenance mode, global rate limits). rest_authentication_errors is specifically about identity and access — and it can undo another check's rejection if you don't respect an existing non-null $result.

Why did my rest_authentication_errors check stop another plugin's block from working?
Almost certainly because the filter didn't check whether $result was already non-null before returning its own value — overwriting an existing WP_Error (or a success) with your own default silently replaces the other check's decision.

Should I use rest_prepare_post or register_rest_field to add a computed field to the response?
register_rest_field for a straightforward computed value tied to the schema. rest_prepare_post when you need to both add and remove fields, or when the logic depends on the full response object rather than a single field's value.

Does rest_insert_post fire for posts saved through the normal editor, not the REST API?
No — it fires specifically for posts created or updated through a REST API request. A normal editor save fires wp_insert_post and save_post, not rest_insert_post.

When should a dedicated WordPress team review a site's REST API hook usage?
When multiple plugins or custom code hook into authentication and response-shaping on the same endpoints — at that point, tracing which check actually wins requires understanding the full pipeline order, which is exactly the kind of audit worth outsourcing rather than reconstructing from scratch under time pressure.

Summary

A full breakdown of each of the 5 hooks in this category — with examples and a hands-on IDE — is on the REST API Hooks page, and the whole set is also available as one PDF to keep. For the broader discipline of building custom REST APIs on WordPress, see REST API Development on 4wp.dev.

Originally published on 4wp.dev.

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.

DEV Community: Anatoliy Dovgun

SDLC Explained for WordPress Developers: The 4wp.dev Umbrella, 7 Phases, 60 Years

What Is SDLC?

The 7 Phases of SDLC (the 7 Ribs of the 4wp.dev Umbrella)

SDLC vs Methodologies: Waterfall, Agile, Scrum, Kanban

A Short History of SDLC: Sixty Years of Weather

SDLC From Three Sides: Client, Project, Developer

SDLC in WordPress Development: Phase by Phase

From WordPress Developer to Tech Lead

SDLC and AI: AI Took One Rib

SDLC FAQ

Forecast for 2027: Sunny ☀️

More From 4wp.dev

The Hook That Fires Twice: Why save_post Isn't as Simple as It Looks (4wp.dev Hooks Series)

The Problem

Why This Is Dangerous

Step-by-Step Solution — The Contract of Each Hook

When It's Better to Bring In a Specialist

FAQ

Summary

The Price of Attention: Fullstack WordPress Developers in the AI Venture (4wp.dev)

Fullstack Was Already a Lot

Agents Multiply Output, Not Attention

How We Spend It at 4wp.dev

Conclusion

False Affordance in WordPress (4wp.dev Methodologies): When UI Promises What Code Doesn't Deliver

What a false affordance is

A Real Case: The "Show More" That Shows Nothing

Why it happened

The Rule

Scenario A: classic PHP template

Scenario B: block theme (FSE), Query Loop + JS

After

The Same Pattern Elsewhere

Why It Happens More Now: the AI Factor

Not Only Design: Two Types of Interfaces

The Cost

Checklist

Conclusion

False Affordance in WordPress (4wp.dev Methodologies): When UI Promises What Code Doesn't Deliver

What a false affordance is

A Real Case: The "Show More" That Shows Nothing

Why it happened

The Rule

Scenario A: classic PHP template

Scenario B: block theme (FSE), Query Loop + JS

After

The Same Pattern Elsewhere

Why It Happens More Now: the AI Factor

Not Only Design: Two Types of Interfaces

The Cost

Checklist

Conclusion

MVC in WordPress: The Pattern Everyone Learns, Few Truly Apply

1. Controller — the traffic director

2. Model — the data layer

3. View — the presentation layer

4. Real plugin: 4WP Weather

5. Quick checklist

- [ ] Templates never call WP_Query directly

Go deeper

- 🔌 4WP plugins

The Front Door You Forgot You Built: What These 5 REST API Hooks Actually Gate (4wp.dev Hooks Series)

The Problem

Why This Is Dangerous

Step-by-Step Solution — The Pipeline, in Order

When It's Better to Bring In a Specialist

FAQ

Summary

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

- [ ] Templates never call `WP_Query` directly

`admin_enqueue_scripts` and performance: check `$hook_suffix`

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