是否存在反对使用 CMS 的争论？
我正在考虑从头开始重建我的网站，但这一次，使用 CMS。无论我走到哪里，人们都告诉我使用 cms，但直到现在我才真正考虑它。我的网站不太复杂。就工作流程而言，这是一个好主意吗？我是唯一会编辑该网站的人，因此，如果这只是工作流程和效率问题，我是否应该在网站变得非常大之前立即进行转换？
I'm thinking about rebuilding my website from scratch, but this time, using a CMS. Everywhere I turn people tell me to use a cms, but it's only now I'm really considering it. My site isn't too complicated. Is this a good idea in terms of workflow? I'm the only person who will edit the site, so if it's just a matter of workflow and efficiency, should I just convert now before it gets really big?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
当然，我想到了一些。
部署复杂性。许多 CMS 需要数据库，这意味着在某处运行数据库进程并备份该数据库以及站点的其余代码和资产。
需要更多的空间来保存管理器、框架、库等的 CMS 代码。
膨胀可能会发挥作用，CMS 可能而且很可能会实现您不需要的功能。
此外，任何 CMS 都会有某种限制，与大多数静态站点相比，有些事情会比其他事情更棘手。
Sure, a few come to mind.
Deployment complexity. Many CMSes require a database, which means running a database process somewhere, and backing that up, as well as the rest of the code and assets for the site.
More space will be required to hold the CMS code for the manager, framework, libraries, etc.
Bloat could come into play, the CMS may, and likely would, implement features you have no use for.
Additionally any CMS will have some kind of limitations, some things will be more tricky to do than others when compared to a mostly static site.
只需阅读代码即可。这通常就是您需要的所有论点。 （如果您的需求非常简单，并且不需要插件，也不需要自己编写任何代码，那么我仍然会使用 CMS）
Just read the code. That's often all the arguments you need. (If your needs are really simple and you don't need plugins and you don't need to write any code yourself I'd still use a CMS, though)
如果您的网站主要是设计展示，并且其中没有真正的内容，那么 CMS 只会阻碍您并使事情变得更加困难。
否则，它大部分都会有帮助。
If your site is mainly a design showcase, and doesn't have real content in it, then a CMS will only get in your way and make things harder.
Otherwise, it will mostly be of help.
连同其他人的发言。如果它只是一个小站点，您不一定需要 CMS，但如果您希望将来在客户项目中使用 CMS，为什么不现在就开始呢？
Along with everyone else's statements. If it's just a small site you don't necessarily need a CMS, but if you are wanting to use a CMS for client projects in the future, why not start now.
部署。如果您要对站点进行一些重大更改或测试某些内容，您可能希望使用数据库的开发副本在本地进行尝试。完成后，如何将所有内容都转移到实时站点而不覆盖（例如）自创建开发副本以来在实时站点上所做的评论？
专业化。 CMS 在某些方面非常有用，但在其他方面却很糟糕。如果您想向网站添加更复杂的功能怎么办？一开始它可能是一个插件或模块，但很快您就编写了所有这些代码，并且您意识到您应该只使用一个框架并自己构建 CMS 部分。
Deployment. If you're doing some big changes to your site or testing something, you'll probably want to try it out locally with a development copy of the database. Once you're done, how do you get everything to the live site without overwriting, say, comments that were made on the live site since you created a development copy?
Specialization. CMS's are great for some things, but they're bad at others. What if you want to add more complex functionality to your site? It might be a plugin or module at first, but soon you're writing all this code and you realize you should have just used a framework and built the CMS part yourself.
如果它是一个简单的静态网站，只有一个编辑器，并且没有任何使用复杂功能的愿望，并且您对选择的网络语言有足够的信心，那么就去吧。即使你感觉不够自信，这也应该是一个很好的挑战。
编写一些小模板，以便您可以将代码与设计分开，有一些简单的方法来添加文章或博客文章或其他内容 - 它可以像包含目录中的文本文件一样简单。
使用 CMS，即使在现代且相当可用的状态下，也需要更多的硬件资源。并且可能会有一个陡峭的学习曲线。当新漏洞出现时，还需要维护和勤奋地应用安全补丁。另一方面，CMS 可以让您快速启动并运行一个基本站点，并且如果您想丰富它，还可以根据您的需求进行扩展，因为您可以使用其各种现成的插件和扩展。您想要通过 OAuth 登录的用户发表博客评论吗？没问题。 RSS？有一个扩展。
最重要的是，如果这是一个简单的静态站点，只有一个编辑器（如您所描述的那样），那么设置一些代码来运行它应该很简单。您将在模板设计上花费与自定义 CMS 模板一样多的时间，避免 CMS 所需的初始学习曲线，并且不必过多担心现代 CMS 所需的资源和维护。但是，您自己编写或集成的内容将在功能和未来想法方面受到限制。
If it's a simple static site with a single editor and without any aspirations of using complicated functionality and you feel confident enough in your web language of choice, then go for it. Even if you don't feel confident enough, it should be a good challenge.
Write some minor templating so that you can separate your code from your design, have some simple way of adding articles or blog posts or whatever - it could be as simple as including text files from a directory.
Using a CMS, even in their modern and quite usable state will require more resources, hardware-wise. and will probably have a steep learning curve. It will also require maintenance and dilligent security patch application as new vulnerabilities appear. On the other hand a CMS can get you up and running with a basic site quickly, and grow with your needs if you feel like enriching it, as you get to use its large variety of ready made plugins and extensions. You want blog comments with users logging in via OAuth? No problem. RSS? There's an extension for that.
Bottom line is, if this is a simple static site with a single editor as you describe it, it should be trivial to set up some code to run it. You'll spend as much time on its template design as you would on customizing a CMS's template, avoid the initial learning curve a CMS requires, and not worry too much about the resources and maintenance a modern CMS requires. You will, however, be limited in functionality and future ideas by what you can write or integrate yourself.
这在一定程度上取决于网站的目的。
如果这是一种获取网络上发布信息的手段，那么采用 WordPress 之类的工具将很快让您上手，并提供许多额外的功能，这些功能需要花费相当多的时间来构建 - 例如统计数据、提要、在共享网络托管包上设置自托管需要执行一些基本步骤，例如创建数据库和解压缩文件等，但实际上相当简单。您可以将管理网站所节省的时间集中在其他事情上，从而发挥作用或做一些与其他人不同的事情。
但是，如果您的目的部分是为了学习开发功能的经验，或者您有标准 CMS 中没有的不寻常需求，那么就需要开发自己的功能。
It depends somewhat on the purpose of the site.
If it is a means to an end of getting information posted on the web, then adopting something like WordPress will quickly get you going, and provide lots of extra functionality that would take a fair amount of time to build in - e.g. stats, feeds, remote publishing etc. There are a few basic steps you'll need to go through setting up self-hosting on a shared web-hosting package e.g. creating the DB and unzipping the files etc but fairly straightforward really. And the time you save administering your website can be focussed on other things where you're making a difference or doing something different to everyone else.
However if your purpose is in part the learning experience of developing the functionality or you have unusual requirements that aren't in a standard CMS, then there is an argument for developing your own.