页面发布

[Discourse]

本指南涵盖了如何在 Discourse 上使用页面发布功能。此功能允许 Staff 用户将主题转换为具有自定义样式的独立静态页面。示例包括服务条款和隐私政策页面。

所需用户级别：Staff

在 Discourse 上发布静态页面

页面发布功能允许 Staff 用户从主题创建独立静态页面。这类似于创建服务条款或隐私政策页面的过程。

摘要

本文档将涵盖：

• 启用页面发布
• 将主题发布为页面
• 取消发布主题
• 常见问题及解决方案
• 常见问题解答 (FAQs)
• 附加资源

启用页面发布

1. 导航至 Admin > Settings（管理 > 设置）。
2. 激活 enable page publishing（启用页面发布）设置。
   

登录时启用页面发布

若要使已发布的页面在用户未登录时可见：

1. 在 Admin > Settings（管理 > 设置）处激活 show_published_pages_login_required（需要登录才能显示已发布页面）设置。
   

发布主题

1. 转到公共主题的第一个帖子，然后选择省略号图标（…）。
   

2. 选择扳手图标。
   

3. 选择“Page Publishing”（页面发布）选项。
   

   

4. 将出现一个模态对话框，允许您确认 slug（可从帖子标题预先填充）并预览已发布页面的 URL。
   

   

要允许页面发布，必须禁用 secure upload（安全上传）站点设置。

