WordPress嵌套回复及其构成原理

浏览次数：次 2009年08月01日 NeoEase 字号: 大中小

WordPress 2.7 开始引入了原生的嵌套回复功能. 这是一个有争议的功能, 也是制作主题中一个难度较高的模块, 所以大家对它一直讨论不断.

WordPress 嵌套回复

要不要使用嵌套回复? (优缺点对照)

一部分人对这个功能垂涎已久, 在 WordPress 原生支持嵌套回复之前就尝试使用一些插件来支持该功能. 嵌套回复有很多优点:

1. 它可以提高用户体验, 调动访客回复的积极性, 从而增加评论的数量, 能让博客变得像社区一样活跃.

2. 博客的回复邮件通知功能越来越被重视, 因为它可以为你挽留一些游客. 另外评论者发表评论后也不用经常回来查看是否被答复, 可以在一定程度上提高互动性. 嵌套回复可以有针对性的对评论进行答复, 评论者只要收到邮件便可知其所答.

另一部分人不使用嵌套回复, 我就是其中之一. 为什么呢? 且听我慢慢道来. 任何事物都有其利弊, 嵌套回复也存在一些缺点:

1. 嵌套回复是一种依赖程序的显示结构, 也就是说, 只要你使用了一次, 以后必须使用, 否则评论的顺序就乱了. 假设现在有 A, B, C 三人, 他们都进行了一次评论, 操作如下:
A 添加了一条评论.
B 也添加了一条评论.
C 回复了 A 的评论.

如果主题支持嵌套回复, 会得到以下的显示结构:

A

C

B

但如果主题不支持嵌套, 则会显示如下:

A

B

C

也就是说, 页面结构将变得无比的混乱, 你不得不让当前主题支持嵌套回复, 或者使用插件对其进行支持. 这就是对程序的依赖, 除非精通其制作原理, 否则它会限制你对主题和插件的选择.

2. 嵌套回复有针对性的回复功能 (针对某条评论进行回复) 是它的优势, 同时也是他的劣势. 如果有 100 个人在你的一篇文章中发表了评论, 并且你习惯对大部分评论都进行回复, 那是不是你也需要回复差不多 100 次? 如果这样的话, @ 回复比嵌套回复更适合你.

3. 嵌套回复依赖浏览器对 JavaScript 的支持.

我不使用嵌套回复也是因为前两个原因, 我不敢确定自己以后会一直使用嵌套回复, 并且在我的回复者中, 经常出现几个人提问同一个问题. 使用 @reply 是一个折中的选择, 我可以在一个回复中回答网友的评论, 并且我无需对相同的提问进行多次回答; 另外, 通过一些插件, 我同样可以实现回复邮件通知的功能, 仅是邮件内容稍为复杂罢了.

怎样将嵌套回复功能集成到主题中?

在主题中实现嵌套回复的方法有二, 包括 WordPress 提供的默认方法和自定义的回调方法. 下面我会讲解一下如何实现起嵌套结构, CSS 部分请自行研究.

默认方法:
WordPress 提供的基本的嵌套风格, default 主题用的就是这种模式.
优点: 方便使用, 减少代码量.
缺点: 代码结构不好, 不可能适合所有的主题.
实现步骤如下:

1. 在 header.php 的 <?php wp_head(); ?> 前方添加以下代码.

1	<?php if(is_singular()) wp_enqueue_script( "comment-reply" ); ?>

其作用是加载嵌套回复所需的 JavaScript 代码. (也就是说, 如果浏览器不支持 JavaScript, 嵌套回复就没法实现)

2. 在 comments.php 文件的顶部添加以下代码.

