WordPress Comments in Classic vs. Block Themes

WordPress comments work with both classic themes and block themes, but the theme architecture used to display them is significantly different.

In a classic theme, the typical comment flow is based on PHP template files and functions such as:

comments_template()
comments.php
wp_list_comments()
comment_form()

In a block theme, the visible comment section is instead assembled from WordPress blocks inside the site’s templates.

A simplified comparison looks like this:

CLASSIC THEME

single.php
↓
comments_template()
↓
comments.php
↓
PHP functions render comments


BLOCK THEME

single.html
↓
Comments block
↓
Comment Template
Comments Pagination
Post Comments Form
↓
dynamic blocks render comments

The underlying WordPress comment data is still the same system.

Posts can still have:

• open or closed comments;
• approved comments;
• pending comments;
• threaded replies;
• pagination;
• moderation rules.

What changes is primarily how the active theme represents that data on the frontend and how developers or site administrators customize the presentation.

This guide explains how comments work in classic and block themes, where their templates live, how comment forms and threaded replies are rendered, what happens when comments are disabled and what to check when migrating between the two theme architectures.

Classic themes and block themes use different template systems

The official WordPress Theme Handbook distinguishes between the two major architectures.

A classic theme is primarily built with:

• PHP template files;
• CSS;
• JavaScript;
• template tags;
• hooks and filters.

A block theme is built primarily with:

• block templates;
• HTML template files containing block markup;
• the Site Editor;
• theme.json;
• dynamic WordPress blocks.

The official WordPress block themes documentation explains that block themes use blocks throughout the site, including areas that classic themes traditionally control through PHP templates.

The underlying comment system does not change

Switching from a classic theme to a block theme does not inherently convert your comments into a new data format.

The comments themselves continue to belong to WordPress’s normal comment system.

Conceptually:

wp_comments
+
wp_commentmeta
+
post comment_status
+
WordPress comment APIs

remain relevant regardless of whether the active theme is classic or block-based.

The theme controls presentation, not the existence of comment records

This distinction matters when changing themes.

A theme can stop displaying comments without deleting them.

For example:

database
→ 73 approved comments

classic theme
→ displays them

new block theme template
→ contains no Comments block

frontend
→ comments disappear visually

database
→ 73 comments still exist

This is the same general distinction discussed in What Happens to Old Comments When You Disable Them: stored comment data and frontend presentation are separate layers.

How comments work in a classic WordPress theme

Classic themes commonly render comments through:

comments_template()

The official comments_template() documentation states that the function loads the specified comment template and queries comments associated with the current post.

A classic single-post template might contain

<?php

if (
    comments_open()
    ||
    get_comments_number()
) {
    comments_template();
}

This means:

comments open
OR
existing comments exist
↓
load comment template

The default classic comment template is comments.php

The WordPress Theme Handbook identifies:

comments.php

as the comment template used by classic themes.

The official Template Files documentation explicitly notes that classic themes use comments.php, while block themes use blocks instead.

A typical classic theme structure

theme/
├── style.css
├── functions.php
├── header.php
├── footer.php
├── index.php
├── single.php
├── page.php
└── comments.php

The exact files vary by theme, but this architecture remains common.

What usually happens inside comments.php?

A classic comments.php file may contain logic for:

• displaying the comment title;
• listing comments;
• displaying comment authors;
• rendering avatars;
• rendering dates;
• creating reply links;
• comment pagination;
• displaying the comment form;
• displaying a comments-closed message.

The official Classic Theme Comment Template documentation covers this structure in detail.

Classic themes often use wp_list_comments()

A common implementation is:

<ol class="comment-list">
    <?php
    wp_list_comments(
        array(
            'style'      => 'ol',
            'short_ping' => true,
        )
    );
    ?>
</ol>

wp_list_comments() takes the available comment objects and renders their frontend markup according to the supplied arguments and callbacks.

Classic themes use comment_form() for the form

The standard WordPress function:

comment_form()

generates the comment submission form.

A simple classic template may end with:

<?php comment_form(); ?>

Classic themes give developers direct PHP control

This architecture makes it straightforward for developers to conditionally modify behavior using PHP.

For example:

if ( comments_open() ) {
    comment_form();
}

or:

if ( get_comments_number() ) {
    wp_list_comments();
}

Classic comment markup can be heavily customized

Developers can:

• modify the comments.php template;
• provide custom callback functions;
• alter form fields;
• change comment navigation;
• customize threaded replies;
• change markup structure;
• apply CSS directly to theme classes.

