DEV Community: Anatoliy Dovgun

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.

add_filter(‘practice_case_b2b_migration’): Why Using __return_false Changes the Core Email Flow in WordPress

Anatoliy Dovgun — Sat, 07 Feb 2026 21:03:49 +0000

add_filter( 'send_email_change_email', '__return_false' )

Why Returning False Changes the Core Email Flow in WordPress

Filters in WordPress are often described as tools for modifying data.

In real-world systems — they control behavior.

And in complex architectures, they prevent infrastructure-level failures.

This article walks through a real B2B marketplace migration case and explains why returning false in specific filters is not a hack — but an architectural control decision.

The Scenario: B2B Marketplace + CRM Migration

Imagine:

You are building a B2B marketplace.
The source of truth for users is an external CRM.
Thousands of users must be migrated or synchronized.
During synchronization, user emails may change.
Users do not initiate these changes.

At first glance, this looks like a standard import task.

It isn’t.

What WordPress Does by Default

When wp_update_user() runs and detects an email change, WordPress:

Detects the email difference.
Prepares a notification.
Applies the filter send_email_change_email.
If the filter returns true → the email is sent.

Additionally, depending on context, WordPress may also trigger:

New user notification
Password change notification
Email verification flows

For interactive user behavior — this is correct.

For CRM-driven migration — this is dangerous.

The Infrastructure Risk

Uncontrolled email triggers during migration can cause:

Thousands of unintended emails
SMTP throttling
Domain reputation damage
Confused users
Support overload
Trust erosion

This is not a minor technical detail.

This is product-level and infrastructure-level risk.

The First Layer of Control (And Why It Wasn’t Enough)

During initial system design, we anticipated user creation issues.

So we disabled new user notifications:

add_filter( 'wp_send_new_user_notification_to_user', '__return_false' );

That solved welcome emails during migration.

But real-world testing exposed a gap.

Because:

Some users were created.
Some were updated.
Some had email changes.

Even with new user notifications disabled, WordPress still triggered:

send_email_change_email

Because from core perspective — email change is a separate lifecycle event.

Lesson:

Disabling one filter does not mean you control the lifecycle.

The Critical Decision Point

To prevent email change notifications:

add_filter( 'send_email_change_email', '__return_false' );

By default → true.

We explicitly return false.

Important:

This does not:

Modify user data
Override internal functions
Disable WordPress email globally
Break core logic

It changes a boolean decision flag.

That’s a behavioral override.

And that’s an architectural choice.

Why This Is Architecturally Significant

There is a difference between:

Modifying data
Modifying control flow

Boolean filters like:

send_email_change_email
send_password_change_email
user_has_cap

are not data transformers.

They are behavioral switches.

They sit at decision points inside core.

Changing them alters system flow — not data integrity.

That distinction matters.

Scoped Implementation (Best Practice)

This should never be applied blindly in production.

Recommended approach:

if ( defined( 'CRM_MIGRATION_PROCESS' ) && CRM_MIGRATION_PROCESS ) {
    add_filter( 'send_email_change_email', '__return_false' );
}

Better yet:

Apply only in CLI context
Scope to migration service layer
Enable only during sync
Remove after migration

Control the scope.

Never globally suppress lifecycle behavior without context.

A Practical Classification of WordPress Filters

Understanding filter types helps avoid architectural mistakes.

1. Data Filters

Modify values.

Examples:

the_content
pre_user_email

2. Boolean Control Filters

Control system decisions.

Examples:

send_email_change_email
send_password_change_email
user_has_cap

These are control switches.

3. Pre-Persistence Filters

Run before saving data.

Example:

pre_insert_user_data

4. Capability & Security Filters

Control permissions.

Example:

map_meta_cap

In our migration case, we were dealing with Boolean Control Filters.

These require architectural awareness.

Why This Was Required in B2B Context

In this migration:
Email changes were system-driven.
CRM was authoritative.
Users did not initiate updates.
No verification flow was required.

From UX perspective — notifications would create noise.