<?php
	if (!empty(WordPress 2.7 开始引入了原生的嵌套回复功能. 这是一个有争议的功能, 也是制作主题中一个难度较高的模块, 所以大家对它一直讨论不断. 
 

要不要使用嵌套回复? (优缺点对照)
一部分人对这个功能垂涎已久, 在 WordPress 原生支持嵌套回复之前就尝试使用一些插件来支持该功能. 嵌套回复有很多优点: 
1. 它可以提高用户体验, 调动访客回复的积极性, 从而增加评论的数量, 能让博客变得像社区一样活跃. 
2. 博客的回复邮件通知功能越来越被重视, 因为它可以为你挽留一些游客. 另外评论者发表评论后也不用经常回来查看是否被答复, 可以在一定程度上提高互动性. 嵌套回复可以有针对性的对评论进行答复, 评论者只要收到邮件便可知其所答. 
另一部分人不使用嵌套回复, 我就是其中之一. 为什么呢? 且听我慢慢道来. 任何事物都有其利弊, 嵌套回复也存在一些缺点: 
1. 嵌套回复是一种依赖程序的显示结构, 也就是说, 只要你使用了一次, 以后必须使用, 否则评论的顺序就乱了. 假设现在有 A, B, C 三人, 他们都进行了一次评论, 操作如下:
A 添加了一条评论.
B 也添加了一条评论.
C 回复了 A 的评论. 
如果主题支持嵌套回复, 会得到以下的显示结构: 

A

C

B

但如果主题不支持嵌套, 则会显示如下: 

A

B

C

也就是说, 页面结构将变得无比的混乱, 你不得不让当前主题支持嵌套回复, 或者使用插件对其进行支持. 这就是对程序的依赖, 除非精通其制作原理, 否则它会限制你对主题和插件的选择. 
2. 嵌套回复有针对性的回复功能 (针对某条评论进行回复) 是它的优势, 同时也是他的劣势. 如果有 100 个人在你的一篇文章中发表了评论, 并且你习惯对大部分评论都进行回复, 那是不是你也需要回复差不多 100 次? 如果这样的话, @ 回复比嵌套回复更适合你. 
3. 嵌套回复依赖浏览器对 JavaScript 的支持. 
我不使用嵌套回复也是因为前两个原因, 我不敢确定自己以后会一直使用嵌套回复, 并且在我的回复者中, 经常出现几个人提问同一个问题. 使用 @reply 是一个折中的选择, 我可以在一个回复中回答网友的评论, 并且我无需对相同的提问进行多次回答; 另外, 通过一些插件, 我同样可以实现回复邮件通知的功能, 仅是邮件内容稍为复杂罢了. 
怎样将嵌套回复功能集成到主题中?
在主题中实现嵌套回复的方法有二, 包括 WordPress 提供的默认方法和自定义的回调方法. 下面我会讲解一下如何实现起嵌套结构, CSS 部分请自行研究. 
默认方法:
WordPress 提供的基本的嵌套风格, default 主题用的就是这种模式.
优点: 方便使用, 减少代码量.
缺点: 代码结构不好, 不可能适合所有的主题.
实现步骤如下: 
1. 在 header.php 的 <?php wp_head(); ?> 前方添加以下代码. 

1

            
            
            <?php if(is_singular()) wp_enqueue_script( "comment-reply" ); ?>
            
        
    


其作用是加载嵌套回复所需的 JavaScript 代码. (也就是说, 如果浏览器不支持 JavaScript, 嵌套回复就没法实现) 
2. 在 comments.php 文件的顶部添加以下代码. 


    
        
            
            1
2
3
4
5

            
            
            ___FCKpd___3
            
        
    


3. 在 comments.php 文件的评论列表元素中添加以下代码调用所有相关评论. 


    
        
            
            1

            
            
            <?php wp_list_comments(); ?>
            
        
    


4. 在 comments.php 的 id="commentform" 元素内部添加以下代码. 


    
        
            
            1

            
            
            <?php comment_id_fields(); ?>
            
        
    


和表单的适当取消回复按钮, 代码如下. 


    
        
            
            1

            
            
            <?php cancel_comment_reply_link() ?>
            
        
    


5. 将所有调用评论部分的代码由 


    
        
            
            1

            
            
            <?php comments_template(); ?>
            
        
    


修改为一下代码 


    
        
            
            1

            
            
            <?php comments_template("", true); ?>
            
        
    


回调方法:
在基本嵌套的基础上, 定义 callback 方法以重新定义评论的内容和布局.
优点: 灵活多变
缺点: 增加大量代码 
1. 在默认方法的基础上, 添加一个回调函数, 以取代 WordPress 默认的评论布局. 我在 function.php 中添加了一个名为 custom_comments 的方法. 这里需要注意, 请不要加上结束的 </li> 标签, 我会在后续文章中说明具体为何不能加上. 
2. 在 comments.php 中将 


    
        
            
            1

            
            
            <?php wp_list_comments(); ?>
            
        
    


修改为以下代码以调用自定义的 custom_comments 方法 


    
        
            
            1

            
            
            <?php wp_list_comments("callback=custom_comments"); ?>
            
        
    


详细代码可以参考本人制作的 Blocks 主题. 
什么主题适合添加嵌套回复?
在主题中添加嵌套回复是个麻烦事, 它很折腾人, 而且会打乱整个主题结构, 直到现在我还在怀疑官方是否应该原生地支持嵌套回复. 但既然支持了很应该尝试一下, 那是不是所有的主题都适合添加嵌套回复功能? 我觉得不是. 
对于一些图片较多的, 或者评论页面结构复杂的主题, 显然是不适合的, 这就是为什么我一直不在 iNove 添加嵌套回复功能的原因. 但是对于一些不依赖图片的主题, 如 Blocks 就很适合添加. 
另外, 还需要根据你的需求判断是否支持嵌套回复, 支持多少层的回复? 最深层次是 10, 但我们可以只支持到第二或者第三层, 以降低开发成本. 
后记
不知为何, 没有使用嵌套回复的我被多次问及相关的问题. 因为嵌套回复实现复杂, 难以维护, 和其他一些原因, 很多主题没有支持嵌套回复, 但很多人却是对它情有独钟, 我觉得可以将我的理解和大家分享一下. 
WordPress 嵌套回复构成原理
上面部分, 我已经介绍了嵌套回复的利弊, 制作方法等等. 本文将简单说明嵌套回复构成的原理. 
本文中提及的 4 个方法均来自 Walker_Comment 类, 该类继承自 Walker, 是构建嵌套回复的核心部分. 另外, WordPress 中的子页面和子分类也是使用 Walker 的子类来实现的. 如果你想对 WordPress 的嵌套同能了解更多, 可以查阅 WordPress Codex 中关于 Walker 类的说明. 
打开 wp-includes/comment-template.php, 查找 Walker_Comment 类. 以下展开介绍这 4 个方法. 

start_lvl
子菜单列表的开始标签, 默认是 <ul>, 在第一个子条目之前生成. 
end_lvl
对应 start_lvl 的子菜单列表的结束标签, 默认是 </ul>, 在最后一个子条目之后生成. 
start_el
条目的前半部分, 包括开始符号和评论内容. 开始符号是 <div> 或者 <li> (外层是 ol 或 ul 的情况下是 <li>); 评论内容就是评论的相关信息显示, WordPress 向我们提供了可即用的布局, 但也可以通过 callback 方法改变评论内容的结构. 调用回调函数的部分代码示意如下: 


    
        
            
            1
2
3
4
5
6
7
8
9
10
11
12
13

            
            
            function start_el(&$output, $comment, $depth, $args) {
	$depth++;
	$GLOBALS["comment_depth"] = $depth;
 
	// 如果定义了回调函数, 则调用其回调函数, 并终止后面的处理.
	if ( !empty($args["callback"]) ) {
		call_user_func($args["callback"], $comment, $args, $depth);
		return;
	}
 
	// 如果没有定义回调函数, 则执行本方法中后面的处理, 生成默认的评论布局.
	...
}
            
        
    


我们所谓的自定义嵌套回复, 就是创建一个 callback 方法, 并在 wp_list_comments 方法中调用这个它生成自定义的评论结构. 也可以认为是定义一个新的方法, 取代 start_el 方法内部的默认布局. 
end_el
条目的后半部分, 其实就一个结束符号. 这里也提供一个名为 end-callback 的回调方法, 原理和 start_el 一样, 是一个自定义的处理方式. 但是 end-callback 并不常用, 因为 end_el 只生成一个简单的结束符号, 实在没必要为此再定义一个方法. 
我觉得只有在需要复杂的评论结构时, 才有必要用到 end-callback. 如: 要在评论的上方和下方都添加背景图效果, 评论框内可能需要多一个 DIV 层, 则可能用上 end-callback. 在 callback 方法中以 <div class="comment"><div class="inner"> 作为开始, 而 end-callback 中以 </div></div> 结束掉. 
例子
下面我将以一个嵌套回复的例子来证明上述内容. 
现有评论嵌套结构如下: 

comment (1)

comment (1.1) 

comment (1.2)

comment (1.2.1) 

comment (2) 

依照上述方法, 执行顺序如下: 

start_el (1)
start_lvl (1)
start_el (1.1)
end_el (1.1)
start_el (1.2)
start_lvl (1.2)
start_el (1.2.1)
end_el (1.2.1)
end_lvl (1.2)
end_el (1.2)
end_lvl (1)
end_el (1)
start_el (2)
end_el (2) 

假设方法配置都是默认的, 则: 

start_lvl 为 <ul>
end_lvl 为 </ul>
start_el 为 <li> 和内容部分
end_el 为 </li> 

又设 "..." 为评论内容, 则代码生成如下: 


    
        
            
            1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

            
            
            <li>
	... (1)
 
	<ul>
		<li>
			... (1.1)
 
		</li>
		<li>
			... (1.2)
 
			<ul>
				<li>
					... (1.2.1)
 
				</li>
			</ul>
		</li>
	</ul>
</li>
<li>
	... (2)
 
</li>
            
        
    


本文转自 NeoEase 原文出自：http://www.neoease.com/wordpress-thread-comments/和http://www.neoease.com/wordpress-walker-comments/
SERVER["SCRIPT_FILENAME"]) && "comments.php" == basename(
WordPress 2.7 开始引入了原生的嵌套回复功能. 这是一个有争议的功能, 也是制作主题中一个难度较高的模块, 所以大家对它一直讨论不断. 
 

要不要使用嵌套回复? (优缺点对照)
一部分人对这个功能垂涎已久, 在 WordPress 原生支持嵌套回复之前就尝试使用一些插件来支持该功能. 嵌套回复有很多优点: 
1. 它可以提高用户体验, 调动访客回复的积极性, 从而增加评论的数量, 能让博客变得像社区一样活跃. 
2. 博客的回复邮件通知功能越来越被重视, 因为它可以为你挽留一些游客. 另外评论者发表评论后也不用经常回来查看是否被答复, 可以在一定程度上提高互动性. 嵌套回复可以有针对性的对评论进行答复, 评论者只要收到邮件便可知其所答. 
另一部分人不使用嵌套回复, 我就是其中之一. 为什么呢? 且听我慢慢道来. 任何事物都有其利弊, 嵌套回复也存在一些缺点: 
1. 嵌套回复是一种依赖程序的显示结构, 也就是说, 只要你使用了一次, 以后必须使用, 否则评论的顺序就乱了. 假设现在有 A, B, C 三人, 他们都进行了一次评论, 操作如下:
A 添加了一条评论.
B 也添加了一条评论.
C 回复了 A 的评论. 
如果主题支持嵌套回复, 会得到以下的显示结构: 

A

C

B

但如果主题不支持嵌套, 则会显示如下: 

A

B

C

也就是说, 页面结构将变得无比的混乱, 你不得不让当前主题支持嵌套回复, 或者使用插件对其进行支持. 这就是对程序的依赖, 除非精通其制作原理, 否则它会限制你对主题和插件的选择. 
2. 嵌套回复有针对性的回复功能 (针对某条评论进行回复) 是它的优势, 同时也是他的劣势. 如果有 100 个人在你的一篇文章中发表了评论, 并且你习惯对大部分评论都进行回复, 那是不是你也需要回复差不多 100 次? 如果这样的话, @ 回复比嵌套回复更适合你. 
3. 嵌套回复依赖浏览器对 JavaScript 的支持. 
我不使用嵌套回复也是因为前两个原因, 我不敢确定自己以后会一直使用嵌套回复, 并且在我的回复者中, 经常出现几个人提问同一个问题. 使用 @reply 是一个折中的选择, 我可以在一个回复中回答网友的评论, 并且我无需对相同的提问进行多次回答; 另外, 通过一些插件, 我同样可以实现回复邮件通知的功能, 仅是邮件内容稍为复杂罢了. 
怎样将嵌套回复功能集成到主题中?
在主题中实现嵌套回复的方法有二, 包括 WordPress 提供的默认方法和自定义的回调方法. 下面我会讲解一下如何实现起嵌套结构, CSS 部分请自行研究. 
默认方法:
WordPress 提供的基本的嵌套风格, default 主题用的就是这种模式.
优点: 方便使用, 减少代码量.
缺点: 代码结构不好, 不可能适合所有的主题.
实现步骤如下: 
1. 在 header.php 的 <?php wp_head(); ?> 前方添加以下代码. 


    
        
            
            1

            
            
            <?php if(is_singular()) wp_enqueue_script( "comment-reply" ); ?>
            
        
    


其作用是加载嵌套回复所需的 JavaScript 代码. (也就是说, 如果浏览器不支持 JavaScript, 嵌套回复就没法实现) 
2. 在 comments.php 文件的顶部添加以下代码. 


    
        
            
            1
2
3
4
5

            
            
            ___FCKpd___3
            
        
    


3. 在 comments.php 文件的评论列表元素中添加以下代码调用所有相关评论. 


    
        
            
            ___FCKpd___4
            
            
            ___FCKpd___5
            
        
    


4. 在 comments.php 的 id="commentform" 元素内部添加以下代码. 


    
        
            
            ___FCKpd___6
            
            
            ___FCKpd___7
            
        
    


和表单的适当取消回复按钮, 代码如下. 


    
        
            
            ___FCKpd___8
            
            
            ___FCKpd___9
            
        
    


5. 将所有调用评论部分的代码由 


    
        
            
            ___FCKpd___10
            
            
            ___FCKpd___11
            
        
    


修改为一下代码 


    
        
            
            ___FCKpd___12
            
            
            ___FCKpd___13
            
        
    


回调方法:
在基本嵌套的基础上, 定义 callback 方法以重新定义评论的内容和布局.
优点: 灵活多变
缺点: 增加大量代码 
1. 在默认方法的基础上, 添加一个回调函数, 以取代 WordPress 默认的评论布局. 我在 function.php 中添加了一个名为 custom_comments 的方法. 这里需要注意, 请不要加上结束的 </li> 标签, 我会在后续文章中说明具体为何不能加上. 
2. 在 comments.php 中将 


    
        
            
            ___FCKpd___14
            
            
            ___FCKpd___15
            
        
    


修改为以下代码以调用自定义的 custom_comments 方法 


    
        
            
            ___FCKpd___16
            
            
            ___FCKpd___17
            
        
    


详细代码可以参考本人制作的 Blocks 主题. 
什么主题适合添加嵌套回复?
在主题中添加嵌套回复是个麻烦事, 它很折腾人, 而且会打乱整个主题结构, 直到现在我还在怀疑官方是否应该原生地支持嵌套回复. 但既然支持了很应该尝试一下, 那是不是所有的主题都适合添加嵌套回复功能? 我觉得不是. 
对于一些图片较多的, 或者评论页面结构复杂的主题, 显然是不适合的, 这就是为什么我一直不在 iNove 添加嵌套回复功能的原因. 但是对于一些不依赖图片的主题, 如 Blocks 就很适合添加. 
另外, 还需要根据你的需求判断是否支持嵌套回复, 支持多少层的回复? 最深层次是 10, 但我们可以只支持到第二或者第三层, 以降低开发成本. 
后记
不知为何, 没有使用嵌套回复的我被多次问及相关的问题. 因为嵌套回复实现复杂, 难以维护, 和其他一些原因, 很多主题没有支持嵌套回复, 但很多人却是对它情有独钟, 我觉得可以将我的理解和大家分享一下. 
WordPress 嵌套回复构成原理
上面部分, 我已经介绍了嵌套回复的利弊, 制作方法等等. 本文将简单说明嵌套回复构成的原理. 
本文中提及的 4 个方法均来自 Walker_Comment 类, 该类继承自 Walker, 是构建嵌套回复的核心部分. 另外, WordPress 中的子页面和子分类也是使用 Walker 的子类来实现的. 如果你想对 WordPress 的嵌套同能了解更多, 可以查阅 WordPress Codex 中关于 Walker 类的说明. 
打开 wp-includes/comment-template.php, 查找 Walker_Comment 类. 以下展开介绍这 4 个方法. 

start_lvl
子菜单列表的开始标签, 默认是 <ul>, 在第一个子条目之前生成. 
end_lvl
对应 start_lvl 的子菜单列表的结束标签, 默认是 </ul>, 在最后一个子条目之后生成. 
start_el
条目的前半部分, 包括开始符号和评论内容. 开始符号是 <div> 或者 <li> (外层是 ol 或 ul 的情况下是 <li>); 评论内容就是评论的相关信息显示, WordPress 向我们提供了可即用的布局, 但也可以通过 callback 方法改变评论内容的结构. 调用回调函数的部分代码示意如下: 


    
        
            
            ___FCKpd___18
            
            
            ___FCKpd___19
            
        
    


我们所谓的自定义嵌套回复, 就是创建一个 callback 方法, 并在 wp_list_comments 方法中调用这个它生成自定义的评论结构. 也可以认为是定义一个新的方法, 取代 start_el 方法内部的默认布局. 
end_el
条目的后半部分, 其实就一个结束符号. 这里也提供一个名为 end-callback 的回调方法, 原理和 start_el 一样, 是一个自定义的处理方式. 但是 end-callback 并不常用, 因为 end_el 只生成一个简单的结束符号, 实在没必要为此再定义一个方法. 
我觉得只有在需要复杂的评论结构时, 才有必要用到 end-callback. 如: 要在评论的上方和下方都添加背景图效果, 评论框内可能需要多一个 DIV 层, 则可能用上 end-callback. 在 callback 方法中以 <div class="comment"><div class="inner"> 作为开始, 而 end-callback 中以 </div></div> 结束掉. 
例子
下面我将以一个嵌套回复的例子来证明上述内容. 
现有评论嵌套结构如下: 

comment (1)

comment (1.1) 

comment (1.2)

comment (1.2.1) 

comment (2) 

依照上述方法, 执行顺序如下: 

start_el (1)
start_lvl (1)
start_el (1.1)
end_el (1.1)
start_el (1.2)
start_lvl (1.2)
start_el (1.2.1)
end_el (1.2.1)
end_lvl (1.2)
end_el (1.2)
end_lvl (1)
end_el (1)
start_el (2)
end_el (2) 

假设方法配置都是默认的, 则: 

start_lvl 为 <ul>
end_lvl 为 </ul>
start_el 为 <li> 和内容部分
end_el 为 </li> 

又设 "..." 为评论内容, 则代码生成如下: 


    
        
            
            ___FCKpd___20
            
            
            ___FCKpd___21
            
        
    


本文转自 NeoEase 原文出自：http://www.neoease.com/wordpress-thread-comments/和http://www.neoease.com/wordpress-walker-comments/
SERVER["SCRIPT_FILENAME"])) {
die (__("Please do not load this page directly. Thanks!"));
}
?>