This flexibility also creates theme-specific implementations

Two classic themes may display the exact same WordPress comment data using completely different markup.

One theme might produce:

<ol class="comment-list">

while another uses:

<div class="discussion-thread">

with a custom callback.

This matters when switching classic themes

The comments themselves remain stored, but their:

• layout;
• spacing;
• avatars;
• typography;
• reply styling;
• pagination;
• form appearance;

can change significantly.

How threaded replies work in classic themes

WordPress supports nested comment replies when threaded comments are enabled.

Classic themes traditionally need the:

comment-reply

script for enhanced threaded reply behavior.

The official Theme Handbook documentation on scripts explains that classic themes using threaded comments should conditionally enqueue the comment-reply script.

A common classic implementation

add_action(
    'wp_enqueue_scripts',
    function () {
        if (
            is_singular()
            &&
            comments_open()
            &&
            get_option( 'thread_comments' )
        ) {
            wp_enqueue_script(
                'comment-reply'
            );
        }
    }
);

Do not load comment-reply everywhere unnecessarily

If comments exist only on individual posts, loading the script across:

• archives;
• search pages;
• homepage;
• pages with comments disabled;

adds an unnecessary frontend resource.

Conditional loading is more appropriate.

Block themes handle comment presentation differently

Block themes do not generally use a traditional comments.php template to compose the visible comment section.

Instead, comment presentation is built with WordPress blocks.

A block theme’s single-post template might conceptually include:

Post Title
Post Content
Comments

where Comments is a dynamic block structure.

The main Comments block

WordPress provides the:

Comments

block.

The official Comments block documentation describes it as an advanced block used to display post comments with multiple configurable child blocks.

The Comments block is a container

It can contain several components, including:

• Comments Title;
• Comment Template;
• Comments Pagination;
• Post Comments Form.

This produces a different customization model

Instead of opening:

comments.php

and editing PHP, a site administrator can often open:

Appearance
→ Editor
→ Templates
→ Single

and customize the comment area visually.

Block themes use the Site Editor

With a block theme, the active theme can expose its templates through the Site Editor.

This means the comment section can be:

• moved;
• restyled;
• restructured;
• removed;
• combined with other blocks;

without editing a PHP template directly.

A block theme template is still a template

The visual editing model should not be confused with normal post content.

The comment section is usually part of the template structure rather than being manually inserted into every individual post.

In other words:

Single template
↓
Comments block
↓
used by many posts

Do not add the Comments block manually to every post

If comments belong to the site’s normal article layout, they generally belong in the relevant template.

Otherwise editors may end up creating inconsistent posts where:

Post A
→ Comments block manually inserted

Post B
→ no block

Post C
→ duplicate comment section

The Comment Template block

Inside the main Comments block, WordPress provides a:

Comment Template

block.

The official Comment Template block documentation explains that it contains the block structure repeated for comments returned by the query.

Think of it as a repeating comment layout

Conceptually:

Comment Template
├── Avatar
├── Comment Author Name
├── Comment Date
├── Comment Content
└── Comment Reply Link

That structure is repeated for the comments returned for the current post.

This is similar in purpose to a classic comment loop

Classic:

wp_list_comments()
+
PHP callback

Block theme:

Comment Template
+
nested blocks

Comment Content is its own block

The Comment Content block outputs the body of a comment.

The official Comment Content documentation explains that it belongs inside the Comment Template structure.

Other comment information can be controlled independently

A block theme can treat elements such as:

• author name;
• avatar;
• date;
• content;
• reply link;

as separate blocks.

This gives block themes more visual composition flexibility

For example, you can design:

Avatar | Author
       | Date
       | Comment
       | Reply

or:

Author · Date

Comment body

Reply

using block layout controls rather than building the structure entirely through PHP markup.

The Comment Reply Link block

WordPress includes:

core/comment-reply-link

for rendering reply links.

The current Block Editor documentation identifies it as a dynamic, server-rendered block that receives comment context.

Dynamic blocks do not simply store final HTML

The block stores configuration and context rather than permanently saving the rendered comment output into the template.

At runtime, WordPress can render the appropriate comment information for the current post.

The Post Comments Form block

Block themes can use:

Post Comments Form

inside the Comments structure.

The official Post Comments Form documentation describes it as the block responsible for displaying the comment submission form.

The form still respects WordPress comment state

A block theme does not bypass:

comment_status

or the WordPress comment system simply because the form is represented as a block.

