Forem: Anatoliy Dovgun

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).