DEV Community: Muhammad Medhat

WordPress Block Themes vs Classic Themes: Should You Switch in 2026?

Muhammad Medhat — Sun, 16 Aug 2026 15:17:39 +0000

If you've been developing WordPress websites for several years, there's a good chance you've spent a lot of time working with files like:

header.php
footer.php
single.php
page.php
archive.php
functions.php

That's certainly where most of my WordPress development experience has been.

But WordPress has been changing.

With the Block Editor, Site Editor, block themes, patterns, and theme.json, WordPress now offers a very different approach to theme development.

So I decided to take a closer look at the question:

If you're already comfortable building classic WordPress themes, is it worth moving toward block themes in 2026?

This isn't an article written from the perspective of someone who has spent years exclusively building block themes. Most of my own WordPress work has traditionally involved classic themes.

Instead, I'm looking at block themes from the perspective of an experienced WordPress developer who is exploring how the platform is evolving—and where the newer approach fits alongside the architecture I've used extensively.

Classic Themes vs Block Themes

WordPress currently identifies two primary theme types:

Classic themes
Block themes

According to the official WordPress Theme Developer Handbook, classic themes primarily use PHP, JavaScript, and CSS and can make extensive use of WordPress functions, hooks, and filters.

Block themes, on the other hand, are built around block markup and HTML-based templates and allow users to edit more areas of the website through the Site Editor.

A simplified comparison looks like this:

Classic Theme	Block Theme
PHP templates	HTML block templates
`single.php`	`templates/single.html`
`header.php`	`parts/header.html`
`footer.php`	`parts/footer.html`
Template hierarchy	Block-based templates
Custom PHP logic	Blocks + APIs + plugins
Customizer / theme options	Site Editor / Styles
`theme.json` optional	`theme.json` commonly used

This doesn't mean classic themes are obsolete.

They aren't.

WordPress continues to maintain documentation for classic theme development, and classic themes remain a valid part of the platform.

What I'm Used to: Classic Themes

A traditional WordPress theme might have a structure like this:

my-theme/
├── style.css
├── functions.php
├── index.php
├── header.php
├── footer.php
├── sidebar.php
├── single.php
├── page.php
├── archive.php
└── 404.php

The templates contain PHP and WordPress template functions.

For example:

<?php get_header(); ?>

<main class="site-content">

    <?php if ( have_posts() ) : ?>

        <?php while ( have_posts() ) : the_post(); ?>

            <article <?php post_class(); ?>>

                <h1><?php the_title(); ?></h1>

                <div class="entry-content">
                    <?php the_content(); ?>
                </div>

            </article>

        <?php endwhile; ?>

    <?php endif; ?>

</main>

<?php get_footer(); ?>

For developers who have spent years working with WordPress, this architecture is very familiar.

You have direct access to PHP, the Loop, template files, hooks, filters, conditional tags, queries, and all the other tools that make WordPress flexible.

The official WordPress documentation still describes this as the classic theme approach.

So What Is a Block Theme?

A block theme changes the way the theme's templates are constructed.

Instead of building your main templates using PHP, you use HTML files containing WordPress block markup.

A simplified block theme might look like:

my-block-theme/
├── style.css
├── theme.json
├── templates/
│   ├── index.html
│   ├── single.html
│   └── page.html
└── parts/
    ├── header.html
    └── footer.html

A single.html template could look something like:

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">

    <!-- wp:post-title /-->

    <!-- wp:post-featured-image /-->

    <!-- wp:post-content /-->

</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer"} /-->

There's no traditional PHP Loop here.

Instead, the template is composed of blocks.

WordPress defines a block theme as a theme that has an index.html template in the templates or block-templates directory, with templates built from block markup.

The Big Difference: Who Controls the Layout?

This is probably the most important conceptual difference.

With a traditional classic theme, the developer typically controls the site's structure through PHP template files.

With a block theme, the Site Editor can be used to edit areas such as:

Header
Footer
Navigation
Templates
Template parts
Global styles
Other block-based content

This means the site owner can have significantly more control over the structure of the website without modifying PHP files.

WordPress describes this as one of the major advantages of block themes.

For a client who frequently wants to modify the website layout, this can be a big advantage.

Where Does `theme.json` Fit?

This is one of the areas I find particularly interesting.

theme.json is a configuration file that allows developers to define global settings and styles for a WordPress theme.

And importantly:

theme.json isn't exclusive to block themes.

WordPress's official documentation explicitly states that theme.json works with both block and classic themes.

That makes it especially interesting for developers who primarily work with classic themes.

You don't necessarily need to abandon your existing development approach to start using modern WordPress features.

A Simple `theme.json`

A basic modern theme.json could look like this:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3,
    "settings": {
        "appearanceTools": true,
        "layout": {
            "contentSize": "720px",
            "wideSize": "1200px"
        }
    }
}

There are two properties here that developers should understand:

"$schema"

and:

"version": 3

They aren't the same thing.

`version`

The version property specifies which theme.json schema version the theme is using.

As of the current official documentation, Version 3 is the latest theme.json version. Version 3 works with WordPress 6.6 and later.

`$schema`

The $schema property tells development tools which JSON Schema to use.

This can provide features such as:

Autocomplete
Validation
Editor hints
Error reporting
Property suggestions

WordPress provides schemas for individual WordPress versions, and its documentation recommends using the oldest WordPress version your theme supports when choosing a version-specific schema.

For example:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3
}

If your theme targets a different minimum WordPress version, use the appropriate schema URL for that target.

For the latest development schema, WordPress also provides:

https://schemas.wp.org/trunk/theme.json

However, for a production theme, targeting the appropriate stable WordPress version is generally safer than relying on trunk.

Why Is `theme.json` Important?

theme.json can control a surprisingly large part of the WordPress design system.

For example:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3,

    "settings": {
        "color": {
            "palette": [
                {
                    "slug": "primary",
                    "color": "#2563eb",
                    "name": "Primary"
                },
                {
                    "slug": "dark",
                    "color": "#111827",
                    "name": "Dark"
                }
            ]
        },

        "typography": {
            "fluid": true
        }
    }
}

You can use theme.json for things such as:

Color palettes
Typography
Spacing
Layout
Borders
Shadows
Block settings
Custom templates
Template parts
Patterns
Global styles

The official documentation describes theme.json as a configuration file for global settings, styles, templates, template parts, and more.

Classic Themes Can Use Modern WordPress Features Too

This is an important point that sometimes gets lost in the block-theme discussion.

You don't necessarily have:

Classic theme OR modern WordPress.

There is a middle ground.

WordPress documentation specifically notes that classic themes can use theme.json and take advantage of block-editor functionality.

The WordPress community sometimes calls these hybrid themes—classic themes that adopt some modern block-related functionality.

WordPress notes that "hybrid theme" is a commonly used community term rather than an official third theme type.

This is actually an interesting option for developers like me who have extensive experience with classic themes.

You can gradually adopt newer WordPress capabilities without necessarily rewriting an entire project.

Template Parts: PHP vs Blocks

Here's another example of the architectural difference.

In a classic theme, you might have:

<?php get_header(); ?>

...

<?php get_footer(); ?>

WordPress also provides functions such as:

get_template_part();

for reusing template components.

With a block theme, you can use template-part blocks:

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:post-content /-->

<!-- wp:template-part {"slug":"footer"} /-->

The underlying concept is similar:

Reuse common parts of your website.

But the implementation is different.

The classic approach uses PHP templates and WordPress functions.

The block approach uses block markup and template parts.

Does a Block Theme Mean No PHP?

No.

This is another misconception worth clearing up.

WordPress is still a PHP application.

Plugins can still register:

Custom post types
Taxonomies
REST API endpoints
Hooks
Filters
Custom functionality
Server-side logic

For example:

add_action( 'init', function () {

    register_post_type( 'portfolio', [
        'public'   => true,
        'label'    => 'Portfolio',
        'supports' => [
            'title',
            'editor',
            'thumbnail'
        ]
    ] );

} );

The difference is primarily in how the theme handles presentation and templates, not that PHP suddenly disappears from WordPress.

In fact, keeping application/business functionality in plugins rather than tying it tightly to the theme is often a useful architectural approach.

When Would I Still Choose a Classic Theme?

This is where my own experience influences my answer.

If I were working on an existing project that is already built around a classic theme and works well, I wouldn't automatically recommend rebuilding it as a block theme.

There has to be a reason.

For example, I'd be comfortable continuing with a classic theme when:

1. The existing architecture works

If the site is stable, maintainable, and meeting the client's requirements, changing architecture just because a newer approach exists doesn't necessarily provide enough value.

2. The project relies heavily on custom PHP templates

Some projects have complex template logic and custom integrations where the traditional PHP architecture is already a good fit.

3. The team knows the classic architecture well

Development speed and maintainability matter.

If a team can build and maintain a classic theme efficiently, that has real value.

4. The client doesn't need full Site Editor control

If the website structure is intentionally controlled by developers, the biggest advantage of a block theme may not be necessary.

When Would I Consider a Block Theme?

For a new project, however, I would definitely consider a block theme.

Especially when:

The client wants visual control

If the client wants to modify headers, footers, templates, and global styles without involving a developer, the Site Editor can be very useful.

The website is heavily block-based

If the entire content strategy already revolves around Gutenberg, patterns, and blocks, a block theme can be a natural fit.

