对我来说,在“设置/法律”中,指向独立托管的常见问题解答页面的 URL(以及 presumably 服务条款和隐私政策页面的 URL)似乎在论坛主页上无法正常工作了。
我尝试了几个指向其他网页的测试 URL,但它们现在似乎都没有任何反应。在我的论坛主页上,始终显示的是 login_required.welcome_message 文本,而最近之前,在该指定 URL 处的常见问题解答页面本应显示出来。
如果这些自定义页面作为 Discourse 内的帖子发布并设置为公开,我仍然可以在“需要登录”的对话框中手动添加指向这些页面的链接。
1 个赞
simon
2021 年8 月 11 日 21:45
2
这个问题您那边解决了吗?在我的测试站点上,我发现可以将 tos url 和 privacy policy url 设置指向外部网站。我没有注意到外部链接在站点的注册弹窗或关于页面中被忽略的问题。
1 个赞
嗨,Simon
这个问题对我来说一直没解决,所以我最终只好把常见问题解答(FAQ)里的内容(它实际上是网站内一个已公开发布的页面)直接复制粘贴到欢迎对话框的文本中。虽然效率不高,但能解决问题。
有趣的是,在点击注册时,注册对话框中指向服务条款(TOS)和隐私政策的链接(同样是已公开发布的页面)仍然可以正常跳转——所以我的问题似乎仅限于着陆页。
2 个赞
simon
2021 年8 月 12 日 17:32
4
您的意思是,您的 FAQ 页面是一个已发布为独立页面的 Discourse 主题吗?如果是的话,我还没有尝试过这样做。
嗨,是的,我正是这个意思。
我别无选择,因为在一次升级过程中,所有预置的话题都消失了。之前一直运行正常,直到最近的升级导致它们无法从首页正常显示。
simon
2021 年8 月 12 日 23:14
6
哦,不。我本来想问您为什么使用已发布页面作为服务条款(TOS)和常见问题(FAQ)页面,但现在明白了。不过,为这些主题使用已发布页面似乎并非理想方案。我相当确定可以重新创建预置主题。它们是由一些隐藏的网站设置控制的。以下设置可用于重置服务条款和隐私主题:
tos_topic_id
privacy_topic_id
我不确定设置 FAQ 主题 ID 的设置名称是什么,但如果您希望进行此更改,我们可以帮您找到该设置。据我理解,您需要在您的“工作人员”分类中创建新主题,然后将这些隐藏网站设置指向对应的主题 ID。
谢谢 Simon,这很有用。
如果能找到 FAQ 主题 ID 就更好了——至少对于其他遇到同样“预置主题混乱”问题的人会有帮助。
关于落地页的问题,几天前我把这个难题转化为了一个优势:我生成了一个更简短的 FAQ 版本(主要是为了帮助那些不确定自己是否找对地方的人),并在底部添加了链接,指向完整的 FAQ 员工主题、服务条款员工主题以及隐私政策主题。
在此之前,我的 FAQ 内容就是整个落地页(替换了欢迎对话框的文本)。
1 个赞
simon
2021 年8 月 13 日 16:31
8
FAQ 主题对应的站点设置名称是 guidelines_topic_id。
我在该帖子中找到了相关信息:https://meta.discourse.org/t/how-to-fix-faq-privacy-policy-and-tos-page/179013/3。
建议先检查旧的条款(TOS)、隐私政策和 FAQ 主题是否仍然存在。你可以通过在 Rails 控制台中查看以下每个站点设置的值,然后在界面中查找这些主题是否已被删除:
tos_topic_id
privacy_topic_id
guidelines_topic_id
获取每个设置返回的 ID 后,你可以通过访问 /t/-/<来自设置值的主题 ID> 来尝试查找已删除的主题。如果主题存在,应该可以通过用户界面恢复它们。如果这些主题不存在,我的推测是可以在“员工”分类中创建新主题。之后,你就可以将这些新主题 ID 设置为上述各个设置的值。我本人尚未尝试过此操作,但如果你不确定是否要在自己的网站上进行更改,我可以在本地开发环境中进行测试。
谢谢西蒙。
听起来很合理。我需要先让自己对 Rails 有足够的了解,才能应对这个建议。
nathank
(Nathan Kershaw)
2021 年12 月 28 日 20:46
10
Paul,你进展如何?我记得这个问题困扰你很久了。
我自己刚刚也遇到了同样的问题,不小心使用了 delete_all 来处理 FAQ/指南主题,而且过了一段时间才发现。这篇帖子非常有帮助:
Interesting. How did you manage to delete those topics? You shouldn’t be allowed to delete them in the UI.
First, let’s see if the topics are really gone.
./launcher enter app
rails c
Topic.with_deleted.exists?(SiteSetting.guidelines_topic_id)
Topic.with_deleted.exists?(SiteSetting.tos_topic_id)
If the topics are really gone, create two new topics in the Staff category and assign the topic ids in the rails console to the site settings.
SiteSetting.guidelines_topic_id = 4711 # replace with t…
如果你需要帮助,我很乐意指导你完成。
1 个赞
Paul_King
(Paul King)
2021 年12 月 29 日 11:29
11
nathank:
保罗,你进展如何?
我从未找到那些丢失的预设主题,但我仍然对我的解决方法感到满意,因此没有动力去努力尝试——基本上它们现在是常规可编辑的员工主题,标记为公开,我可以并且确实会不时更新它们。
nathank
(Nathan Kershaw)
2021 年12 月 29 日 18:55
12
假设您拥有服务器的root访问权限,修复只需5分钟即可完成,而且您不会丢失任何有用的主题内容。
它所做的只是识别那些主题为要使用的主题。
我承认我对使用 Rails 一无所知,但我能够使用数据探索器查询(根据另一位用户的建议,我现在似乎找不到)来确认原始主题确实已消失。
据我所知,我的设置现在似乎“知道”要使用哪些员工主题,即使我用来实现这一目标的方法(我现在也似乎找不到!)不像 Rails 编辑路线那样硬核。
2 个赞