From infrastructure perspective — risk.

From architecture perspective — mandatory control.

Engineering Lessons
Study full lifecycle, not just creation.
Inspect internal trigger points in wp_update_user().
Map all related filters before mass operations.
Use scoped boolean filters.
Document every override.

WordPress core works correctly.

But it works correctly for interactive user flows.

CRM-driven synchronization is not interactive.

If you do not control trigger points —
core will execute its default behavior.

Final Thought

add_filter( 'send_email_change_email', '__return_false' );

This is not about “turning something off.”

It is about taking control over system behavior.

In complex B2B systems, filters are not customization tools.

They are infrastructure control mechanisms.

And every time you override default WordPress behavior,
you are making an architectural decision — not just writing code.

Source: https://4wp.dev

4wp Responsive Plugin

Anatoliy Dovgun — Tue, 03 Feb 2026 16:46:58 +0000

4WP Responsive

Responsive controls for core Gutenberg blocks with per-breakpoint spacing, visibility, font-size, and alignment support. Designed to be theme.json-first and editor-friendly.

Documentation

– Plugin page: https://4wp.dev/plugin/4wp-responsive/

– GitRepository: https://github.com/4wpdev/4wp-responsive

What it does today

– Responsive spacing per breakpoint (Padding/Margin: top/right/bottom/left).

– Responsive visibility per breakpoint (Hide / Show only).

– Responsive font-size per breakpoint for blocks that support typography.

– Responsive text alignment per breakpoint (left/center/right/justify).

– Works with core blocks (e.g. Heading, Paragraph, Group, List) and any block that supports the same features.

– Uses utility CSS classes + CSS variables (no frontend JS).

– Editor preview stays in sync with the selected device mode.

Advantages

– Theme.json-first: reads spacing and font-size presets from the active theme.

– Works with standard blocks (no custom block requirement).

– Minimal markup changes: classes + CSS variables only.

– Safe fallback: content stays intact if the plugin is deactivated.

– Single generated CSS file, cached with a hash.

How it works

– Presets (from theme.json) are applied via utility classes like:

– has-forwp-padding-top-mobile-40

– has-forwp-font-size-desktop-large

– has-forwp-text-align-mobile-center

– Custom values (e.g. 150 / 150px / 2rem) are applied via:

– class has-forwp-*-custom

– CSS variable on the block, e.g. –forwp-padding-top-mobile: 150px;

– this keeps output clean while allowing arbitrary values

Editor UI

You will find Responsive Spacing in the block inspector sidebar:

– Tabs: Desktop / Tablet / Mobile

– Sections: Padding, Margin, Font Size, Alignment, Visibility

– Current screen size is shown per tab

– Hidden blocks are dimmed in the editor instead of fully removed

Settings

Settings → 4WP Responsive

Breakpoints

Displayed in a table with the active source:

– theme.json (settings.custom.breakpoints), if present

– Plugin settings, only when theme.json has no breakpoints

– Default values if neither is available

If the theme defines breakpoints, custom fields are disabled to avoid conflicts.

CSS storage path

Generated CSS is stored in wp-content/uploads/4wp-responsive/ by default.

You can override the storage path with an absolute path if your architecture requires it.

Requirements

– WordPress 6.0+

– PHP 7.4+

– A theme with theme.json is recommended (for presets).

Notes

– The plugin respects theme.json presets for spacing and font sizes.

– Custom values are supported, but only through CSS variables (no inline padding/margin).

4WP-FAQ is not just another FAQ block — it is a smart wrapper around core Accordion.

Anatoliy Dovgun — Mon, 02 Feb 2026 21:16:44 +0000

4WP-FAQ is not another FAQ plugin and not a new block.
It’s a smart wrapper over the WordPress core Accordion, adding structure and meaning to existing content.

The plugin does not change design, does not break layouts, and does not modify the base block structure. It works entirely on top of native Accordion blocks, adding aggregation logic and Schema.org support.

What 4WP-FAQ does