You want a centralized design system

theme.json provides a structured way to define colors, typography, spacing, layout, and other design settings.

You're building a new theme from scratch

A new project gives you an opportunity to adopt the architecture without having to migrate years of existing code.

WordPress's current Theme Handbook describes block themes as the modern method of building WordPress themes and says its theme-development documentation primarily focuses on this approach.

What About Performance?

This is one area where I would avoid making absolute claims.

You'll sometimes hear:

"Block themes are faster."

Or:

"Classic themes are faster."

Neither statement is universally true.

Performance depends on the implementation.

A poorly optimized block theme can be slow.

A carefully built classic theme can be extremely fast.

Things such as:

Hosting
Database queries
Images
JavaScript
CSS
Third-party scripts
Plugins
Caching
Page complexity

can all have a major impact.

So I wouldn't choose a theme architecture based solely on the assumption that one is automatically faster.

What Should a Classic-Theme Developer Learn?

This is probably the question I'm asking myself as much as anyone reading this article.

If you've already spent years learning classic WordPress development, should you throw all of that knowledge away?

Definitely not.

I would look at it as an expansion of your existing skills.

A reasonable learning path could be:

Classic WordPress Development
            ↓
       Gutenberg
            ↓
       Block Editor
            ↓
       theme.json
            ↓
       Block Patterns
            ↓
       Block Themes
            ↓
      Custom Blocks

Your existing knowledge of:

PHP
WordPress hooks
Filters
Template hierarchy
The Loop
Custom post types
REST APIs
Plugins
Security
Performance

doesn't become useless.

You're simply adding another layer to your WordPress toolkit.

My Perspective as a WordPress Developer

Most of my WordPress development experience has been with classic themes, so I'm not going to pretend that I've spent the majority of my career building block themes.

I haven't.

But that's exactly why I found the evolution interesting.

When you've been working with WordPress for years, it's easy to keep using the architecture you're comfortable with.

And there is nothing wrong with that when the architecture is appropriate.

But WordPress is clearly investing heavily in the block-based direction.

The official Theme Handbook now describes block themes as the modern method of building themes and focuses its current guidance heavily on that approach.

For me, that doesn't mean:

"Classic themes are dead."

It means:

"As WordPress developers, we should understand where the platform is going, even if our current projects still use the architecture we're most experienced with."

That's the approach I'm taking.

I'm not replacing my classic-theme knowledge.

I'm expanding it.

So, Should You Switch?

My answer is:

It depends.

If you're maintaining an existing classic WordPress website that works well, I wouldn't migrate it simply because block themes are newer.

If you're starting a new project, I'd at least evaluate whether a block theme makes sense.

And if you're a WordPress developer who has mostly worked with classic themes, I'd definitely recommend learning:

Block Editor
theme.json
Patterns
Template Parts
Site Editor
Block Themes
Custom Blocks

You don't need to become a block-theme expert overnight.

But understanding the architecture will make it much easier to work with modern WordPress projects.

Final Thoughts

WordPress theme development isn't necessarily a choice between:

Classic = Old
Block = New

It's more nuanced than that.

Classic themes remain powerful and relevant.

Block themes provide a newer approach that gives WordPress users much greater control over templates and site-wide design through blocks and the Site Editor.

And theme.json provides an interesting bridge between the two worlds because it can be used with both classic and block themes.

For developers who have spent years working with classic themes, the goal shouldn't be to forget everything we already know.

The goal is to understand the new architecture well enough to decide when it actually makes sense to use it.

That's where I currently see the value in learning block themes.

Not because classic themes have suddenly become irrelevant—but because WordPress itself is evolving, and we should evolve with it.

Official WordPress References

This article is based primarily on the official WordPress Developer Documentation:

WordPress Theme Developer Handbook
https://developer.wordpress.org/themes/
What Is a Theme?
https://developer.wordpress.org/themes/getting-started/what-is-a-theme/
Block Editor — Themes
https://developer.wordpress.org/block-editor/how-to-guides/themes/
Introduction to theme.json
https://developer.wordpress.org/themes/global-settings-and-styles/introduction-to-theme-json/
theme.json Version 3 Reference
https://developer.wordpress.org/block-editor/reference-guides/theme-json-reference/theme-json-living/
Developing with theme.json
https://developer.wordpress.org/block-editor/how-to-guides/themes/global-settings-and-styles/
Classic Themes
https://developer.wordpress.org/themes/classic-themes/

All technical claims and examples in this article should be checked against the official documentation for the WordPress version your project supports, particularly when working with theme.json versions and schemas.

WordPress Block Themes vs Classic Themes: Should You Switch in 2026?

Muhammad Medhat — Sun, 16 Aug 2026 15:10:57 +0000

If you've been developing WordPress websites for several years, there's a good chance you've spent a lot of time working with files like:

header.php
footer.php
single.php
page.php
archive.php
functions.php

That's certainly where most of my WordPress development experience has been.

But WordPress has been changing.

With the Block Editor, Site Editor, block themes, patterns, and theme.json, WordPress now offers a very different approach to theme development.

So I decided to take a closer look at the question:

If you're already comfortable building classic WordPress themes, is it worth moving toward block themes in 2026?

This isn't an article written from the perspective of someone who has spent years exclusively building block themes. Most of my own WordPress work has traditionally involved classic themes.

Classic Themes vs Block Themes

WordPress currently identifies two primary theme types:

Classic themes
Block themes

According to the official WordPress Theme Developer Handbook, classic themes primarily use PHP, JavaScript, and CSS and can make extensive use of WordPress functions, hooks, and filters.

Block themes, on the other hand, are built around block markup and HTML-based templates and allow users to edit more areas of the website through the Site Editor.

A simplified comparison looks like this:

Classic Theme	Block Theme
PHP templates	HTML block templates
`single.php`	`templates/single.html`
`header.php`	Template parts
`footer.php`	Template parts
Template hierarchy	Block-based templates
Custom PHP logic	Blocks + APIs + plugins
Customizer / theme options	Site Editor / Styles
`theme.json` optional	`theme.json` commonly used

This doesn't mean classic themes are obsolete.

They aren't.

WordPress continues to maintain documentation for classic theme development, and classic themes remain a valid part of the platform.

What I'm Used to: Classic Themes

A traditional WordPress theme might have a structure like this:

my-theme/
├── style.css
├── functions.php
├── index.php
├── header.php
├── footer.php
├── sidebar.php
├── single.php
├── page.php
├── archive.php
└── 404.php

The templates contain PHP and WordPress template functions.

For example:

<?php get_header(); ?>

<main class="site-content">

    <?php if ( have_posts() ) : ?>

        <?php while ( have_posts() ) : the_post(); ?>

            <article <?php post_class(); ?>>

                <h1><?php the_title(); ?></h1>

                <div class="entry-content">
                    <?php the_content(); ?>
                </div>

            </article>

        <?php endwhile; ?>

    <?php endif; ?>

</main>

<?php get_footer(); ?>

For developers who have spent years working with WordPress, this architecture is very familiar.

You have direct access to PHP, the Loop, template files, hooks, filters, conditional tags, queries, and all the other tools that make WordPress flexible.

The official WordPress documentation still describes this as the classic theme approach.

So What Is a Block Theme?

A block theme changes the way the theme's templates are constructed.

Instead of building your main templates using PHP, you use HTML files containing WordPress block markup.

A simplified block theme might look like:

my-block-theme/
├── style.css
├── theme.json
├── templates/
│   ├── index.html
│   ├── single.html
│   └── page.html
└── parts/
    ├── header.html
    └── footer.html

A single.html template could look something like:

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">

    <!-- wp:post-title /-->

    <!-- wp:post-featured-image /-->

    <!-- wp:post-content /-->

</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer"} /-->

There's no traditional PHP Loop here.

Instead, the template is composed of blocks.

WordPress defines a block theme as a theme that has an index.html template in the templates or block-templates directory, with templates built from block markup.

The Big Difference: Who Controls the Layout?

This is probably the most important conceptual difference.

With a traditional classic theme, the developer typically controls the site's structure through PHP template files.

With a block theme, the Site Editor can be used to edit areas such as:

Header
Footer
Navigation
Templates
Template parts
Global styles
Other block-based content

This means the site owner can have significantly more control over the structure of the website without modifying PHP files.

WordPress describes this as one of the major advantages of block themes.

For a client who frequently wants to modify the website layout, this can be a big advantage.

Where Does `theme.json` Fit?

This is one of the areas I find particularly interesting.

theme.json is a configuration file that allows developers to define global settings and styles for a WordPress theme.

And importantly:

theme.json isn't exclusive to block themes.

WordPress's official documentation explicitly states that theme.json works with both block and classic themes.

That makes it especially interesting for developers who primarily work with classic themes.

You don't necessarily need to abandon your existing development approach to start using modern WordPress features.

A Simple `theme.json`

A basic modern theme.json could look like this:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3,
    "settings": {
        "appearanceTools": true,
        "layout": {
            "contentSize": "720px",
            "wideSize": "1200px"
        }
    }
}

There are two properties here that developers should understand:

"$schema"

and:

"version": 3

They aren't the same thing.

`version`

The version property specifies which theme.json schema version the theme is using.

As of the current official documentation, Version 3 is the latest theme.json version. Version 3 works with WordPress 6.6 and later.

