你有一些问题
使用\'no_found_rows\' => true
不正确。no_found_rows
用于将not 分页。\'no_found_rows\' => true
路过get_posts
到WP_Query
为了合法地“破坏”分页,这就是为什么get_posts
无法按正常方式分页。
这里真正发生的是,默认情况下,当您使用WP_Query
, WP_Query
运行整个数据库并查找与查询参数匹配的所有帖子。主查询和自定义查询都会发生这种情况。因此,如果每页需要5篇文章,则查询将返回5篇文章,但已检查完整的数据库中是否有与查询匹配的所有文章,并将该金额返回并存储到$found_posts
查询对象的属性。找到的与查询匹配的帖子数量用于(内部)计算$max_num_pages
属性,该属性在计算分页查询中的分页时是不可或缺的。$max_num_pages
这将告诉分页功能将有多少页文章(您可以使用echo $printposts->max_num_pages
),然后相应地显示链接。
具有no_found_rows
设置为true
, 跳过上述过程。WP_Query
现在只需查找与查询匹配的前5篇文章,暂停/停止执行并返回这5篇文章。跳过计算数据库中的所有帖子以建立与特定查询匹配的所有帖子的过程。所以,正如我所说的,您现在在法律上破坏分页,因为分页对这样的查询不起作用。这样做是为了在运行未分页查询时节省资源。它使这样的查询更快,并节省了查询在数据库中花费(不必要)的时间。
由于需要对查询分页,因此需要删除\'no_found_rows\' => true
在next_posts_link()
函数根据主查询对象设置为页数。在页面模板上,永远只有一个页面,所以您的链接永远不会只在默认情况下工作。要使其工作,您需要设置next_posts_link()
到$max_num_pages
自定义查询的属性。这很容易,因为next_posts_link()
接受一组自定义页数。所以你需要做的就是通过$printposts->max_num_pages
作为像这样的第二个参数
<div class="nav-next "><?php next_posts_link( \'Older posts »\', $printposts->max_num_pages ); ?></div>
只有一个额外的注意事项,
suppress_filters
默认设置为false,这意味着
posts_*
过滤器可以根据需要影响和修改查询。我通常将此参数设置为
true
对于自定义查询,我知道我正在保存,并且任何自定义筛选器都不会干扰我的自定义查询