Comments Pagination is also block-based

WordPress provides:

Comments Pagination

with inner blocks for:

• previous page;
• page numbers;
• next page.

The official Comments Pagination documentation confirms that it operates as part of the Comments block structure.

Classic themes handle pagination through PHP functions

A classic theme may instead use functions such as:

previous_comments_link()
next_comments_link()

or:

the_comments_pagination()

The feature is the same, the composition model is different

Both architectures can provide:

page 1
page 2
page 3

for large comment threads.

The difference is whether developers primarily configure that output with:

PHP template functions

or:

theme blocks

Block themes can style comment components independently

Because many pieces are blocks, the editor can expose visual settings for:

• typography;
• spacing;
• colors;
• borders;
• layout;
• alignment.

For example, the Comments Title block currently exposes controls for typography, dimensions, borders and other visual properties.

Classic themes normally style comments through CSS

A classic implementation may contain:

.comments-area {}

.comment-list {}

.comment {}

.comment-author {}

.comment-content {}

.reply {}

.comment-respond {}

The available classes vary by theme.

Block themes can still use CSS

Block-based customization does not mean CSS is obsolete.

Developers can still provide:

• theme styles;
• theme.json configuration;
• block-specific CSS;
• custom style variations.

The difference is that many common presentation controls no longer require editing CSS manually.

The comment data is still generated dynamically

Block themes do not save every comment into the template file.

A template may contain block markup describing:

show comment author here
show comment content here
show reply link here

WordPress supplies the actual comment data at runtime.

Block templates usually live as HTML files

A block theme commonly contains:

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

The template markup can include block comments such as:

<!-- wp:comments -->
...
<!-- /wp:comments -->

Do not confuse HTML templates with static HTML output

Although block-theme template files use the .html extension, dynamic blocks can still execute server-side rendering.

The file describes the block composition.

WordPress interprets it and generates the final response.

Classic vs block comment architecture

CLASSIC THEME

PHP template
↓
comments_template()
↓
comments.php
↓
PHP comment loop
↓
HTML


BLOCK THEME

HTML block template
↓
Comments block
↓
nested dynamic comment blocks
↓
server-side rendering
↓
HTML

Where do you remove comments in a classic theme?

If comments should no longer appear in a classic theme, inspect the relevant singular templates.

Typical files include:

single.php
page.php
singular.php

You may find:

comments_template();

or a conditional call around it.

Removing comments_template() changes presentation

For example:

// comments_template();

would stop that template from loading its comment template.

But this does not automatically change:

• stored comment status;
• existing comment records;
• REST behavior;
• admin interfaces;
• other templates.

Do not use template removal as the only method of disabling comments

If comments should genuinely be disabled site-wide, use a complete policy rather than only removing the visible section.

See How to Completely Disable Comments in WordPress.

Where do you remove comments in a block theme?

With a block theme, you can often open:

Appearance
→ Editor
→ Templates
→ Single

and remove the Comments block from the template.

This can remove the whole visible comment area

Removing the parent Comments block can remove child components such as:

• comment title;
• comment list;
• pagination;
• reply links;
• comment form.

But again, presentation is not comment status

You can have:

post comment_status = open
+
template contains no Comments block

The frontend does not show the normal comment interface, but the post can still be logically open for comments.

Do not mistake a missing Comments block for complete disabling

If the actual policy is:

nobody should be able to submit comments

change comment configuration too.

WordPress comment status is theme-independent

A post can store:

comment_status = closed

regardless of whether the theme is:

• classic;
• block-based;
• custom;
• hybrid.

For the difference between site defaults and individual content, see WordPress Per-Post vs. Site-Wide Comment Settings.

Switching themes does not normally reopen comments

If a post is stored as:

comment_status = closed

activating another theme does not normally rewrite it to:

open

The post’s stored discussion state belongs to the content configuration rather than the visual theme.

Switching themes can make comments appear or disappear visually

Suppose:

Post A
→ 15 approved comments
→ comment_status = closed

Classic Theme A loads comments_template() whenever existing comments are present.

The result:

15 old comments visible
form closed

You switch to Block Theme B, whose Single template has no Comments block.

The result becomes:

0 comments visible
form absent

The database can still contain all 15 comments.

This is an important migration test

When switching themes, do not verify only:

• header;
• footer;
• navigation;
• post content.

Also verify:

• existing comment visibility;
• comment form;
• threaded replies;
• pagination;
• avatars;
• comment counts;
• closed-comment states.