`$schema`

The $schema property tells development tools which JSON Schema to use.

This can provide features such as:

Autocomplete
Validation
Editor hints
Error reporting
Property suggestions

WordPress provides schemas for individual WordPress versions, and its documentation recommends using the oldest WordPress version your theme supports when choosing a version-specific schema.

For example:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3
}

If your theme targets a different minimum WordPress version, use the appropriate schema URL for that target.

For the latest development schema, WordPress also provides:

https://schemas.wp.org/trunk/theme.json

However, for a production theme, targeting the appropriate stable WordPress version is generally safer than relying on trunk.

Why Is `theme.json` Important?

theme.json can control a surprisingly large part of the WordPress design system.

For example:

{
    "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
    "version": 3,

    "settings": {
        "color": {
            "palette": [
                {
                    "slug": "primary",
                    "color": "#2563eb",
                    "name": "Primary"
                },
                {
                    "slug": "dark",
                    "color": "#111827",
                    "name": "Dark"
                }
            ]
        },

        "typography": {
            "fluid": true
        }
    }
}

You can use theme.json for things such as:

Color palettes
Typography
Spacing
Layout
Borders
Shadows
Block settings
Custom templates
Template parts
Patterns
Global styles

The official documentation describes theme.json as a configuration file for global settings, styles, templates, template parts, and more.

Classic Themes Can Use Modern WordPress Features Too

This is an important point that sometimes gets lost in the block-theme discussion.

You don't necessarily have:

Classic theme OR modern WordPress.

There is a middle ground.

WordPress documentation specifically notes that classic themes can use theme.json and take advantage of block-editor functionality.

The WordPress community sometimes calls these hybrid themes—classic themes that adopt some modern block-related functionality.

WordPress notes that "hybrid theme" is a commonly used community term rather than an official third theme type.

This is actually an interesting option for developers like me who have extensive experience with classic themes.

You can gradually adopt newer WordPress capabilities without necessarily rewriting an entire project.

Template Parts: PHP vs Blocks

Here's another example of the architectural difference.

In a classic theme, you might have:

<?php get_header(); ?>

...

<?php get_footer(); ?>

WordPress also provides functions such as:

get_template_part();

for reusing template components.

With a block theme, you can use template-part blocks:

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:post-content /-->

<!-- wp:template-part {"slug":"footer"} /-->

The underlying concept is similar:

Reuse common parts of your website.

But the implementation is different.

The classic approach uses PHP templates and WordPress functions.

The block approach uses block markup and template parts.

Does a Block Theme Mean No PHP?

No.

This is another misconception worth clearing up.

WordPress is still a PHP application.

Plugins can still register:

Custom post types
Taxonomies
REST API endpoints
Hooks
Filters
Custom functionality
Server-side logic

For example:

add_action( 'init', function () {

    register_post_type( 'portfolio', [
        'public'   => true,
        'label'    => 'Portfolio',
        'supports' => [
            'title',
            'editor',
            'thumbnail'
        ]
    ] );

} );

The difference is primarily in how the theme handles presentation and templates, not that PHP suddenly disappears from WordPress.

In fact, keeping application/business functionality in plugins rather than tying it tightly to the theme is often a useful architectural approach.

When Would I Still Choose a Classic Theme?

This is where my own experience influences my answer.

If I were working on an existing project that is already built around a classic theme and works well, I wouldn't automatically recommend rebuilding it as a block theme.

There has to be a reason.

For example, I'd be comfortable continuing with a classic theme when:

1. The existing architecture works

If the site is stable, maintainable, and meeting the client's requirements, changing architecture just because a newer approach exists doesn't necessarily provide enough value.

2. The project relies heavily on custom PHP templates

Some projects have complex template logic and custom integrations where the traditional PHP architecture is already a good fit.

3. The team knows the classic architecture well

Development speed and maintainability matter.

If a team can build and maintain a classic theme efficiently, that has real value.

4. The client doesn't need full Site Editor control

If the website structure is intentionally controlled by developers, the biggest advantage of a block theme may not be necessary.

When Would I Consider a Block Theme?

For a new project, however, I would definitely consider a block theme.

Especially when:

The client wants visual control

If the client wants to modify headers, footers, templates, and global styles without involving a developer, the Site Editor can be very useful.

The website is heavily block-based

If the entire content strategy already revolves around Gutenberg, patterns, and blocks, a block theme can be a natural fit.

You want a centralized design system

theme.json provides a structured way to define colors, typography, spacing, layout, and other design settings.

You're building a new theme from scratch

A new project gives you an opportunity to adopt the architecture without having to migrate years of existing code.

WordPress's current Theme Handbook describes block themes as the modern method of building WordPress themes and says its theme-development documentation primarily focuses on this approach.

What About Performance?

This is one area where I would avoid making absolute claims.

You'll sometimes hear:

"Block themes are faster."

Or:

"Classic themes are faster."

Neither statement is universally true.

Performance depends on the implementation.

A poorly optimized block theme can be slow.

A carefully built classic theme can be extremely fast.

Things such as:

Hosting
Database queries
Images
JavaScript
CSS
Third-party scripts
Plugins
Caching
Page complexity

can all have a major impact.

So I wouldn't choose a theme architecture based solely on the assumption that one is automatically faster.

What Should a Classic-Theme Developer Learn?

This is probably the question I'm asking myself as much as anyone reading this article.

If you've already spent years learning classic WordPress development, should you throw all of that knowledge away?

Definitely not.

I would look at it as an expansion of your existing skills.

A reasonable learning path could be:

Classic WordPress Development
            ↓
       Gutenberg
            ↓
       Block Editor
            ↓
       theme.json
            ↓
       Block Patterns
            ↓
       Block Themes
            ↓
      Custom Blocks

Your existing knowledge of:

PHP
WordPress hooks
Filters
Template hierarchy
The Loop
Custom post types
REST APIs
Plugins
Security
Performance

doesn't become useless.

You're simply adding another layer to your WordPress toolkit.

My Perspective as a WordPress Developer

Most of my WordPress development experience has been with classic themes, so I'm not going to pretend that I've spent the majority of my career building block themes.

I haven't.

But that's exactly why I found the evolution interesting.

When you've been working with WordPress for years, it's easy to keep using the architecture you're comfortable with.

And there is nothing wrong with that when the architecture is appropriate.

But WordPress is clearly investing heavily in the block-based direction.

The official Theme Handbook now describes block themes as the modern method of building themes and focuses its current guidance heavily on that approach.

For me, that doesn't mean:

"Classic themes are dead."

It means:

"As WordPress developers, we should understand where the platform is going, even if our current projects still use the architecture we're most experienced with."

That's the approach I'm taking.

I'm not replacing my classic-theme knowledge.

I'm expanding it.

So, Should You Switch?

My answer is:

It depends.

If you're maintaining an existing classic WordPress website that works well, I wouldn't migrate it simply because block themes are newer.

If you're starting a new project, I'd at least evaluate whether a block theme makes sense.

And if you're a WordPress developer who has mostly worked with classic themes, I'd definitely recommend learning:

Block Editor
theme.json
Patterns
Template Parts
Site Editor
Block Themes
Custom Blocks

You don't need to become a block-theme expert overnight.

But understanding the architecture will make it much easier to work with modern WordPress projects.

Final Thoughts

WordPress theme development isn't necessarily a choice between:

Classic = Old
Block = New

It's more nuanced than that.

Classic themes remain powerful and relevant.

Block themes provide a newer approach that gives WordPress users much greater control over templates and site-wide design through blocks and the Site Editor.

And theme.json provides an interesting bridge between the two worlds because it can be used with both classic and block themes.

For developers who have spent years working with classic themes, the goal shouldn't be to forget everything we already know.

The goal is to understand the new architecture well enough to decide when it actually makes sense to use it.

That's where I currently see the value in learning block themes.

Not because classic themes have suddenly become irrelevant—but because WordPress itself is evolving, and we should evolve with it.

Official WordPress References

This article is based primarily on the official WordPress Developer Documentation:

WordPress Theme Developer Handbook
https://developer.wordpress.org/themes/
What Is a Theme?
https://developer.wordpress.org/themes/getting-started/what-is-a-theme/
Block Editor — Themes
https://developer.wordpress.org/block-editor/how-to-guides/themes/
Introduction to theme.json
https://developer.wordpress.org/themes/global-settings-and-styles/introduction-to-theme-json/
theme.json Version 3 Reference
https://developer.wordpress.org/block-editor/reference-guides/theme-json-reference/theme-json-living/
Developing with theme.json
https://developer.wordpress.org/block-editor/how-to-guides/themes/global-settings-and-styles/
Classic Themes
https://developer.wordpress.org/themes/classic-themes/

What's New in WordPress 7.0: Key Features and Improvements

Muhammad Medhat — Wed, 08 Jul 2026 15:01:52 +0000

WordPress 7.0, codenamed "Armstrong," was officially released on May 20, 2026. This release focuses on improving publishing workflows, enhancing the editing experience, expanding AI infrastructure, and providing new tools for developers while maintaining WordPress's commitment to performance, accessibility, and extensibility.

AI Infrastructure in WordPress Core

One of the biggest additions in WordPress 7.0 is the introduction of foundational AI infrastructure. Rather than providing a built-in AI writing assistant, WordPress now includes a standardized AI Client and connector framework that allows plugins and services to integrate AI capabilities in a consistent way. This approach gives developers a common foundation for building AI-powered features without tying WordPress to a specific AI provider.

