我很好奇，在不破坏 Discourse 更新（或至少尽量减少破坏）的情况下，我们能对 Discourse 进行多大程度的定制？这不仅限于界面，还包括调整布局、添加新功能等。
我非常喜欢 Discourse，但我知道自己迟早会想要实现或更改一些功能。我希望拥有自己的移动应用，而不是依赖 Discourse 的官方应用。我希望它更加定制化，并专门服务于我的社区。
我也不喜欢旧款手机显示难看的 Times New Roman 字体以及功能极度简化的 Discourse 版本。我理解技术总是在进步，但我怀疑我们是否真的需要回归那种丑陋的外观来表明某些功能已不再受支持？这可能会切断对某些可能已不存在、但对社区至关重要的功能的访问。
我还想定制不仅仅是界面以外的其他方面，实现新功能、调整布局等。基本上，我想利用 Discourse 的数据库和大部分“骨架”，使其尽可能贴近我自己的风格，而不是让人感觉“这只是一个换了颜色的 Discourse 论坛”。
我猜测通过组件、插件等方式可以进行大量定制，但我想知道其局限性在哪里？特别是在 Discourse 更新时，哪些定制内容可能会失效？
这正是我目前正在做的事情，作为一名拥有15年WordPress背景的用户，这感觉就像回到了过去。不过，在令人闻风丧胆的ChatGPT的帮助下，我开始学习一些东西，并发现如果你懂GitHub、会编辑文件、会使用CSS等，其实也没那么难。
是的，我使用 Git/GitHub，并且对工作流程有“基础”的了解（最近因为我在业余时间开发其他项目，所以学得更多）。我猜很多事情都可以做，但始终存在一个挑战：今天基于 Discourse XYZ 版本构建的内容，明天更新后可能会失效，这很令人沮丧，尤其是当你不知道哪里出问题时……
因此，尽量少进行自定义感觉更稳妥，但这样就不够“品牌化”。我想，这取决于你如何权衡哪一方面更有价值。
你用的是 ChatGPT 还是 Codex？我一直在 GitHub Codespaces 中使用 Claude Code CLI，体验非常流畅！而且，因为我把希望 Claude 执行的操作、行为方式等全部写在 CLAUDE.md 文件中，它很少会产生幻觉，或者说幻觉程度没那么严重。随着我发现更多希望 Claude 做或不做的事情，这个文件也在不断增长。
这应该只需在主题中添加一行 CSS 即可更改。
只要你使用现有的扩展钩子，定制空间相当大。
你看过 Discourse customers | Discourse - Civilized Discussion 和 https://discover.discourse.com/ 上的站点吗，比如 Epic Developer Community Forums 和 https://community.robotime.com/ ？
说实话，我取消了 Claude 的订阅，因为它无法生成图片，而且与 OPEN Router 的兼容性不佳。我当时订阅了很多服务，所以除了 GPT 之外，我把其他的都取消了。
我只是将其作为整体变化的一部分提及：从一个原本运行良好的平台，突然变得无法使用，或者至少不再像以前那样运作。正因如此，我开始避免访问使用 Discourse 的论坛。我知道我最终需要升级手机，但这台目前还能用，所以……
这个看起来相当不错：https://forums.unrealengine.com/
已保存到我的笔记中，以备将来参考。谢谢！
还有一些其他看起来很有趣的论坛，但我总觉得能认出它们是 Discourse。我知道我是在过度思考而不是动手建设，但我只是好奇我们究竟能在多大程度上对其进行定制？正如我所说，我认为有很多事情可以做，尤其是在用户界面方面。我想知道在 Discourse 更新后，这些功能是否还能正常工作？我得做一些测试。
这就是自我实现的预言 
我几乎从来不需要图片，所以这对我来说从来不是问题。而在我极少数需要图片的时候，我会求助于 ChatGPT。但有一半的时候，取决于我问什么，它生成的结果根本和我脑海中的想法沾不上边，所以我最后还是在 Photoshop 里自己动手做。
不过，Claude Code 对我帮助很大，速度超快。
如果 ChatGPT 能满足你的工作需求，那它绝对是合适的工具。只要好用，这就够了。
倒不是我觉得 Discourse 看起来有多糟糕，我只是希望在其中融入更多我自己的风格，哪怕是它的结构、某些功能的实现和展示方式。
再说，也许我想得太多了，但我确实需要做一些测试，看看效果如何。
我觉得它在很多主题等方面都停留在过去，我其实之前还为此大发牢骚过
另一个问题是论坛看起来都会差不多，因为它们的本质就是标题列表。看看 Facebook、Reddit 和 X，它们的话题卡片在某种程度上都长得差不多。
我不是专家，但在我看来，Discourse 的可定制性非常高。不仅如此，开发者似乎还在不断创造新的、更简便的定制方式。Discourse 似乎也很谨慎，会在即将发生可能影响用户定制内容的变更时提供警告。
[quote=“alltiagocom, post:1, topic:408829”]
基本上，使用数据库和 Discourse 的大部分“骨架”，并将其尽可能贴近我自己的风格，而不是让人觉得“这不过是另一个换了颜色的 Discourse 论坛”。
[/quote]\n
完全有可能创造出远超“另一个换了颜色的 Discourse 论坛”的作品，事实上，仅使用官方开发团队提供的主题组件和插件就能实现如此多的更改，这让我惊叹不已。正如支持人员会告诉你的那样，界面上的所有内容都可以通过 API 访问，这意味着如果你想“使用数据库和 Discourse 的大部分‘骨架’”，没有任何东西能阻止你。
话虽如此……我喜欢你在另一个帖子中提到的关于构建社区、分享以及为人们提供分享空间的想法。这正是我试图做的事情的基础。你还提到你是一名音乐家，也许也是一名喜欢软件开发的音乐家。一旦你构建了一个完全定制的网站，你将负责维护它，并且各种事物（与 Discourse 相关的或其他方面）可能会出现故障，你将不得不花费自己的时间或付费请人来修复。
开启一些新话题。每个话题只使用一个单一的想法。告诉论坛你想要什么，并询问如何实现你的想法的建议。将其分解为单个功能将有助于人们头脑风暴解决方案，同时也能让你采取更结构化的方法，并更清晰地定义你的目标。
它是专为 Discourse 构建的 AI
另外……别觉得被冒犯，把这当作关于你自身时间价值的建议，考虑聘请专业开发者。这里有几位常在此论坛出没的开发者，而“市场”类别正是为此类咨询而设，你可以在那里提出你的想法，开发者可以竞标执行这项工作
是的，我总是说，只要是数字化的东西，总有一种方法可以实现。所以我想我需要对此做一些研究，一步一步来。我想下一步就是把我的 Discourse 论坛重新上线。我曾经安装过它，但后来决定把它下架，直到我准备好真正专注于它为止。
没错，从 2001 年左右开始。但最近，尤其是在 Claude Code 的帮助下，我能够为自己创建一些有用的工具，并最终也向其他人发布了一些。
我并不想成为一名专业开发者，也不想在这上面花太多钱，但这绝对是我喜欢做的事情。一直从事创意工作可能会让人非常疲惫。而像软件开发这样更具二元逻辑的事情，则能带来很大的满足感。
完全没有被冒犯。任何反馈都是有价值的。我同意，我越来越多地在分析自己的时间价值，考虑哪些事情不值得花时间去做而应该雇别人来做，以及哪些是我真正喜欢做的事情，无论需要花费多少时间和精力。这就是为什么开发新工具对我来说如此有成就感。这实际上是我乐于看到事物成为现实的时间，所以从来都不是浪费的时间。
是的，互联网已经变得非常“千篇一律”。我认为这主要是因为人们更注重功能而非风格。这并不是说我觉得这有什么问题，但拥有独特性同样重要。
我也赞同你的另一个话题。Discourse 还有很大的成长空间。我喜欢 Discourse 的一点是，它确实感觉像一个正在发展的平台，团队在这里与我们互动，分享路线图等。它不像是一个没有人知道发生了什么的内卷平台。这一点我非常看重。
100% 是我用过的最好的后端平台之一。
限制非常少。主要的限制在于无法覆盖模板，你需要通过插件出口（Plugin Outlets）向现有视图添加新内容。不过，结合一些 CSS 通常就能达到目的。
你可以创建新路由，并完全控制其布局。
后端更加灵活。
因此，尽可能使用官方 API，这样重构的工作量会更少，但你永远无法完全消除维护工作。
指望零维护是不合理的……只需看看我的 GitHub 账号和一些热门插件，你就会看到大量标记为“兼容性：”的提交
良好的做法是维护一个预发布服务器（staging server），以便测试升级并查看自定义内容是否出现错误——网站定制化程度越高，就越需要某种形式的预发布实例——尽管使用开发实例也能提供帮助。
如果不了解具体细节，很难说某种自定义有多“安全”……但一般来说，自定义得越多，需要进行的维护工作就越多。
如果您在插件出口处添加类似自定义组件的内容，或者完全替换 Discourse 组件……通常这些应该能继续正常工作，因为您是将自定义代码插入到扩展点中（我们尽量保留这些扩展点，因为很多人都在使用它们）。
在 CSS 中，您应尽可能利用现有的 --variables（CSS 变量）来更改样式，因为有时我们需要更改内容结构，但即使这样做，我们仍可以重用相同的变量。
因此，这是一种更安全的方法：
.d-header {
--title-color--header: red;
}
这种方法的安全性较低：
.d-header {
.extra-info-wrapper .topic-link {
color: red;
}
}
我们一直推动平台远离那些更容易出错的旧自定义方法，例如模板覆盖和 modifyClass 的使用。我们还在致力于开发更稳定的 API……但所有东西仍然需要不时进行一些维护。
谢谢你的反馈。
我觉得我真的需要好好考虑一下那个预发布服务器。这绝对是个好办法。
目前我认为第一步是重新安装 Discourse，创建内容，然后到时候先从那些不需要大改、可以用组件完成的简单事情做起。看看能走多远。然后再开始考虑预发布服务器的事。
谢谢！
关于变量的那个提示确实很有价值。
我想我只需要找个时间坐下来，列出所有我想更改或实现的功能，然后逐一处理，先从那些可以通过组件修改的功能开始，看看能推进到什么程度。
确实是这样，
我现在是discourse进行系统性稳定工程，
然后我使用了部分主题组件和自己写了部分主题组件来进行自定义，以达成符合我的当地用户的文化习惯。