Automatically converts Accordion-based questions and answers into valid FAQPage Schema (JSON-LD)

Aggregates all FAQ blocks across the site and understands where and in what context each question is used

Works only with real content — no duplication, no invented questions

Core value

4WP-FAQ creates a single source of truth for real questions and answers:

Clear visibility into which questions are actually used

Transparent mapping of questions to pages and contexts

Easy validation of content reuse and relevance

Philosophy

Content is the source of truth.
The plugin doesn’t generate knowledge — it records facts, aggregates them, and exposes data for analysis, reuse, and integrations.

Built for scale

Reuse common questions via autocomplete

Real usage and interaction statistics

Click and expansion tracking with entry-point context

A knowledge base built on actual user questions, not copies or assumptions

🔗 Plugin page & documentation:
https://4wp.dev/plugin/4wp-faq/

💻 GitHub repository:
https://github.com/4wpdev/4wp-faq

How to Use MCP with WordPress: Step-by-Step

Anatoliy Dovgun — Sat, 24 Jan 2026 22:28:00 +0000

Context

This guide shows how to connect an MCP client to WordPress via the MCP Adapter and create content using MCP tools.

Prerequisites

WordPress 6.9+
MCP Adapter installed and activated
MCP client (Cursor, Claude Desktop, VS Code, etc.)
Application Password for the WordPress admin user (HTTP transport)

Abilities Provider (Required)

MCP Adapter exposes only abilities that are explicitly registered and marked meta.mcp.public=true. That means you need a small abilities provider plugin that registers admin‑only tools such as create-post and update-post.

GitHub → 4wp-mcp-abilities

Important: This is not a production plugin. Treat it as reference code only. You can adapt it inside a theme or a temporary internal plugin, but you must review security, permissions, and data exposure before using it in any real environment.

The repository is intentionally minimal and acts as a reference implementation.

Code is poetry.

What exactly must be enabled

Abilities plugin active (admin‑only).
Abilities registered on wp_abilities_api_init.
Each ability includes meta.mcp.public = true.
Admin capability check (recommended: manage_options).

*- Abilities code example (minimal) *

// Register on wp_abilities_api_init
wp_register_ability('your-plugin/create-post', [
  'label' => 'Create Post',
  'description' => 'Create a WordPress post',
  'input_schema' => [
    'type' => 'object',
    'properties' => [
      'title' => ['type' => 'string'],
      'content' => ['type' => 'string'],
      'status' => ['type' => 'string', 'default' => 'draft']
    ],
    'required' => ['title','content']
  ],
  'execute_callback' => function($input){
    return wp_insert_post([
      'post_title' => $input['title'],
      'post_content' => $input['content'],
      'post_status' => $input['status'] ?? 'draft'
    ]);
  },
  'permission_callback' => function(){
    return current_user_can('manage_options');
  },
  'meta' => [
    'mcp' => [
      'public' => true,
      'type' => 'tool'
    ]
  ]
]);

Steps

Step 1: Install and activate MCP Adapter

Command (WP-CLI):

cd "/path/to/wordpress" wp plugin install mcp-adapter --activate

You can also activate via WP Admin → Plugins → Installed Plugins.

Step 2: Install and activate the Abilities Provider plugin

Install the plugin, then activate it in WP Admin. This is required for content actions to appear as MCP tools.

Step 3: Configure MCP client (HTTP)

Use the MCP WordPress remote proxy to connect over HTTP:

{
  "mcpServers": {
    "wordpress-local": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "http://your-site.local/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "admin",
        "WP_API_PASSWORD": "YOUR_APP_PASSWORD"
      }
    }
  }
}

Step 4: Verify MCP server in your editor

Open View → Command Palette → MCP: Open MCP Settings
Confirm the server is listed and has no errors
Reload the editor

Step 5: List tools and execute an ability
Command (MCP tools/list):


{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}
**Command (Execute ability)**:


{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"mcp-adapter-execute-ability","arguments":{"ability_name":"your-plugin/create-post","parameters":{"title":"Example","content":"Hello from MCP","status":"draft"}}}}