Improved Publishing Workflows

WordPress 7.0 introduces several workflow enhancements that make creating and managing content more efficient. The release streamlines common editorial tasks and improves the overall publishing experience, helping content creators spend less time navigating the interface and more time producing content.

Enhanced Block Editor

The Block Editor receives a variety of improvements aimed at making page building faster and more intuitive. Users benefit from a smoother editing experience, while new capabilities provide greater flexibility when designing pages and managing content layouts. These refinements continue WordPress's evolution toward a fully visual site-building experience.

Better Tools for Developers

WordPress 7.0 includes numerous updates for plugin and theme developers. The release introduces new APIs and infrastructure that simplify extending WordPress while maintaining compatibility with existing development practices. The accompanying Field Guide outlines developer-focused enhancements and any important breaking changes developers should review before upgrading.

Performance, Accessibility, and Stability

As with every major release, WordPress 7.0 includes performance optimizations, accessibility improvements, bug fixes, and security updates. These enhancements improve the overall user experience for both site visitors and administrators while ensuring WordPress remains reliable and maintainable.

Why Upgrade to WordPress 7.0?

Upgrading to WordPress 7.0 offers several benefits:

Modern AI integration infrastructure for plugins and services.
Improved publishing and editing workflows.
Enhanced Block Editor experience.
New developer APIs and extensibility improvements.
Better performance, accessibility, and stability.
Ongoing security and maintenance updates.

Conclusion

WordPress 7.0 represents an important step forward for the platform by modernizing content creation workflows and laying the foundation for future AI-powered functionality. While many improvements are focused on infrastructure and developer experience, site owners and content creators also benefit from a smoother editing interface, improved performance, and a more efficient publishing process. Before upgrading, it's recommended to back up your website and verify that your themes and plugins are compatible with WordPress 7.0.

Container Queries: The CSS Feature I Wish I Had Years Ago

Muhammad Medhat — Sun, 14 Jun 2026 15:02:41 +0000

Introduction

For years, responsive design meant one thing:

@media (max-width: 768px) {
    ...
}

Media queries work great when you want to adapt a layout based on the viewport size.

But what if a component lives inside a narrow sidebar on a large screen?

Or inside a wide content area on a tablet?

That's where Container Queries shine.

The Problem With Media Queries

Imagine a card component:

<div class="card">
    ...
</div>

You want the card to switch layouts when it becomes too narrow.

With media queries, you're forced to react to the viewport:

@media (max-width: 768px) {
    .card {
        flex-direction: column;
    }
}

The problem?

The viewport may be large while the card's container is small.

The component doesn't actually know how much space it has available.

Enter Container Queries

Container Queries allow a component to respond to the size of its parent container rather than the viewport.

First, define a container:

.cards-wrapper {
    container-type: inline-size;
}

Then create queries based on that container:

@container (max-width: 500px) {
    .card {
        flex-direction: column;
    }
}

Now the card adapts based on the space it actually has.

A Real Example

Imagine a product card:

<div class="products">
    <article class="product-card">
        <img src="product.jpg" alt="">
        <div class="content">
            <h3>Product Name</h3>
            <p>Description</p>
        </div>
    </article>
</div>

Default layout:

.product-card {
    display: flex;
    gap: 1rem;
}

Make the parent a container:

.products {
    container-type: inline-size;
}

Change layout when space becomes limited:

@container (max-width: 450px) {
    .product-card {
        flex-direction: column;
    }
}

The card becomes fully reusable regardless of where it's placed.

When I Use Container Queries

I find them most useful for reusable components like:

Product cards
Team member cards
Dashboard widgets
Pricing tables
Sidebar blocks
Custom WordPress blocks

Instead of designing around the page, you design around the component itself.

Container Queries vs Media Queries

Use Media Queries when:

Adjusting page layouts
Changing navigation behavior
Responding to viewport size

Use Container Queries when:

Building reusable components
Creating modular UI systems
Designing components that appear in different layouts

I don't see them as competitors.

They solve different problems and often work together.

Browser Support

Container Queries are now supported in all modern browsers, making them practical for production projects.

Always verify support requirements if you're targeting older browsers, but for most modern projects they're ready to use.

Final Thoughts

Container Queries changed the way I think about responsive design.

Instead of asking:

"How wide is the screen?"

I can ask:

"How much space does this component actually have?"

That small shift makes components more reusable, predictable, and easier to maintain.

If you're still relying only on media queries, Container Queries are definitely worth adding to your CSS toolbox.

🧠 AI Tools That Actually Help Developers (And How I Use Them Daily)

Muhammad Medhat — Mon, 06 Apr 2026 16:28:42 +0000

There’s no shortage of AI tools right now.

Every week, a new tool promises to:

Replace developers
Build full apps in seconds
10x your productivity

But if you’re actually working on real projects, you already know the truth:

Most of these tools don’t fit into your daily workflow.

So instead of another “Top 7 AI Tools” list, this is something more practical:

👉 The AI tools I actually use as a developer
👉 And how they fit into real work — especially in WordPress projects

🚀 ChatGPT — My Daily Development Assistant

Out of all the tools, this is the one I use the most.

Not because it’s magical —
But because it saves time where it actually matters.

How I use it daily:

Debugging WordPress issues
Writing and fixing PHP functions
Understanding hooks and filters faster
Refactoring messy code
Generating starting points instead of searching for hours

Instead of:

Opening 5 tabs, reading random answers, testing blindly…

I describe the problem clearly and iterate.

🔧 Real Example from My Workflow

Let’s say I need:

A custom WooCommerce function to modify checkout fields

Before:

Search
Read documentation
Try multiple snippets
Debug manually

Now:

I ask ChatGPT
Get a working draft
Adjust it based on my project

👉 What used to take an hour can take minutes

🎥 See It in Action

If you want to see how I actually use ChatGPT during real development work, I made a full video where I walk through practical examples step by step:

👉

This isn’t a “look what AI can do” demo —
It’s how I use it inside real projects.

⚙️ AI Inside the Tools You Already Use

One thing many developers miss:

AI isn’t just standalone tools anymore —
It’s built into the tools you already use.

For example:

GitHub Copilot → speeds up repetitive coding
IDE AI assistants → smarter suggestions
Canva AI → quick visuals for content or clients

These aren’t revolutionary on their own —
But they remove friction.

👉 And removing friction is what actually improves your workflow

🧩 AI for Learning (Faster Than Documentation Alone)

AI changed how I learn new things.

Before:

Long documentation
Multiple tutorials
Slow trial and error

Now:

I ask specific questions
Get simplified explanations
Request real examples

Example:

“Explain WordPress hooks with a real use case”

👉 You go from confusion to clarity much faster

But this leads to something important…

📄 Documentation Still Matters (More Than Ever)

There’s a common misconception:

“AI replaces documentation”

It doesn’t.

In my workflow, documentation is still essential —
Sometimes even more than before.

🔍 Why I Still Check Documentation

Even when I use ChatGPT, I don’t blindly trust the output.

If I’m working with:

WordPress hooks
WooCommerce customization
APIs or integrations

I always go back to documentation to confirm:

Are the hooks correct?
Is this the recommended approach?
Is there a better or more optimized way?

👉 Because AI can give you something that works
But not always something that’s correct

⚠️ What AI Gets Wrong

From real experience, AI can:

Suggest outdated functions
Miss small but critical details
Ignore performance considerations
Provide solutions that don’t scale

And if you skip documentation,
you won’t even notice.

🧠 My Real Workflow (AI + Documentation)

This is how I actually work:

Use AI → to get direction or a draft
Review → based on my experience
Check documentation → verify accuracy
Improve → based on project needs

👉 AI gives speed
👉 Documentation gives certainty

You need both.

🛠️ AI for Repetitive Work

Where AI really shines isn’t complex architecture.

It’s repetitive work:

Writing similar functions
Generating variations of code
Formatting data
Creating dummy content

👉 It removes the work you don’t want to do anyway
So you can focus on what actually matters

⚠️ What AI Still Can’t Do

AI is powerful — but it’s not reliable on its own.

It doesn’t:

Understand your full project context
Make architectural decisions
Guarantee best practices

That’s why:

AI doesn’t replace developers — it amplifies them

If you understand the fundamentals,
AI makes you faster and more effective.

If not?

It just makes mistakes faster.

🔥 The Real Advantage

The developers getting real value from AI aren’t:

The ones trying every new tool
Or chasing trends

They’re the ones who:

Integrate AI into their workflow
Ask better questions
Verify and refine the output

🧠 Final Thought

AI tools are everywhere.

But the goal isn’t to use more tools.

It’s to work smarter with the right ones.

For me, that starts with ChatGPT —
supported by experience, and grounded in documentation.

👉 Want to See more AI Tools?

🎥 Check out my youtube channel:

Clarity AI Studio - YouTube

Welcome to Clarity AI Studio — where artificial intelligence is made clear, practical, and easy to use. This channel is dedicated to breaking down complex AI tools into simple, step-by-step tutorials anyone can follow. Whether you're a student, professional, entrepreneur, or small business owner, you'll learn how to use AI to save time, boost productivity, and work smarter. We cover: • AI tools explained simply • Step-by-step tutorials • Productivity and automation workflows • AI for small businesses and creators • Practical use cases you can apply immediately No hype. No complicated jargon. Just clear explanations and real-world applications. Understand AI. Use AI. Stay ahead.