Existing comments are content, even though themes render them differently

A long-running site may contain years of useful discussions.

A theme migration should preserve the intended access to those discussions unless the site owner deliberately chooses otherwise.

Comments Count can appear outside the discussion area

WordPress block themes can use the:

Comments Count

block independently in appropriate post contexts.

The current Comments Count documentation explains that it can display the total number of comments for a post or page.

This can create inconsistencies after removing comments

For example:

Single template
→ Comments block removed

Post header
→ Comments Count still present

A visitor may see:

23 Comments

but have nowhere to read them.

Comments Link can create the same issue

WordPress also provides a Comments Link block that links to the current post’s comments section.

If you remove the comment section, check whether:

• Comments Count;
• Comments Link;
• comment metadata;

remain elsewhere in the template.

Comment presentation must be internally consistent

If comments are enabled:

count
+
link
+
discussion
+
form

may all be useful.

If comments are disabled but historical comments remain visible:

count
+
discussion
+
no form

may be appropriate.

If comments are completely removed from public view:

no count
no link
no discussion
no form

is generally more coherent.

Threaded replies differ in implementation too

In a classic theme, developers must usually ensure the correct reply script is loaded.

The Theme Handbook specifically notes that classic themes should add the comment-reply script when required.

Block themes handle the script integration for comment blocks

The same documentation notes that in block themes, the necessary script is included when the relevant comment block is present.

This means developers generally do not need to manually enqueue it simply because a block-theme template uses comments.

This reduces theme boilerplate

Classic:

developer checks conditions
↓
wp_enqueue_script( 'comment-reply' )

Block theme:

comment block present
↓
WordPress handles required block behavior

Do not manually enqueue duplicate comment scripts in a block theme

If the block infrastructure already handles the required assets, another manual enqueue may create redundant code or make debugging harder.

Comment styling is more portable conceptually in block themes

A block-oriented design system can define consistent:

• font sizes;
• colors;
• spacing;
• borders;
• layout rules.

through WordPress block styling and theme.json.

But block styling is still theme-dependent

Switching block themes can still change:

• available presets;
• spacing scales;
• font families;
• style variations;
• default block styles.

The comments themselves persist, but their visual design can change.

Classic themes often require template overrides for deeper changes

If you want to rearrange:

avatar
author
date
content
reply

in a classic theme, you may need to:

• edit comments.php;
• create a child-theme override;
• provide a custom callback;
• modify CSS.

Block themes expose much of that structure directly

In a block theme, the equivalent change may involve rearranging the nested blocks inside the Comment Template.

This is one of the major practical differences

Classic themes tend to expose comment structure primarily to developers.

Block themes can expose substantially more of that structure to site editors through the Site Editor.

That does not mean block themes eliminate code

Advanced customization can still require:

• custom blocks;
• PHP filters;
• JavaScript;
• CSS;
• theme.json;
• custom render callbacks.

The architecture is more block-oriented, not code-free.

Comment moderation does not change between theme architectures

Regardless of theme type, WordPress administration can still manage comments through:

Dashboard
→ Comments

Theme architecture primarily affects frontend presentation.

Discussion Settings remain global WordPress settings

Options under:

Settings
→ Discussion

continue to influence comment behavior regardless of theme.

The official Comments in WordPress documentation covers enabling comments, moderation and display settings independently of theme architecture.

Per-post comment status also remains independent

A single post can remain:

comments = open

or:

comments = closed

regardless of the active theme.

The theme determines how that state is represented

For example, when comments are closed:

Classic Theme A might display:

Comments are closed.

Classic Theme B might show old comments without any message.

Block Theme C might remove the form automatically while retaining the comment list.

Block Theme D might have no comment structure in the template at all.

Do not evaluate comment policy only by appearance

If the frontend contains no comment form, verify:

comments_open()

or the stored:

comment_status

before concluding that comments are disabled.

Classic-theme migration checklist

When moving from one classic theme to another, inspect:

• comments.php behavior;
• comments_template() conditions;
• custom comment callbacks;
• comment form customizations;
• threaded reply support;
• comment pagination;
• comment CSS;
• avatars;
• custom hooks.

Classic-to-block migration checklist

When moving from a classic theme to a block theme, review:

• whether the Single template contains a Comments block;
• how historical comments render;
• whether the Post Comments Form appears correctly;
• Comment Template structure;
• reply links;
• comment pagination;
• comment counts;
• Comments Link blocks;
• typography;
• spacing;
• nested reply indentation;
• mobile layout;
• custom functionality previously implemented in comments.php.

