无限长的归档页面

@ Bitcron笔记

其实这个问题由来已久,我曾在7月25日给 pi#bitcron.com 发邮件询问归档页面加载文章的限制。当时我嫌分页不够直接,于是写了 limit=999,却只在归档页面上看到大约300篇文章,然而我的博文总数高达800+篇。我猜是因为速度等原因限制了全部加载,并求教了不使用分页情况下加载全部文章的方法,第二天便得到了回复。

可以手工传入 page 这个参数,就可以取得后面一页了的数据了。
不是 323 篇, 是 300 篇, 系统做了限制,每次最多获取 300 条,一来避免对系统产生性能问题,二来可以避免页面本身的性能问题了。
已经做了调整,将最大数目改为 1000 篇。
但是,建议在当前情况下,不要在 Dashboard 的 Cache 策略设定为 No 之类的,对页面的实际生成速度会影响比较显著。 :)

当时我对 Hepo 所说的 page 参数一无所知,心想着既然已经改成了1000篇,应该还够我用好几个月,便没做他想。直到后来设计主题「它布」的时候,机缘巧合下用到了自动加载功能,这才第一次接触了 page 参数

作用:对内部产生的内容,可以实现滚动自动翻页载入。
接受参数:<as_ul=False, callback=''>,如果 as_ul = True,则最外部的 DOM 元素是 ul,反之则是 divcallback 是一个字符串类型,表示一个 JavaScript 的函数名,为翻页载入成功后的回调函数。
代码示例:

+posts.set_min_per_page(6)
+page(as_ul=True)
    for post in posts: li.post
        span.date= post.date('%Y-%m-%d %H:%M')
        .content.markdown= post.content

但真正将它跟归档页面结合起来还是前几天的事。制作定制主题的时候,客户提出“归档页不需要翻页,滚轮就是最好的翻页”,只是因为要求简单,不需要按照年份分组,我便没有使用自定义变量空间,而是直接用了官方的 posts 变量空间,所以也没有遇到什么难题。

今天因为纠结自定义变量空间下的 category 问题,读了好几遍官方文档都不得其解,想起曾经也问过很多相关问题,说不定以前看不懂的答案,现在会有所启发。于是我开始倒叙查看过去的问题邮件,看到了 page 参数,觉得好像在官方文档里读到过,便又去翻找。这才发现,原来 page 参数说的就是自动加载功能,感到很多混乱的思考连成了一条线。

说干就干,经过几轮测试,我终于弄懂了其中的逻辑,技术小白的心酸。官方给出的示例代码里有一句设定每页最少显示篇数的代码 +posts.set_min_per_page(6),刚开始我以为用这个就行,便去掉了自定义变量空间里的 limit,结果发现行不通。加了 limit 以后才发现上述代码压根没用,才意识到这是 posts 变量空间的参数,在自定义变量空间下当然不能使用。

那么 limit 设置成什么数字比较好呢?想想每年的博文应该不会超过366篇,就这么敲定了。亲测效果很棒,虽然跟 toggle 有些冲突,但影响不大,也无法避免,就 let it be 了。以下是 archive.jade 中的代码片段,做个记录。

entries = d.get_data(types='post', limit='366', sort='desc').group('-date:year')
+page(as_ul=false)
    for year, year_posts in entries
        header
            h2= year
            year_start_date = '%s-1-1' %year
            year_end_date = '%s-1-1' %(year.int+1)
            yearly_count = d.get_data(types='post', return_count=true, date_start=year_start_date, date_end=year_end_date)
            span= yearly_count

        ul: for post in year_posts: li
            time(datetime= post.date.format('%Y-%m-%d'))= post.date.format('%m.%d')
            a(href=post.url)= post.title

如果之前官方设定的300篇是专业人士认定的理想值的话,那么现在打开归档页面的首次加载值(366篇)已经表现得非常好了。不论如何,是大大优于1000篇的,也让博文越写越多的我从今往后高枕无忧了。


2017.08.24更新:在 Fooleap 的提示下,我重新思考了这个冲突,发现确实不可解。因为自动加载实现的是同样格式的项目不停加载,而我的归档页面除了文章还有年份标题,要么只加载文章没有年份标题,要么年份标题重复了。所以最后我还是移除了这项功能。在文章不多的情况下,把归档和分类分别统合在一个页面内是我觉得最理想的方式,非常符合我对于简洁的追求。然而文章数量一旦多起来,又开始令人苦恼了。交给未来的水八口解决吧。


评论