youtube.com

AI Didn’t Replace Web Developers — It Made Good Ones Stronger

Muhammad Medhat — Tue, 10 Mar 2026 22:37:56 +0000

When AI coding tools started becoming popular, a lot of predictions appeared online:

“AI will replace developers.”

But after actually using these tools in real development work, something else became clear.

AI didn’t replace web developers.

Instead, it helped many developers become more productive, faster, and sometimes even better at solving problems.

The real difference isn’t whether developers use AI.
It’s how they use it.

AI Works Best With Developers, Not Instead of Them

AI can generate code, explain concepts, and suggest solutions.

But it still depends on the developer to:

understand the system
review the generated code
integrate it into a real project
debug issues when things go wrong

In practice, AI works best as a development assistant, not a replacement.

The developers who benefit the most are the ones who already understand what they’re building.

Real Examples From My WordPress Workflow

In my daily WordPress development work, AI has become a useful assistant in several situations.

Not as a replacement — but as something that removes friction from repetitive or time-consuming tasks.

Here are a few practical examples.

1. Debugging Hook Timing Issues

Sometimes a WordPress hook doesn’t fire the way you expect.

For example, a callback attached to init might run too early or too late depending on what the code needs.

Instead of manually searching documentation or browsing multiple threads, I can quickly ask AI something like:

“Why might a WordPress hook not fire as expected?”

It usually suggests things like:

checking hook priority
verifying execution order
confirming the hook exists in the current request
making sure the code runs after plugins load

It doesn’t fix the problem automatically, but it often points me in the right direction faster.

2. Generating Plugin Boilerplate

When starting a new feature or plugin, there is always repetitive setup work.

For example:

plugin headers
basic structure
registering hooks
creating activation functions

Instead of starting from an empty file every time, AI can generate a simple starting point.

For example:

a basic plugin structure
a small admin settings page
registering actions and filters

The generated code is rarely perfect, but it removes the blank-page problem and speeds up the first steps.

3. Understanding Old or Unfamiliar Code

WordPress developers often work with older projects or code written by other developers.

Sometimes you encounter:

very long functions
complex filters
unusual logic
legacy code

AI can help summarize what a piece of code is doing before you dive deeper.

For example, asking:

“What does this function do?”

This doesn’t replace reading the code, but it helps understand the context faster, especially in large codebases.

4. Exploring Alternative Implementations

Sometimes a solution works, but you still want to check if there’s a cleaner or more efficient approach.

For example:

alternative ways to structure a WordPress plugin
different ways to filter a query
optimizing loops or database queries

AI can generate alternative ideas quickly.

The developer still decides what to keep, but it helps explore options faster.

5. Testing Small Ideas Quickly

For quick experiments, I often test ideas using WP-CLI.
you can read articles about Simple WP-CLI Commands for more info

For example, triggering hooks directly:

wp eval 'do_action("my_plugin_custom_hook");'

AI can help quickly draft small snippets for things like:

temporary debugging code
logging hooks
small PHP checks

This makes it easier to experiment without interrupting the development flow.

The Real Skill That Matters

AI becomes most useful when developers already understand:

programming fundamentals
debugging
system architecture
performance considerations

Without those skills, AI-generated code can be confusing or even harmful.

But with strong fundamentals, AI becomes a force multiplier.

It removes repetitive work and allows developers to focus more on solving real problems.

How AI Is Actually Changing Development

AI is definitely changing the development workflow.

Tasks that once required long searches through documentation can now happen much faster:

generating boilerplate code
explaining unfamiliar syntax
suggesting debugging steps
exploring implementation ideas

But the developer still remains responsible for:

understanding the problem
making technical decisions
reviewing generated code
maintaining the system long-term

AI speeds up development — it doesn’t replace the thinking behind it.

Final Thoughts

AI didn’t eliminate the need for web developers.

Instead, it became another powerful tool in the development toolbox.

Developers who learn how to use it effectively can:

work faster
experiment more
reduce repetitive tasks
focus more on real problem solving

In the end, AI doesn’t replace developers.

It helps the ones who adapt become stronger and more productive.

Understanding WordPress Execution Order (Who Runs First and Why Your Code Fails Sometimes)

Muhammad Medhat — Wed, 11 Feb 2026 22:23:19 +0000

A lot of WordPress “bugs” are not really bugs.

They’re this:

“My code is fine, but it’s running at the wrong time.”

If you understand when WordPress loads plugins, themes, and hooks, you can avoid a huge class of problems: things not showing, filters not firing, or options not being available yet.

This article walks through execution order in a practical way, with real hooks and examples.

1. The Big Picture: What Loads First?

When a page loads in WordPress, this is (roughly) what happens:

WordPress core boots up
Must-use plugins (mu-plugins) load
Regular plugins load
The current theme loads
Important core hooks fire (like init, wp_loaded, etc.)
The template is chosen and rendered

You don’t need to memorize every internal step, but you do need one key idea:

If your code depends on something, make sure it runs after that thing is loaded.

2. Key Hooks in the Early Lifecycle

Let’s look at a few hooks you’ll see all the time, and what they’re good for.

`plugins_loaded`

add_action( 'plugins_loaded', function() {
    // Check if other plugins are active
});

When it fires:
After all active plugins have been loaded.

Use it when:

Your plugin depends on another plugin (e.g. WooCommerce, ACF)
You want to check if a plugin is active before using its functions
You’re writing compatibility code

Example:

add_action( 'plugins_loaded', function () {
    if ( class_exists( 'WooCommerce' ) ) {
        // Safe to run WooCommerce-related code
    }
});

`init`

add_action( 'init', function() {
    // Register CPTs, taxonomies, etc.
});

When it fires:
After WordPress is loaded, but before any headers are sent.

Use it when:

Registering Custom Post Types and taxonomies
Adding rewrite rules
Setting up things that must be ready early in the request

This is one of the most commonly used hooks in WordPress.

`wp_loaded`

add_action( 'wp_loaded', function() {
    // Code that needs everything initialized
});

When it fires:
After WordPress, plugins, and the theme have all been loaded.

Use it when:

init is too early for what you’re doing
You need everything available before your code runs

3. Theme-Specific Hooks

When you’re working on themes (or plugins that depend on theme behavior), these hooks matter a lot.

`after_setup_theme`

add_action( 'after_setup_theme', function() {
    add_theme_support( 'post-thumbnails' );
});

When it fires:
Right after the active theme is loaded.

Use it when:

Adding add_theme_support()
Registering nav menus
Doing high-level theme setup

`wp_enqueue_scripts`

add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_style( 'my-theme', get_stylesheet_uri() );
});

When it fires:
When WordPress is ready to enqueue scripts and styles for the frontend.

Use it when:

Enqueuing CSS and JS files for your theme or plugin

If your styles/scripts aren’t loading or are in the wrong place, check if you’re using this hook correctly.

4. Hook Priority: Same Hook, Different Order

Sometimes you hook into the same hook as someone else, but you still need to control who runs first.

That’s where priority comes in.

Default priority is 10:

add_action( 'init', 'my_function' );           // priority 10
add_action( 'init', 'my_other_function', 20 ); // priority 20

Lower = earlier. Higher = later.

Example:

add_action( 'init', function() {
    error_log( 'I run first' );
}, 5 );

add_action( 'init', function() {
    error_log( 'I run second' );
}, 15 );

When you care about priority:

You want to override something another plugin or theme did
You need to modify data after someone else touched it
You want to make sure your code doesn’t run too early

5. Common “Execution Order” Problems (and Why They Happen)

Let’s connect this to real-life issues you’ve probably seen.

Problem 1: “My Custom Post Type 404s”

You:

Register a CPT somewhere random (like at the bottom of functions.php)
Visit the CPT archive and get a 404

Likely cause:
CPT is not registered on init (or not on every request), so rewrite rules and queries don’t know about it.

Fix:

add_action( 'init', 'register_books_cpt' );

Problem 2: “I’m Getting ‘Call to undefined function’ From Another Plugin”

You:

Call a function from WooCommerce or another plugin
Code runs too early
Function doesn’t exist yet

Likely cause:
You are running before plugins_loaded.

Fix:

add_action( 'plugins_loaded', 'my_plugin_compat' );

Problem 3: “My Script Isn’t Loading Where I Expect”

You:

wp_enqueue_script() directly in functions.php
It loads in weird places, or not at all

Likely cause:
Scripts are not enqueued on wp_enqueue_scripts.

Fix:

add_action( 'wp_enqueue_scripts', 'my_theme_assets' );

6. A Simple Mental Model

You don’t need to memorize every hook, but this mental model helps:

Core boots
↓
Plugins load      (plugins_loaded)
↓
Theme loads       (after_setup_theme)
↓
WordPress “ready” (init, wp_loaded)
↓
Assets phase      (wp_enqueue_scripts)
↓
Template chosen   (template_redirect, etc.)
↓
Page output

Ask yourself:

“At this point in the timeline, does what I need already exist?”

If not, you’re probably on the wrong hook.

7. Quick Debugging Techniques

When something doesn’t work, instead of only checking your logic, check your timing.

A few easy tricks:

1) Log when a hook fires

add_action( 'init', function() {
    error_log( 'init fired' );
});

Check wp-content/debug.log to confirm.

2) Temporarily change hooks

Try moving your code:

from init → wp_loaded
from constructor → init
from random place → plugins_loaded

If it starts working, your problem was timing, not code.

3) Dump the call stack (for deeper debugging)

If you’re more advanced, tools like Xdebug or debug_backtrace() help you see how you got to a certain hook.

8. Final Thoughts

Understanding when WordPress runs your code is one of those skills that:

prevents subtle bugs
makes debugging less painful
helps you work better with other plugins and themes

After a while, you’ll stop thinking “WordPress is weird” and start thinking:

“Ah, my code is just running too early / too late.”

That’s a much easier problem to fix.

Simple WP-CLI Commands That Make WordPress Easier

Muhammad Medhat — Sat, 17 Jan 2026 16:44:03 +0000

WP-CLI isn’t just for advanced developers.
Even for basic WordPress tasks, it can save time and reduce a lot of clicking around in the dashboard.

If you already know what WP-CLI is and how to install it, here are simple, everyday commands I use to manage WordPress sites faster.

1) Check Basic Site Info (First Thing I Run)

wp option get siteurl
wp option get home
wp core version
wp user list --fields=ID,user_login,roles
wp theme list --status=active

When to use it:
Right after connecting to a server, or before doing any changes.

Why:
This gives you a quick picture of the site without opening wp-admin:

Which site URL you’re on

Which WordPress version is running

Who the users are (and their roles)

Which theme is active

It’s an easy way to make sure you’re in the right place and understand the setup before touching anything.

2) See Active Plugins

wp plugin list --status=active

When to use it:
When a site is slow or acting weird and you want to know what’s running.

Why:
Much faster than opening the Plugins page in wp-admin.

3) Disable or Enable a Plugin

wp plugin deactivate plugin-slug
wp plugin activate plugin-slug

When to use it:
A plugin causes errors, white screens, or conflicts.

Why:
You can fix problems even if wp-admin is broken.

4) Update WordPress Core

wp core update

When to use it:
WordPress shows an update notification.

Why:
It’s quick, reliable, and avoids browser timeouts.

5) Update Plugins and Themes

wp plugin update --all
wp theme update --all

When to use it:
Doing regular maintenance or security updates.

Why:
One command replaces many clicks.

6) Fix Permalink Problems

wp rewrite flush --hard

When to use it:
Pages suddenly show 404 errors after changes.

Why:
Same as re-saving permalinks in settings, just faster.

7) Clear Cached Data

wp transient delete --all
wp cache flush

When to use it:
You changed something but the site still shows old data.

Why:
Clears temporary stored values that cause confusion.

8) Enable Maintenance Mode

wp maintenance-mode activate

Disable it when finished:

wp maintenance-mode deactivate

When to use it:
Making quick updates or small migrations.

Why:
Stops visitors from seeing half-finished changes.

9) Create a New User

wp user create editor1 editor@example.com --role=editor --user_pass='Password123'

When to use it:
You need to add a user quickly.

Why:
No forms, no waiting for email confirmations.

10) Reset a User Password

wp user update editor1 --user_pass='NewPassword123'

When to use it:
Someone can’t log in and email isn’t working.

Why:
Instant fix without touching wp-admin.

11) List Pages or Posts

wp post list --post_type=page

When to use it:
You want a quick overview of site content.

Why:
Faster than browsing multiple admin screens.

12) List Media Files (Attachments)

Media files in WordPress are stored as attachments, so you list them like this:

wp post list --post_type=attachment --fields=ID,post_title,guid --format=table

When to use it:
After a migration or when uploads look wrong.

Why:
Gives you a clear list of media without opening the Media Library.

Important Note About `wp media`

You can’t use wp media list to list uploads.
That command does not exist in core WP-CLI.

👉 To list media → use attachments with wp post.

However, wp media is still very useful for managing media files.

Useful `wp media` Subcommands

Fix image rotation

  wp media fix-orientation

When: Images look rotated after upload
Why: Automatically fixes orientation metadata

See registered image sizes

  wp media image-size

When: You want to know which image sizes WordPress uses
Why: Helpful when working with themes or performance

Import media files

  wp media import image.jpg

When: Uploading files in bulk or migrating content
Why: Faster than uploading through the browser

Regenerate thumbnails

  wp media regenerate

When: After changing image sizes or switching themes
Why: Ensures images match the new settings

Easy way to remember:

List media → wp post (attachments)
Manage media → wp media

13) Quick Search & Replace (Safe Way)

wp search-replace 'http://oldsite.com' 'https://newsite.com' --dry-run

When to use it:
After moving a site or changing domains.

Why:
Safely updates links without breaking data.
Always run with --dry-run first.

14) Check WordPress Core Files

wp core verify-checksums

When to use it:
Something feels broken or suspicious.

Why:
Confirms WordPress core files are clean and unchanged.

15) Run a Small One-Time Check

wp eval 'echo get_bloginfo("name");'

When to use it:
You just want to check or tweak something quickly.

Why:
Lets you use WordPress functions without editing files.

A Small Note on Custom Post Types

I often use WP-CLI for Custom Post Types too, mainly to keep things fast and consistent. I’ll cover that workflow in a separate article.

Final Thoughts

WP-CLI isn’t only for advanced developers.
Even simple tasks—updates, users, plugins, media—are easier once you get used to it.

If you already know WordPress, WP-CLI is just another tool that makes daily work smoother and less annoying.

Please check this article Getting Started with WP-CLI

The Classic WordPress Template Hierarchy — The Map Behind Every Theme

Muhammad Medhat — Sun, 26 Oct 2025 12:32:34 +0000

The Classic WordPress Template Hierarchy — Explained Like a Map

When you open a page on a WordPress site, you might think the system just “loads the right file.”
But behind the scenes, something much more elegant happens — a logical treasure hunt called the Template Hierarchy.

This hierarchy is the backbone of every classic (PHP-based) WordPress theme. It determines which template file WordPress will use to display a certain type of content — from a blog post to a category archive, to that friendly (or not so friendly) 404 page.

Let’s take a walk through that map — step by step — and see how WordPress decides what to load.

What Is the Template Hierarchy?

When a visitor requests a page, WordPress does three things:

Queries the database to determine what’s being requested (a post, a category, a page, etc.).
Builds a prioritized list of possible template files based on that type of request.
Loads the first template file that exists in your active theme directory.

If nothing more specific is found, WordPress gracefully falls back to the ultimate safety net: index.php.

Think of it as WordPress saying:

“Do we have something specific for this? No? Okay, something more general? Still no? Alright then, use index.php and show something!”

That’s the beauty of the system — it never breaks, it just gets simpler.

1. Front Page and Home

Your homepage behavior depends on what you’ve set in Settings → Reading:

If “Your latest posts” is selected:

home.php
index.php

If “A static page” is selected:

front-page.php
If a page is assigned as “Posts Page”: home.php
Fallback: index.php

In short:

front-page.php → Always highest priority for the site front page.
home.php → The blog posts listing.
index.php → The safety net.

📘 Reference – Front Page Display

2. Single Posts and Custom Post Types

Whenever you open a single post, WordPress looks for templates in this order:

single-{post_type}-{slug}.php
single-{post_type}.php
single.php
singular.php
index.php

Example:
If you have a custom post type called movie and the post slug is inception, WordPress will try:

single-movie-inception.php
→ single-movie.php
→ single.php
→ singular.php
→ index.php

📘 Reference – Single Post Templates

3. Pages (Static Pages)

Pages have their own neat system because they can use custom templates.

Order of lookup:

Template selected in the Page Editor (Template Name: in file header)
page-{slug}.php
page-{id}.php
page.php
singular.php
index.php

Example: for a page titled About Us, with slug about, the chain might look like:

page-about.php
→ page-42.php
→ page.php
→ singular.php
→ index.php

📘 Reference – Page Templates

4. Archives: Categories, Tags, Custom Taxonomies

Category Archive

When browsing a category archive (like /category/news):

category-{slug}.php
category-{id}.php
category.php
archive.php
index.php

Tag Archive

For tags, it’s similar:

tag-{slug}.php
tag-{id}.php
tag.php
archive.php
index.php

Custom Taxonomies

If you’ve registered a custom taxonomy (say genre for books):

taxonomy-{taxonomy}-{term}.php
taxonomy-{taxonomy}.php
taxonomy.php
archive.php
index.php

📘 Reference – Category, Tag & Taxonomy Templates

5. Author, Date, and Other Archives

Author Archives

author-{nicename}.php
→ author-{id}.php
→ author.php
→ archive.php
→ index.php

Date Archives

date.php
→ archive.php
→ index.php

Other archives (post type archives, search results, etc.) follow a similar pattern.

📘 Reference – Author and Date Archives

6. Search and 404 Templates

Search Results

search.php
→ index.php

404 (Not Found)

404.php
→ index.php

A well-designed 404.php can turn a dead-end into a friendly nudge — or even a chance to show helpful links or your site map.

📘 Reference – Special Templates

7. Attachments and Comments

Attachments (media items)
- attachment-{mime_type}.php
- attachment.php
- single-attachment.php
- single.php
- index.php
Comments Template
- comments.php is included inside your templates via comments_template().

📘 Reference – Attachments

8. Child Themes and Overrides

When using a child theme, the lookup happens twice — once in the child, then in the parent:

WordPress first checks the child theme for the requested file.
If it doesn’t exist there, it falls back to the parent theme.

Example:

/wp-content/themes/my-child-theme/single.php
→ /wp-content/themes/my-parent-theme/single.php
→ index.php

That’s why child themes are the perfect way to modify templates safely — without breaking or overwriting parent theme updates.

📘 Reference – Child Themes

9. Why This Hierarchy Is Brilliant

The hierarchy makes WordPress:

Predictable — You always know where to put your custom template.
Flexible — You can override only what you need.
Fail-safe — It always falls back to index.php.
Readable — Anyone who understands the hierarchy can quickly read a theme’s structure.

It’s like a well-thought-out decision tree that keeps WordPress adaptable without chaos.

Conclusion

The WordPress Template Hierarchy is not just a technical system — it’s design philosophy in code form.
It rewards organization, clarity, and foresight. Once you understand it, you gain full control over how every pixel of your site is displayed.

In the next article, we’ll explore how this hierarchy evolves in the Block Theme / Full Site Editing (FSE) era — and what remains timeless.

References

Common WordPress Mistakes New Developers Make and How to Avoid Them

Muhammad Medhat — Fri, 22 Aug 2025 14:47:12 +0000

WordPress is one of the most popular content management systems in the world, powering over 40% of websites. While it’s beginner-friendly, new developers often make mistakes that can cause performance issues, security vulnerabilities, or maintenance headaches down the road.

In this article, we’ll cover the most common mistakes beginners make in WordPress development — and how you can avoid them to build faster, safer, and more maintainable websites.

1. Ignoring WordPress Coding Standards

The mistake: Writing PHP, HTML, CSS, or JavaScript without following WordPress coding standards.

Why it matters:

Makes your code hard to read and maintain.
Other developers may struggle to understand your work.
Increases the risk of errors and bugs.

How to fix:
Follow the official WordPress Coding Standards. You can also integrate tools like PHPCS into your development workflow to automatically enforce them.

2. Not Using Version Control (like Git)

The mistake: Building entire websites without Git or any version control system.

Why it matters:

No backup of your changes.
Difficult to collaborate with a team.
Impossible to roll back safely if something breaks.

How to fix:
Learn Git basics and use platforms like GitHub, GitLab, or Bitbucket. Even if you’re working alone, version control will save you from countless headaches.

3. Hardcoding URLs and File Paths

The mistake: Writing URLs directly into your templates or functions (e.g., https://example.com/images/logo.png).

Why it matters:

Moving the site to another domain or staging environment becomes painful.
Breaks your site during migrations.

How to fix:
Always use WordPress functions like:

<?php echo get_template_directory_uri(); ?>
<?php echo home_url(); ?>

These functions keep your site flexible and migration-friendly.

4. Ignoring Security Best Practices

The mistake: Leaving the default “admin” username, weak passwords, or not updating plugins.

Why it matters:

WordPress sites are common targets for hackers.
Weak security can lead to malware, spam, or data theft.

How to fix:

Always change the default admin username.
Use strong passwords and two-factor authentication.
Keep themes, plugins, and WordPress core updated.
Use a reputable security plugin like Wordfence or Sucuri.

5. Forgetting to Optimize Performance

The mistake: Installing too many plugins, uploading uncompressed images, and ignoring caching.

Why it matters:

Slow websites drive visitors away.
Poor performance affects SEO rankings.

How to fix:

Minimize plugin usage — only keep what’s necessary.
Compress images using tools like TinyPNG or plugins like Smush.
Use caching plugins such as WP Rocket or LiteSpeed Cache.
Implement a CDN (Content Delivery Network) if possible.

6. Editing Core WordPress Files

The mistake: Modifying WordPress core files to change functionality.

Why it matters:

Your changes will be wiped out on updates.
Can break the site or introduce security holes.

How to fix:
Never edit WordPress core files. If you need to extend or modify functionality, use hooks (actions and filters) or custom plugins.

7. Poor Database Management

The mistake: Not cleaning up unused tables, revisions, or testing queries directly in the live database.

Why it matters:

Leads to bloated databases and slow queries.
Increases chances of breaking the site.

How to fix:

Regularly optimize your database using plugins like WP-Optimize.
Always back up your database before making changes.
For testing queries, use a local environment or staging site, not production.

8. Not Using a Child Theme

The mistake: Editing a parent theme’s files directly.

Why it matters:

All changes will be lost once the theme is updated.
Maintaining and debugging becomes very difficult.

How to fix:
Always create a child theme before making modifications. This way, you can safely update the parent theme while keeping your customizations intact. Here’s WordPress’s guide on child themes.

9. Skipping Regular Backups

The mistake: Relying on “hoping nothing breaks” instead of real backups.

Why it matters:

Sites can break during updates.
Hosting problems, hacks, or human mistakes can cause data loss.

How to fix:
Always schedule automatic backups. Use plugins like UpdraftPlus or rely on your hosting provider’s built-in backup solutions.

Final Advice: Choose Managed Hosting

One of the smartest moves for new developers is to use WordPress managed hosting. With managed hosting, you get built-in performance optimization, advanced security, and automatic backups.

Most providers also offer their own caching and backup plugins, which are usually better integrated and more reliable than third-party options. By using them, you avoid plugin conflicts and ensure your site stays secure and fast.

✅ By avoiding these mistakes, using child themes, and relying on managed hosting with built-in tools, you’ll save yourself countless hours of troubleshooting — and ensure your WordPress projects are professional, scalable, and easy to maintain.

How to Do AJAX in WordPress Correctly: A Complete Guide with jQuery and Vanilla JavaScript

Muhammad Medhat — Fri, 08 Aug 2025 12:54:17 +0000

How to Do AJAX in WordPress Correctly

AJAX (Asynchronous JavaScript and XML) is a technique for making background HTTP requests to the server without reloading the page. In WordPress, AJAX is often used to load data dynamically, process forms, or update content in real time. WordPress has a built-in AJAX handling system via admin-ajax.php that works both in the admin and the front-end — when set up correctly.

In this article, we’ll cover:

The basic flow of AJAX in WordPress.
Two approaches — jQuery and Vanilla JavaScript.
How to properly pass variables from PHP to JavaScript.
A quick comparison of both approaches.

1. How WordPress AJAX Works

A standard WordPress AJAX request involves:

JavaScript event triggers a request.
The request is sent to admin-ajax.php with an action parameter.
WordPress executes the matching PHP function via add_action().
The PHP function returns a response.
JavaScript receives the response and updates the DOM.

Official docs: [WordPress AJAX documentation][1].

2. Enqueueing Scripts and Localizing Variables

Whether you use jQuery or Vanilla JS, you first need to enqueue your script in functions.php:

function my_enqueue_scripts() {
    wp_enqueue_script(
        'my-ajax-script',
        get_template_directory_uri() . '/js/my-ajax.js',
        ['jquery'], // remove 'jquery' if using vanilla JS only
        null,
        true
    );

    wp_localize_script('my-ajax-script', 'ajax_object', [
        'ajax_url' => admin_url('admin-ajax.php')
    ]);
}
add_action('wp_enqueue_scripts', 'my_enqueue_scripts');

This wp_localize_script() call makes ajax_object.ajax_url available in your JavaScript file.

💡 Note on ajaxurl vs ajax_object.ajax_url
In the WordPress admin area, there is already a global JavaScript variable called ajaxurl that points to the AJAX handler:
console.log(ajaxurl);
// https://yoursite.com/wp-admin/admin-ajax.php
This variable is only available in the admin by default.
On the front-end, ajaxurl is not automatically defined, so you must pass it yourself.
The standard way to do this is by using wp_localize_script() in PHP:
wp_localize_script('my-ajax-script', 'ajax_object', [
    'ajax_url' => admin_url('admin-ajax.php')
]);
This creates a global object in JavaScript:
var ajax_object = {
    ajax_url: "https://yoursite.com/wp-admin/admin-ajax.php"
};
Summary:

Admin pages → You can use ajaxurl directly.

Front-end pages → Use a localized variable like ajax_object.ajax_url. Both point to the same endpoint, but their availability depends on context.

3. PHP AJAX Handler

Create the PHP function that will process the request:

function my_ajax_handler() {
    $name = sanitize_text_field($_POST['name']);
    wp_send_json_success("Hello, {$name}!");
}
add_action('wp_ajax_my_action', 'my_ajax_handler');
add_action('wp_ajax_nopriv_my_action', 'my_ajax_handler');

wp_ajax_my_action → for logged-in users.
wp_ajax_nopriv_my_action → for visitors not logged in.

4. jQuery AJAX Example

If your theme already includes jQuery, AJAX calls are quick to set up:

jQuery(document).ready(function($) {
    $('#myButton').click(function() {
        $.ajax({
            url: ajax_object.ajax_url,
            method: 'POST',
            data: {
                action: 'my_action',
                name: $('#nameInput').val()
            },
            success: function(response) {
                alert(response.data);
            }
        });
    });
});

Pros: Short syntax, good browser support, minimal setup if jQuery is present.

5. Vanilla JavaScript (Fetch API) Example

For modern projects, you can skip jQuery entirely and use the native fetch() API [2]:

document.getElementById('myButton').addEventListener('click', function() {
    const name = document.getElementById('nameInput').value;

    fetch(ajax_object.ajax_url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
        },
        body: new URLSearchParams({
            action: 'my_action',
            name: name
        })
    })
    .then(response => response.json())
    .then(data => {
        alert(data.data);
    })
    .catch(error => console.error('Error:', error));
});