Commands

tools/list — list MCP tools
tools/call — execute a tool

API

Default endpoint: /wp-json/mcp/mcp-adapter-default-server
Transport: HTTP or STDIO

Logic

MCP connects to WordPress
MCP discovers tools (abilities)
MCP executes tools to read/write content

Expected Result

MCP client can list tools
MCP can create or update posts through abilities FAQ

**Q: What should I watch out for?
**Sometimes the agent output lands as one big Classic block. Convert it to blocks once, and the content renders correctly.

**Q: Can an agent write in blocks?
**Yes. Send Gutenberg block markup () in the content so WordPress opens it as blocks instead of Classic.

**Q: Do I need to write custom code?
**Yes. The MCP Adapter only exposes abilities that are explicitly marked meta.mcp.public=true.

**Q: Why does WP-CLI fail on Local?
**Local uses a site-specific MySQL socket. If WP-CLI cannot connect, pass the socket via WP_CLI_DB_HOST.

**Q: Is STDIO safe for production?
**STDIO is intended for local development. Use HTTP with Application Passwords for production.

Summary

Install MCP Adapter, activate an abilities provider plugin, configure your MCP client, and use MCP tools to create or update content. Keep abilities admin‑only and expose only what you need.

References

Thanks to the Automattic team for making MCP Adapter possible.

Step 2: Essential Theme Files – Core WordPress Theme Structure

Anatoliy Dovgun — Wed, 27 Aug 2025 09:01:19 +0000

Step 2: Essential Theme Files

Create the core files required for a WordPress Full Site Editor theme using the 4WP Starter Theme* as our foundation for Personal Branding and Corporate sites.

Project Foundation:

Base Theme: 4WP Starter Theme* - FSE starter theme built for developers
Theme Name: 4WP Starter Theme* (customize for your project)
Use Cases: Personal Branding Site and Corporate websites
License: MIT License (developer-friendly)

Essential Files:

style.css - Theme header and metadata (REQUIRED)
theme.json - FSE configuration and design tokens (REQUIRED)
templates/index.html - Main FSE template (REQUIRED for theme functionality)
functions.php - Theme functionality and hooks (recommended for professional themes)
screenshot.png - Theme preview image (1200x900px, WordPress standard)

GitHub Integration:

The 4WP Starter Theme* repository (🚧 under development - use your own theme name for production) provides:
Version control: Git-based development workflow
Collaboration: Issues, pull requests, and community contributions
Documentation: README.md with setup instructions
Licensing: Clear MIT license for commercial and personal use
Updates: Regular improvements and WordPress compatibility updates

Next Step:

Configure Composer for dependency management and modern PHP development practices with the 4WP Starter Theme* foundation.

Completed Step:

Basic FSE theme structure and WordPress development fundamentals established with proper directory organization and security practices.

===
Resources & References
Full Course on GitHub: https://github.com/4wpdev/4wp-course-fse-theme-development
Theme Code on GitHub: https://github.com/4wpdev/4wp-starter-theme
Course for WordPress developers: https://4wp.dev/course/fse-theme-development/
Author Fullstack WordPress developer: https://anatoliy.dovgun.com/

Step 1: Basic Theme Structure – FSE Theme Development

Anatoliy Dovgun — Tue, 26 Aug 2025 10:40:15 +0000

Step 1: Basic Theme Structure

Create the fundamental folder structure for a Full Site Editor (FSE) theme following WordPress best practices.

Code Snippet:
cd wp-content/themes/starry mkdir -p {assets/{css,js,images},inc,parts,patterns,styles,templates}

What This Creates:

assets/ – Static files (CSS, JS, images)
inc/ – PHP includes and functions
parts/ – Template parts (header, footer, etc.)
patterns/ – Block patterns
styles/ – Theme style variations
templates/ – HTML template files

Next Step:

After creating the structure, we’ll add the essential theme files (style.css, theme.json, functions.php).