Custom comments.php logic does not automatically migrate into blocks

This is especially important.

Your old theme may contain custom code such as:

if ( is_user_logged_in() ) {
    // Special comment UI.
}

or:

wp_list_comments(
    array(
        'callback' => 'my_custom_comment'
    )
);

Activating a block theme does not automatically convert that custom PHP implementation into a block structure.

Audit custom behavior, not only visual output

Check whether the old theme implemented:

• badges;
• author highlighting;
• custom moderation messages;
• special reply controls;
• additional metadata;
• custom form fields;
• rating interfaces;
• membership restrictions.

Plugins may modify comments independently of the theme

A plugin can hook into:

• comment queries;
• comment forms;
• moderation;
• submission;
• REST endpoints;
• comment output;
• spam filtering.

That functionality can continue after switching themes even if the visual integration changes.

Plugin CSS may assume classic theme markup

A plugin may target selectors such as:

.comment-list
.comment-body
.comment-author
.reply

A different block-theme structure may not match those assumptions exactly.

Test third-party comment plugins after migration

This includes systems for:

• anti-spam;
• social comments;
• ratings;
• memberships;
• subscriptions;
• comment editing;
• notifications.

Do not assume block compatibility from frontend appearance alone

A plugin may appear visually acceptable while losing:

• reply behavior;
• custom metadata;
• AJAX functionality;
• moderation controls.

What happens to comments when you switch themes?

In the normal case:

comment database records
→ remain

post comment status
→ remains

moderation state
→ remains

theme presentation
→ changes

What does not automatically migrate?

Theme-specific implementation details such as:

• custom PHP callbacks;
• custom comment markup;
• theme-specific CSS;
• custom JS;
• template-specific placement.

Should you use a block theme just for better comment customization?

Not necessarily.

The theme architecture should be chosen according to the wider site requirements.

A well-built classic theme can provide an excellent comment experience.

A well-built block theme can provide an excellent comment experience.

The significant difference is the customization model.

Classic themes are useful when

• the site already depends on established PHP templates;
• developers require precise PHP-driven markup;
• a mature custom theme already exists;
• theme functionality relies heavily on traditional hooks and templates.

Block themes are useful when

• site owners need visual template editing;
• design systems use block styles and theme.json;
• templates should be configurable through the Site Editor;
• comment layouts should be composed visually.

Neither architecture changes WordPress moderation fundamentals

Regardless of theme:

visitor submits comment
↓
WordPress processes comment
↓
moderation rules apply
↓
comment stored
↓
theme renders approved discussion

Comment spam remains a WordPress-level concern

Changing from a classic to a block theme does not itself solve comment spam.

If spam is targeting your comment form or comment-author website field, the underlying submission system remains relevant.

See Why Comment Spam Targets the Website Field.

Disabling comments should be theme-independent

If comments are not part of the site’s workflow at all, implementing the policy only inside the active theme is fragile.

A theme change could restore visible comment interfaces or change rendering behavior.

A permanent comment policy should be enforced at the WordPress functionality level.

TheOneWP Disable Comments

TheOneWP Disable Comments provides a dedicated module for sites where comments should not remain part of the WordPress workflow.

This separates the site’s comment policy from the details of whether the active theme is classic or block-based.

Theme templates should still be reviewed

Even when comment functionality is disabled centrally, inspect the theme for:

• empty comment containers;
• old comment counts;
• comment links;
• closed-comment messages;
• unused spacing;
• block placeholders.

A useful separation of responsibilities

WordPress comment settings
→ whether discussion is allowed

comment database
→ stored discussion

theme
→ how discussion is displayed

classic comments.php
→ classic presentation

Comments blocks
→ block-theme presentation

Test comment changes on staging

Theme migration can affect years of existing discussion.

Test changes on a staging environment before deploying them to a live site with an established comment archive.

See WordPress Staging Site Best Practices.

Test posts with different comment states

Your staging audit should include at least:

Post with comments open and no comments

comments open
comments = 0

Post with comments open and existing comments

comments open
comments = 20

Post with comments closed and existing comments

comments closed
comments = 20

Post with threaded discussion

Comment
└── Reply
    └── Reply

Post with multiple comment pages

page 1
page 2
page 3

Test logged-out behavior

Always verify comment presentation as a normal visitor.

An administrator session can introduce:

• edit links;
• moderation controls;
• toolbar elements;
• different caching behavior.