3. 在 comments.php 文件的评论列表元素中添加以下代码调用所有相关评论.

___FCKpd___4

___FCKpd___5

4. 在 comments.php 的 id="commentform" 元素内部添加以下代码.

___FCKpd___6

___FCKpd___7

和表单的适当取消回复按钮, 代码如下.

___FCKpd___8

___FCKpd___9

5. 将所有调用评论部分的代码由

___FCKpd___10

___FCKpd___11

修改为一下代码

___FCKpd___12

___FCKpd___13

回调方法:
在基本嵌套的基础上, 定义 callback 方法以重新定义评论的内容和布局.
优点: 灵活多变
缺点: 增加大量代码

1. 在默认方法的基础上, 添加一个回调函数, 以取代 WordPress 默认的评论布局. 我在 function.php 中添加了一个名为 custom_comments 的方法. 这里需要注意, 请不要加上结束的 </li> 标签, 我会在后续文章中说明具体为何不能加上.

2. 在 comments.php 中将

___FCKpd___14

___FCKpd___15

修改为以下代码以调用自定义的 custom_comments 方法

___FCKpd___16

___FCKpd___17

详细代码可以参考本人制作的 Blocks 主题.

什么主题适合添加嵌套回复?

在主题中添加嵌套回复是个麻烦事, 它很折腾人, 而且会打乱整个主题结构, 直到现在我还在怀疑官方是否应该原生地支持嵌套回复. 但既然支持了很应该尝试一下, 那是不是所有的主题都适合添加嵌套回复功能? 我觉得不是.