Pros: No dependency on jQuery, smaller page size, modern syntax.

6. Comparison: jQuery vs Vanilla JavaScript

Feature / Factor	jQuery Method	Vanilla JS Method
Ease of Use	Very easy if jQuery is already loaded; simple syntax	Slightly more verbose; modern syntax but requires understanding of `fetch()`
Dependencies	Requires jQuery library (~90KB minified)	No dependencies — built into modern browsers
Browser Support	Excellent, including older browsers (IE9+)	Modern browsers only (IE not supported without polyfill)
Learning Curve	Low, especially for developers familiar with WordPress	Moderate — requires ES6+ knowledge
Performance	Slightly slower load times due to jQuery overhead	Faster initial load (no extra library)
Best For	Legacy projects, themes already using jQuery	Modern, lightweight projects; performance-focused builds
Example	`$.ajax({...})`	`fetch(url, {...})`

7. Conclusion

If your theme or plugin already uses jQuery, the jQuery method is fast to implement and compatible with older browsers.
For new, performance-focused builds, vanilla JavaScript with fetch() is the better choice — no extra library required, cleaner dependencies, and a future-proof approach.

References

WordPress Developer Resources. AJAX in Plugins. Available from: https://developer.wordpress.org/plugins/javascript/ajax/
Mozilla Developer Network. Fetch API. Available from: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Mozilla Developer Network. URLSearchParams. Available from: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams

⚡ Automating Repetitive Tasks Using VS Code Snippets

Muhammad Medhat — Mon, 04 Aug 2025 13:33:04 +0000

As developers, we write the same chunks of code again and again — whether it’s a React component, a PHP function, a JavaScript utility, or a WordPress loop. This repetition isn’t just tedious, it slows us down and increases the risk of human error.

VS Code snippets offer a powerful way to automate your repetitive tasks, allowing you to generate entire blocks of boilerplate code with just a few keystrokes.

In this article, you’ll learn:

What VS Code snippets are
How to create your own snippets
Useful snippet extensions
Real-world snippet examples for PHP, JS, and WordPress
Tips to improve your productivity using snippets

🧠 What Are VS Code Snippets?

Snippets in Visual Studio Code are templates that make it easier to enter repeating code patterns. When triggered, they auto-complete predefined blocks of code, allowing you to write less and do more.

They can include:

Placeholders ($1, $2, etc.)
Variables (like $TM_FILENAME)
Dynamic behavior (like cursor positioning or repetition)

⚙️ How to Create a Snippet in VS Code

Open the Command Palette: Ctrl+Shift+P
Choose: Preferences: Configure User Snippets
Select or create a language-specific or global snippet file

A sample PHP function snippet might look like:

"Simple PHP Function": {
  "prefix": "phpfn",
  "body": [
    "function ${1:functionName}(${2:$arg}) {",
    "    $3",
    "}"
  ],
  "description": "Basic PHP function"
}

Now, typing phpfn and pressing Tab will generate a complete PHP function.

📦 Popular VS Code Snippet Extensions

While writing custom snippets is great, sometimes you just want prebuilt ones. Here are some amazing snippet packs from the marketplace:

🔹 ES7+ React/Redux/React-Native snippets
🔹 JavaScript (ES6) Code Snippets
🔹 Simple React Snippets
🔹 jQuery Code Snippets
🔹 Laravel Blade Snippets
🔹 WordPress Snippets

You can find more on the VS Code Marketplace.

🔥 Real-World Snippet Examples

🟦 WordPress Loop Snippet

"WordPress Loop": {
  "prefix": "wploop",
  "body": [
    "if ( have_posts() ) :",
    "  while ( have_posts() ) : the_post();",
    "    ?>",
    "    <article id=\"post-<?php the_ID(); ?>\" <?php post_class(); ?>>",
    "      <h2><a href=\"<?php the_permalink(); ?>\"><?php the_title(); ?></a></h2>",
    "      <div class=\"entry-content\">",
    "        <?php the_excerpt(); ?>",
    "      </div>",
    "    </article>",
    "    <?php",
    "  endwhile;",
    "  the_posts_pagination();",
    "else :",
    "  echo '<p>No posts found.</p>';",
    "endif;"
  ],
  "description": "WordPress default loop with pagination"
}

🟨 JavaScript – Debounce Function

"Debounce Function": {
  "prefix": "debounce",
  "body": [
    "function debounce(fn, delay) {",
    "  let timeout;",
    "  return function(...args) {",
    "    clearTimeout(timeout);",
    "    timeout = setTimeout(() => fn.apply(this, args), delay);",
    "  };",
    "}"
  ],
  "description": "Debounce a function to limit calls"
}

🟪 PHP – Custom Post Type in WordPress

"Register CPT": {
  "prefix": "regcpt",
  "body": [
    "function ${1:register_book_post_type}() {",
    "  register_post_type( '${2:book}', array(",
    "    'labels' => array(",
    "      'name' => __( '${3:Books}' ),",
    "      'singular_name' => __( '${4:Book}' )",
    "    ),",
    "    'public' => true,",
    "    'rewrite' => array( 'slug' => '${5:books}' ),",
    "    'show_in_rest' => true,",
    "    'supports' => array( 'title', 'editor', 'thumbnail' )",
    "  ));",
    "}",
    "add_action( 'init', '${1:register_book_post_type}' );"
  ],
  "description": "Register a custom post type"
}

💡 Tips for Power Users

Use $TM_FILENAME_BASE to insert the current file’s name
Store common snippets in global snippets file (global.code-snippets)
Export/import your snippets using Settings Sync
Assign custom prefixes for each stack you work on: wp_, js_, php_, etc.

🎯 Final Thoughts

Using snippets in VS Code is one of the simplest yet most powerful ways to increase productivity, reduce errors, and standardize your code. Whether you're writing complex WordPress plugins, modern JavaScript apps, or backend PHP logic — snippets can save you hours every week.

So stop writing the same thing over and over. Automate it!

DEV Community: Muhammad Medhat

WordPress Block Themes vs Classic Themes: Should You Switch in 2026?

Classic Themes vs Block Themes

What I'm Used to: Classic Themes

So What Is a Block Theme?

The Big Difference: Who Controls the Layout?

Where Does theme.json Fit?

A Simple theme.json

version

$schema

Why Is theme.json Important?

Classic Themes Can Use Modern WordPress Features Too

Template Parts: PHP vs Blocks

Does a Block Theme Mean No PHP?

When Would I Still Choose a Classic Theme?

1. The existing architecture works

2. The project relies heavily on custom PHP templates

3. The team knows the classic architecture well

4. The client doesn't need full Site Editor control

When Would I Consider a Block Theme?

The client wants visual control

The website is heavily block-based

You want a centralized design system

You're building a new theme from scratch

What About Performance?

What Should a Classic-Theme Developer Learn?

My Perspective as a WordPress Developer

So, Should You Switch?

Final Thoughts

Official WordPress References

WordPress Block Themes vs Classic Themes: Should You Switch in 2026?

Classic Themes vs Block Themes

What I'm Used to: Classic Themes

So What Is a Block Theme?

The Big Difference: Who Controls the Layout?

Where Does theme.json Fit?

A Simple theme.json

version

$schema

Why Is theme.json Important?

Classic Themes Can Use Modern WordPress Features Too

Template Parts: PHP vs Blocks

Does a Block Theme Mean No PHP?

When Would I Still Choose a Classic Theme?

1. The existing architecture works

2. The project relies heavily on custom PHP templates

3. The team knows the classic architecture well

4. The client doesn't need full Site Editor control

When Would I Consider a Block Theme?

The client wants visual control

The website is heavily block-based

You want a centralized design system

You're building a new theme from scratch

What About Performance?

What Should a Classic-Theme Developer Learn?

My Perspective as a WordPress Developer

So, Should You Switch?

Final Thoughts

Official WordPress References

What's New in WordPress 7.0: Key Features and Improvements

AI Infrastructure in WordPress Core

Improved Publishing Workflows

Enhanced Block Editor

Better Tools for Developers

Performance, Accessibility, and Stability

Why Upgrade to WordPress 7.0?

Conclusion

Container Queries: The CSS Feature I Wish I Had Years Ago

Introduction

The Problem With Media Queries

Enter Container Queries

A Real Example

When I Use Container Queries

Container Queries vs Media Queries

Browser Support

Final Thoughts

🧠 AI Tools That Actually Help Developers (And How I Use Them Daily)

🚀 ChatGPT — My Daily Development Assistant

How I use it daily:

🔧 Real Example from My Workflow

Where Does `theme.json` Fit?

A Simple `theme.json`

`version`

`$schema`

Why Is `theme.json` Important?

Where Does `theme.json` Fit?

A Simple `theme.json`

`version`

`$schema`

Why Is `theme.json` Important?

`plugins_loaded`

`init`

`wp_loaded`

`after_setup_theme`

`wp_enqueue_scripts`

Important Note About `wp media`

Useful `wp media` Subcommands