Test mobile layouts

Nested comments can become difficult to read on narrow screens.

Review:

• reply indentation;
• avatar size;
• long usernames;
• long URLs;
• comment form fields;
• pagination;
• button width;
• focus states.

Accessibility still matters in both architectures

Comments contain interactive elements such as:

• reply links;
• forms;
• navigation;
• labels;
• pagination.

Regardless of theme architecture, preserve:

• clear form labels;
• keyboard navigation;
• visible focus states;
• sufficient color contrast;
• logical heading structure.

Do not rebuild comments purely for visual reasons

WordPress already provides:

• comment submission;
• threading;
• moderation;
• pagination;
• forms;
• author information;
• reply functionality.

Use existing APIs and blocks where they satisfy the requirement.

Classic vs block theme comparison

CLASSIC THEMES

Primary template system:
PHP

Comment template:
comments.php

Typical loader:
comments_template()

Comment list:
wp_list_comments()

Comment form:
comment_form()

Threaded reply asset:
usually explicitly enqueued

Customization:
PHP + CSS + hooks + filters


BLOCK THEMES

Primary template system:
block templates

Comment template:
Comments block structure

Comment list:
Comment Template block

Comment form:
Post Comments Form block

Threaded reply asset:
handled with comment block integration

Customization:
Site Editor + blocks + theme.json + CSS + APIs

What stays the same?

comment records
post comment_status
moderation
approval
spam state
thread relationships
WordPress comment APIs

What changes?

template architecture
markup composition
visual editing workflow
styling model
theme-specific integration

Classic vs block theme comments checklist

• Identify whether the active theme is classic or block-based.
• Do not assume theme type changes stored comment data.
• In classic themes, inspect comments.php.
• Inspect where comments_template() is called.
• Inspect wp_list_comments() custom callbacks.
• Inspect comment_form() customizations.
• Check the comment-reply script in classic themes.
• Load the reply script only where needed.
• In block themes, inspect the Single template.
• Locate the Comments block.
• Inspect the Comment Template block.
• Inspect Comment Content.
• Inspect author and date blocks.
• Inspect Comment Reply Link.
• Inspect Comments Pagination.
• Inspect Post Comments Form.
• Check Comments Count blocks elsewhere.
• Check Comments Link blocks elsewhere.
• Remember that removing comment presentation does not close comments.
• Remember that closing comments does not necessarily hide old comments.
• Review per-post comment status.
• Review site-wide Discussion settings.
• Review custom post types.
• Review WooCommerce or plugin review systems.
• Test existing comments after changing themes.
• Test threaded replies.
• Test comment pagination.
• Test comment forms.
• Test closed comments with historical discussion.
• Test logged-out users.
• Test mobile layouts.
• Test accessibility.
• Audit theme-specific PHP customizations before migrating.
• Audit plugin integrations.
• Do not assume old comments.php customizations migrate automatically.
• Use staging for major theme migrations.
• Purge caches after changing templates.

Related guides

• How to Completely Disable Comments in WordPress
• WordPress Per-Post vs. Site-Wide Comment Settings
• What Happens to Old Comments When You Disable Them
• Why Comment Spam Targets the Website Field
• Pingbacks, Trackbacks & Internal Links
• WordPress Staging Site Best Practices

Final recommendation

WordPress comments are fundamentally the same data and discussion system in classic and block themes, but the presentation architecture is different.

Classic themes generally rely on:

PHP template
↓
comments_template()
↓
comments.php
↓
WordPress comment functions

Block themes generally rely on:

block template
↓
Comments block
↓
nested dynamic comment blocks

If you maintain a classic theme, understand the relationship between single.php, comments_template(), comments.php, wp_list_comments(), comment_form() and the comment-reply script.

If you maintain a block theme, understand how the Comments block, Comment Template, Post Comments Form, Comments Pagination, Comments Count and Comments Link interact inside the Site Editor.

When switching theme architecture, do not assume that a visually correct post means the comment system migrated correctly.

Test:

historical comments
+
open comments
+
closed comments
+
threaded replies
+
pagination
+
forms
+
comment counts
+
mobile behavior

Most importantly, keep presentation separate from policy.

The useful model is:

WordPress
→ stores and manages comments

comment settings
→ determine whether discussion is allowed

classic theme
→ renders discussion through PHP templates

block theme
→ renders discussion through blocks

Once those layers are kept separate, switching or customizing themes becomes much safer and the behavior of existing comments becomes easier to predict.