对于一些图片较多的, 或者评论页面结构复杂的主题, 显然是不适合的, 这就是为什么我一直不在 iNove 添加嵌套回复功能的原因. 但是对于一些不依赖图片的主题, 如 Blocks 就很适合添加.

另外, 还需要根据你的需求判断是否支持嵌套回复, 支持多少层的回复? 最深层次是 10, 但我们可以只支持到第二或者第三层, 以降低开发成本.

后记

不知为何, 没有使用嵌套回复的我被多次问及相关的问题. 因为嵌套回复实现复杂, 难以维护, 和其他一些原因, 很多主题没有支持嵌套回复, 但很多人却是对它情有独钟, 我觉得可以将我的理解和大家分享一下.

WordPress 嵌套回复构成原理

上面部分, 我已经介绍了嵌套回复的利弊, 制作方法等等. 本文将简单说明嵌套回复构成的原理.

本文中提及的 4 个方法均来自 Walker_Comment 类, 该类继承自 Walker, 是构建嵌套回复的核心部分. 另外, WordPress 中的子页面和子分类也是使用 Walker 的子类来实现的. 如果你想对 WordPress 的嵌套同能了解更多, 可以查阅 WordPress Codex 中关于 Walker 类的说明.

打开 wp-includes/comment-template.php, 查找 Walker_Comment 类. 以下展开介绍这 4 个方法.