:information_source: **对于托管站点，[安全上传仅限于企业版 (Enterprise plan)。](https://meta.discourse.org/t/secure-uploads/140017#enabling-secure-uploads-2)**

已发布的主题

• 如果勾选了 Public（公开）选项，将出现一个 public 标签。
  
  

  

• 已发布的主题将在标题下方显示一条通知，允许访问其发布设置。
  

  

已发布的页面

取消发布主题

1. 在通知下方选择 Publishing Settings（发布设置）。
   

   

2. 点击 Unpublish（取消发布）
   

   

3. 主题已取消发布。
   

   

常见问题及解决方案

登出后无法看到已发布的页面

确保在 Admin > Settings（管理 > 设置）中激活了 show_published_pages_login_required 设置。

向已发布页面添加 Discourse 标题

目前，静态页面旨在保持最小化，不包含典型的 Discourse 标题和页脚。

常见问题解答 (FAQs)

我可以将 FAQ 或关于页面设为公开吗？

您可以创建一个包含所需内容的新主题并将其发布为页面。更改站点设置中的链接，使其指向这些新页面。

如何自定义已发布页面的外观？

使用 HTML 文档结构和相应的 CSS 选择器，在 Admin > Customize > Themes > CSS（管理 > 自定义 > 主题 > CSS）下应用自定义样式。

附加资源

• Making custom CSS changes on your site
• Secure Uploads

[downey (Michael Downey)]

I still need to try this out first hand so the following may not be grounded in reality, but:

It strikes me that this permission model sets up a scenario where you always see two copies of the pages’ content – one in the relevant Discourse category, and one in the published pages themselves. This of course seems duplicative if you’re wanting to publish pages for the general population that is similar to, or identical to, your Discourse user base.

OTOH, if pages had the “world readable” flag available, you could then restrict who can see/edit them to a small group, and the only place the content would be available to other Discourse users would be in the published links themselves.

(I’m thinking of a use case of a “documentation site” here.)

Otherwise, I’m pretty excited to test things out!

[nathank (Nathan Kershaw)]

Awesome stuff, and thanks again for listening to your users. I love the ‘lets make this better for us all’ vibe that Discourse has! We’ll make heavy use of this.

When discussing one use (patching up an install that went a bit awry), another user pointed out a remaining bit of icing that could do with going on the cake:

@Paul_King

not sure why FAQ is omitted from sign up dialog, but you can also set this url here as well - though not sure purpose of this feild/what otherwise links to it if not included in signup dialog?

Hey, is there any way to include the ability to make /faq and /about public as well, as they are currently hidden in Login Required sites. We can of course use the existing functionality that you’ve just released for /faq by making our own, changing the link in settings, and explicitly linking to it. However, this is not pretty and the existing navigation to it remains hidden. We can’t do that at all for /about of course.

[core]

Something that would go nice with this feature is to make publications onebox-compatible such that people could easily share the content.

[DanDevine]

Please excuse my ignorance, as I am very much a beginner in the HTML/CSS space… however, how would we go about applying our theme colour choices to published pages. At its simplest, I’d like to use the dark background/white text to give the published pages the same darkmode experience as accessing our forums.

Is this already in the product, or do I need to play with HTML/CSS? If the latter, could anyone give me some pointers in the right direction? Thanks!

[j.jaffeux (Joffrey Jaffeux)]

@nathank

Hey, is there any way to include the ability to make /faq and /about public as well, as they are currently hidden in Login Required sites. We can of course use the existing functionality that you’ve just released for /faq by making our own, changing the link in settings, and explicitly linking to it. However, this is not pretty and the existing navigation to it remains hidden. We can’t do that at all for /about of course.

Can you make this a separate feature request please? This is not related to page publishing, as in I wouldn’t have to change anything related to page publishing to make it possible. I do agree it would be better if all these “static” pages could have more or less the same behaviour, but there are multiple solutions here (do nothing? add site settings? migrate these to page publishing?), so we might want to have a dedicated topic for this.

[Terrapop]

GTM not loaded on published pages? Would be nice.

[RGJ (Richard - Communiteq)]

@j.jaffeux

but wouldn’t that cause error with other themes trying to load code which is not available?

Hmm that is a really good point.

Just trying to think of a solution here… would it work if type="text/javascript" and type="text/discourse-plugin" were treated differently? The API needs the latter, right?

[j.jaffeux (Joffrey Jaffeux)]

Yes I think we already support having a text/javascript in the theme fields, so there are certainly solutions in this area.

[Terrapop]

That would be great.

[pfaffman (Jay Pfaffman)]

@j.jaffeux

at the moment page publishing is not designed to support theme components or anything using plugin api and especially decorateCooked.

So it’s currently impossible to have responsive published pages, and this site particularly wants

1. images made available when sharing to public media, and
2. responsive/resizing images displayed, especially on mobile–oh, mobile could just resize the image with CSS–that should work, right?

[syl]

+1 for having the Discourse header in published pages. I’m missing my website logo, custom header links and beloved hamburger menu

Another oddity: in posts, my lightboxed images open in a nice popup, whereas in published pages, they open in a new tab…

[pfaffman (Jay Pfaffman)]

I think what’s needed is a set of theme components that add such. The last client I had to use this wanted the topic creator removed. I think it’s hard to guess what will meet people’s needs for this!

[RGJ (Richard - Communiteq)]

Are there currently any ongoing efforts for adding “simple” (non-API) Javascript support to published pages? Or should we forget about this near- to mid-term ?

[ddf]

Can i display external non-Discourse JSON on this page? Because we can’t use php code here and discourse strip most of html so i do not know how to do it…

[Ed_Bobkov (Ed)]

我遇到一个已发布页面的问题：代码块的复制按钮在已发布页面上不可见。截图：Screenshot by Lightshot

有人能复现这个问题吗？有什么解决方案吗？

[RGJ (Richard - Communiteq)]

感谢 @riking！

确实，当 text/javascript 出现在主题组件的 header 或 footer 中时，它会在已发布的页面上执行。

[hellekin]

哈哈！看来有一种取巧的方法可以让某些主题组件与页面发布功能协同工作。

我正在研究为已发布的页面添加一些页眉/页脚，主题组件似乎是可行的方案。但实施一个可能在不久的将来就会失效的功能似乎不太妥当。

@riking，看起来在 header 或 footer 中使用 text/javascript 类型并在已发布页面上生效似乎是无意的。这会被“修复”掉，还是会被“利用”来扩展已发布页面的功能？

DiscPage 的作者 @syl 提到了 利用页面发布功能重新实现 DiscPage 插件 的可能性。@syl，你还有这个打算吗？@riking，你认为整合这两项功能阻力最小的路径是什么？

[syl]

@hellekin

@syl，DiscPage 的作者，曾提到使用“页面发布”功能重新实现 DiscPage 插件的可能性（https://github.com/sylque/discpage/issues/8）。@syl，你还有这个打算吗？

不幸的是，“页面发布”功能无法满足我的需求。若要使用它，我需要发布的页面：

1. 显示在正常的 Discourse 布局中，即带有标准的 Discourse 页眉（就像 服务条款 和 隐私政策 那样），以及
2. 像普通（带样式的）主题一样渲染，即支持 bbcode 和插件。

[hellekin]

在此期间，我使用了 Discourse 默认的自定义功能：

1. 识别新增的元素，例如通过 published-page-footer-links CSS 类。
2. 自定义 CSS 以默认隐藏该元素，仅对已发布的页面显示。
3. 在 Footer 区域添加该元素。

2. 在 CSS 中添加：

/* 仅在已发布的页面上显示页脚链接 */
.published-page-footer-links { display: none; }
.published-page .published-page-footer-links { display: block;}

3. 在 Footer 中添加：

<nav class="published-page-footer-links">
大家好！这是已发布页面的页脚！
</nav>