当一个主题包含被删除过的回复时,在不同的时间访问会看到不同的,错乱的回帖。
现在访问 viewthread 时,系统按照页码找帖子的方式是,先直接对着position找,如果获取到的帖子数量不够,这页里面有删过的帖子,那么就把这个主题标记为 "threaddisablepos",然后以后访问时不再用position找,而是用数据库LIMIT来找。
计划任务每日清理时,这个标记会被清空。
这样只要没有访问过包含删过帖子的页码,这个主题就是pos模式,当访问过包含删掉的帖子的页码之后,就会在一天内变为顺序模式,这两种模式下页码跟帖子的对应可能会有很大差别。
实际使用中问题更显著一些的情况,如果有个几十页的长楼,中间删过十几帖,中间的部分由于不太常被访问,每日清理过后会是页码对位置模式,用户来了访问第60页看到的将会是591-600。大部分时候都是这样,然后有一个人突然访问了一下中间某页,系统发现了有删掉的帖子,就会变成顺序模式,然后在看第60页的用户刷新了一下,或者点链接过来,可能就变成了620-629之类的大错位,持续一天,等明天每日清理过后刷新又再变回页码对位置模式。
可能的解决方案:
方向1. 严格保每页帖数,每日更新时不再删 threaddisablepos。
main/source/include/cron/cron_cleanup_daily.php,删掉 C::t('forum_threaddisablepos')->truncate() 这一行。
方向2. 保帖子位置, 只用 position 跟页码对应,发表后不再变更,有帖子删了就让那页变少。
这样好处是带页码的链接对应哪些帖子是稳定的,而且简单性能好。
main/source/module/forum/forum_viewthread.php,删掉 threaddisablepos 相关的操作。
印象中旧版本的 Discuz 就是只有位置对页码的行为,猜可能是嫌每页帖子数量不一致太难看,额外加了那个机制,然后考虑性能优化性能故意没严格做对。
方向3. 重置帖子编号,当删除回复时,或者计划任务中清空 threaddisablepos 时,把帖子 position 字段重新整理为顺序的。
main/source/include/cron/cron_cleanup_daily.php,在 truncate 前先读一下那个表,把它们下面的 posts 更新为顺序的 position。
此问题之前有过讨论的,而且问题远比这个描述当中的复杂。
包括删帖进回收站,回帖进审核等数据实际存在,占用楼层但需要重算之类的问题。
如果站点对这块有需求可以暂时按方案1来进行修改,但由于对高楼层不够友好不太适合纳入官方解决方案。
按此方案修改以后,需要高楼层的话可以发布成抢楼帖,不影响性能。
方案2就是目前抢楼帖的实际做法,单独把它划分出来而不作为默认配置就是因为它的展示效果在某些情况下很糟糕,比方说如果有个人一口气刷了30多层楼被版主清理了,用户就会翻好几页没帖子,这显然不合适。
方案3,由于此问题影响最大的是楼层数超高的帖子,对楼层数少的帖子其实是否重定几乎不影响性能,而楼层数过多重定的时候的写入量也会非常庞大,对站点压力也会很大,此办法可以考虑作为一个管理工具做成帖子修复一类的按钮,但不宜作为默认配置自动执行。一定要默认执行的话就得考虑设计一个合理的调度算法,在适当且必要的时机进行触发,这个就复杂了。
而且重定楼层无法解决上述的回帖存在但无法展示的问题。
根据之前的讨论,通过优化标记逻辑和展示方式可以更好的解决这个问题,建议等待后续相关优化。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
登录 后才可以发表评论