start_lvl

子菜单列表的开始标签, 默认是 <ul>, 在第一个子条目之前生成.

end_lvl

对应 start_lvl 的子菜单列表的结束标签, 默认是 </ul>, 在最后一个子条目之后生成.

start_el

条目的前半部分, 包括开始符号和评论内容. 开始符号是 <div> 或者 <li> (外层是 ol 或 ul 的情况下是 <li>); 评论内容就是评论的相关信息显示, WordPress 向我们提供了可即用的布局, 但也可以通过 callback 方法改变评论内容的结构. 调用回调函数的部分代码示意如下:

___FCKpd___18

___FCKpd___19

我们所谓的自定义嵌套回复, 就是创建一个 callback 方法, 并在 wp_list_comments 方法中调用这个它生成自定义的评论结构. 也可以认为是定义一个新的方法, 取代 start_el 方法内部的默认布局.

end_el

条目的后半部分, 其实就一个结束符号. 这里也提供一个名为 end-callback 的回调方法, 原理和 start_el 一样, 是一个自定义的处理方式. 但是 end-callback 并不常用, 因为 end_el 只生成一个简单的结束符号, 实在没必要为此再定义一个方法.

我觉得只有在需要复杂的评论结构时, 才有必要用到 end-callback. 如: 要在评论的上方和下方都添加背景图效果, 评论框内可能需要多一个 DIV 层, 则可能用上 end-callback. 在 callback 方法中以 <div class="comment"><div class="inner"> 作为开始, 而 end-callback 中以 </div></div> 结束掉.

例子

下面我将以一个嵌套回复的例子来证明上述内容.

现有评论嵌套结构如下:

comment (1)

comment (1.1)

comment (1.2)

comment (1.2.1)

comment (2)

依照上述方法, 执行顺序如下:

start_el (1)
start_lvl (1)
start_el (1.1)
end_el (1.1)
start_el (1.2)
start_lvl (1.2)
start_el (1.2.1)
end_el (1.2.1)
end_lvl (1.2)
end_el (1.2)
end_lvl (1)
end_el (1)
start_el (2)
end_el (2)

假设方法配置都是默认的, 则: