[Idea] 技术会议内容管理系统

开源松
1

大家好，我是Frost Ming，也是自 2021 年以来 PyCon China 大会网站的维护者。在这三年的维护过程中，遇到了以下几个痛点：

  • 信息收集渠道分散，有问卷、石墨文档、GitHub repo等
  • 格式不统一，用户填入信息，然后粘贴在石墨文档中，格式有各种问题，我需要手动改成标准 Markdown
  • 图片处理，用户上传图片尺寸不一，大小不一，这些都是我需要动用Photoshop手动处理。
  • 网站不受重视，往往最后一刻才会更新网站，更新负担大。

简单回顾一下PyCon China 网站建设的历史，我接手的时候，还是用的一个用了好几年的基于 Jinja + JSON file的静态生成系统。简单试用了一下发现无法运行在新版Python和依赖下。于是2021年我首次尝试了用前端技术栈 NextJS，后来志愿者反馈要使用Python 技术栈，2022年和2023年都用的一个更加成熟的静态生成器 Lektor 。但其实这些工具都没有解决上面的痛点，主要是更新负担大。

于是今天有了一个用Python技术栈做一个网站内容管理系统的想法。目标是今后的信息收集都以这个内容管理系统为第一顺位，让其他的组委员成员也用起来，取代之前的更新负担都放在网站工程师几人之上。所以希望能做好这个系统，好让组委会不必求助于问卷等平台。

我粗略列了一下功能列表，发现这不是我一人能承担，得知贵站在搞开源松，觉得这可能是一个好的项目。

（Notion，国内访问可能有问题）

不知大家反馈如何，欢迎交流，此处 @greyli

2 个赞
2

我想参与（GitHub：YogiLiu） @frostming

1 个赞
3

支持！PyCon China 的网站确实是一个老大难问题。而且每年网站都在办会的那一阵才能访问我也是不知道说什么……哈哈扯远了。这个项目很适合放到开源松一起来开发。有两点想法：

  • 我们不如以开源 Conference CMS 作为出发点来实现。这样不仅 PyCon China 可以用，其他会议，包括代码厨房沙龙都可以用。
  • 建议使用 Flask 作为主要框架。这个社区前身就是 HelloFlask 社区，大家对 Flask 相对更加熟悉。

P.S. 作为原 HelloFlask 现代码厨房社区的版主，怎么可以用「贵站」这种词语 :stuck_out_tongue:

1 个赞
4

支持！

5

改用静态Host以后没有这问题了，这一年都能正常访问的，我保证。所以这也是为什么网站架构是动态CMS + 静态生成。这个CMS允许只有几天可（让组委会）访问

嗯，就看有多少是PyCon专有的需要，看上去还好

没问题，只要本站参与的人多，就用Flask

其实PyConUS一直用的一个基于Django的CMS系统 https://wagtail.org/ ，没有用过，不知道是否会造轮子

1 个赞
6

没用过，但我可以尝试写一份调研，看看是否适合复用。

2 个赞
7

那我们就从 Sprint 2 开始安排任务。我等下先把 Sprint 2 的报名话题创建出来

8

Sprint 2 报名已创建：代码厨房开源松 Sprint 2 召集

9

目前了解到以下几个 Star 数量较高的 Python CMS，准备从这几个着手调研：

欢迎补充。

1 个赞
10

Nice, quokka 看起来停止维护了，所以这个就可以忽略

11

是的，但是 quokka 是这里面唯一号称轻量级的 Flask CMS，其他几个都是基于 Django 的，所以我觉得可以参考一下，或许可以由社区把这个项目接手过来。

12

感觉不用花太多精力调研？我们要做的是 Conference CMS，和单纯的 CMS 会有不少差别（或者说会有很多 add-on features）

13

这个项目是通过定义好的模板生成静态文件，然后直接把静态文件通过服务器代理出去？

14

同意，所以调研的重点应该是现有项目能不能满足我们的需求，或者允许我们去扩展我们需要的 add-on features。

1 个赞
15

服务器不负责serve生成好的网站，只负责把网站文件推送出去(VPS/GitHub/anything)

所以这个服务可以平时不起用，只在需要收集信息修改网站的时候启用。

1 个赞
16

明白了，谢谢

17

仔细研究了一下，现有的 CMS 系统基本无法解决当前的痛点：

  • 基本不支持 SSG，需要一直运行一个 HTTP Server 来保证网页的正常运行。
  • 只注重于向外输出内容，基本不会有数据表单的功能，可以在当前基础上开发，但我觉得无异于开启一个新项目。

像 @greyli 说的，当前的 Conference CMS 和传统的 CMS 差异很大，功能上交集也不多，深入调研的意义不大。

另外，我觉得这个 Conference CMS 更像一个 SSG 系统，所以我也去看了一些 Python SSG 的项目。SSG 的项目和目前需求最大的出入就是缺少服务端，例如像数据表单之类的是需要一个服务端才跑起来的，并且这里还有一个痛点就是 SSG 项目的更新需要网站工程师参与。

不过 SSG 的两个问题我认为可以有以下解决方案：

  • 针对缺少服务端的问题，可以通过引入 Serverless 的方案解决，比如 Firebase / Supabase 之类的服务，这在前端有成熟的技术方案（Astro）；
  • 针对项目更新依赖网站工程师的问题，我觉得这其实是一个项目管理的问题，比如可以把组委会志愿者编辑的文档单独作为一个 Git 的子仓库引入到 SSG 项目中，并通过 GitHub Action 来触发更新即可。

总结就是：可以重新写一个，不算造轮子。

此处 @frostming

2 个赞
18

和我粗略的印象一致。其实CMS+SSG的架构我是参考了 Typlog 三週年 - Just lepture

想法可行，那就干起来吧。 这和以往的博客、Todo项目不太一样，不是重复和学习，而是创造。

3 个赞
19

想参与！:person_raising_hand: GitHub: FarmerChillax

20

如果前端用 Vue.js 的话，大家有推荐的 UI 框架吗？

cc @tkzt