Chris 之前发布了一篇文章，介绍了样式指南在团队流程中的位置。我非常喜欢这篇文章，因此决定分享我对内容管理系统在流程中位置的看法。
我写这篇文章的另一个原因是，这是一个常见的争论点。我合作过的不同团队更喜欢在流程的不同阶段集成内容管理系统。一种方法优于另一种方法本身并没有错，但在深入项目之前，进行讨论并做出决定是一个好主意。
CMS优先方法
这种方法将 CMS 放在流程的最前端。例如，假设您已经知道 WordPress 将作为 CMS，并且您有一个基本主题，该主题循环使用您在项目之间使用的许多常用功能和模板，但设计和样式是开放式的。或者，假设您购买了一个高级主题，并计划从那里修改前端。这关乎提前完成框架。
这很好。我之前使用过一个简单的基本 WordPress 主题，也见过其他人使用 WordPress 子主题 做了一些很棒的工作。但话说回来，我老实说没有参与过任何将内容管理系统的集成真正放在流程首位的项目，其中所有后端代码都是首先完全开发的；在集成之前，总有一些程度的前端工作是在前端完成的，这让我们转向下一种方法。
一次性方法
前端？后端？不，这里没有真正的区别。
例如，我们知道 WordPress 需要大量的 PHP 模板、循环和函数来输出网站的内容和视图。此方法与前端标记一起构建这些内容。
这种方法有很多好处。首先，它可以节省大量时间。与其先编写所有 HTML、CSS 和 JS，然后将其拆分为各种 PHP 代码段，不如一次性处理所有内容，并消除流程中的一个完整步骤。如果您在一个小型团队中工作，并且需要在一个快速周转的项目中承担任务，那么这非常理想。
但它也存在一些缺陷：想象一下，编写了一堆复杂的后端代码，结果项目范围发生了变化，导致代码变得过时。这当然取决于您对更高级编程语言的熟悉程度和技能水平，但我发现修改 HTML 和 CSS 比修改 PHP 之类的东西要容易得多。在这种方法中，出现失误可能会造成巨大的时间浪费。
CMS最后方法
这里的区别在于，使前端开发成为后端开发的强制性和独立交付成果。与其提前处理 CMS 或在项目开始时将前端和后端结合起来，不如将它们分成不同的交付成果，以防止事情变得过于混乱。
我发现这种方法在分阶段处理项目时非常有用。例如，我喜欢 直接在浏览器中设计 的想法，因为它让我可以自由地进行播放和实验，而无需担心在创建样机时后端开发的限制。
这里也存在潜在的缺陷。首先，分阶段工作时，事情可能会在翻译过程中丢失。这有点像古老的传话游戏，在将短语低声传递给一长串人之后，最终得到的短语与最初的短语不同。还有如何维护项目的问题——我们是在前端还是后端交付成果中进行更改，以及如何使它们保持同步？答案因项目而异。
权衡选择
虽然我坚定地站在为合适的项目选择合适方法的一边，但我确实发现自己越来越频繁地将 CMS 放在最后，即使 CMS 已经被选择。我有一个 我用于 WordPress 的样板项目，它创建了这些框并使用 Grunt 自动执行在它们之间传输资产的过程。如果我没有长时间碰过它，我会认为这是一个毫无掩饰的存储库推广。如果您觉得这种东西方便，请随时拆解它并使用它。
您怎么看？您是否有集成内容管理系统的特定方法？这是否对您很重要？这似乎是经常出现的事情，但听听不同的人和团队如何处理它会很有趣。
我倾向于使用“前端优先”方法。如果我知道内容需要放置在哪里，并且了解我可以使用 CMS 将其导入，那么对我来说，首先让前端正常工作是有意义的。从那里，只需要用来自 CMS 的内容替换虚拟数据即可。
我倾向于使用“前端优先”方法。如果我知道内容需要放置在哪里，并且了解我可以使用 CMS 将其导入，那么对我来说，首先让前端正常工作是有意义的。从那里，只需要用来自 CMS 的内容替换虚拟数据即可。
我也开始采用前端优先的方法。在 Illustrator 中创建线框图，然后将其构建为完整的模型。从那里，只需要编写 HTML、CSS 和 JS 即可。一旦到位，您就会确切地知道需要从数据库中提取什么内容，甚至在此之前，它还有助于数据库本身的结构。
我发现这种方法比从后端开始，然后意识到需要一些额外的数据要容易得多，这可能导致数据库需要重新构建，查询需要重新编写等。但话说回来，我通常只处理较小的项目，通常是自己或在一个非常小的团队中进行。因此，这种方法可能不适用于规模更大的项目和更大的团队。
我不确定我的流程属于哪个阶段。我一直构建信息架构来概述页面位置，然后构建内容库，这些内容库在每个页面上的内容方面遵循信息架构。它有一个足够宽松的格式，您可以轻松地创建自定义页面，同时仍然遵循内容库。
通过提前执行此操作，即使目前没有 CMS，我们也会确切地知道每个页面将包含什么内容、如何构建它以及是否存在任何变量。
我通常很幸运能有能力胜任的文案撰写者来输入文案，因此这通常与我构建模板同时发生，我们首先安装 WordPress，使用批量页面创建器创建页面，复制数据库，然后设置一个暂存站点，所有内容都进入暂存站点，并在需要时将其提取下来。
我从 CMS 开始，但它最终会变得更像“一次性”方法。作为一个独立工作室，我的流程通常是这样的
与客户会面以规划内容策略和架构。线框图通用布局。
使用 Google 文档开始收集内容——从长篇页面内容到特定格式的标语（例如，<15 个单词的销售标语）。
在他们执行此操作的同时，我使用 ACF 和 Timber 构建后端，并记录字段以匹配 Google 文档指南。
他们在 WordPress 中使用未设置样式的主题输入内容，而我则进行一些初始设计——样式磁贴等。
迭代数据库结构并构建前端和设计。
从那里到发布都非常线性。
我发现尽早将内容放入 CMS 可以简化以后的流程，此外，它还可以让客户更认真地考虑文案/媒体，并且他们将有更多时间将其整理好。这始终是一件好事。
Lara，这真是一个绝妙的方法！太多时候，网站所有者拥有一个没有内容的网站，或者更糟糕的是，他们希望将之前没有用过的文案转移过来，出于一些我很难理解的原因；而你必须逐渐让他们明白优秀内容、内容测试等的重要性。
我完全同意她的观点。对于小型团队或独立开发者来说，这绝对是最有效率的策略方式。如今，cmd 的意义在于将内容作为我们工作核心。我使用 grunt 和自定义 yeoman gem 来连接 angularjs 和 wordpress 以获得 spa 体验，并在 wordpress 及其自身优势之上使用指令。一旦你克服了使堆栈变得有用的丑陋性，它就会成为一个非常快速的流程。
也可以先从CMS开始。然而，我是一名PHP和Drupal开发者，我参与的项目都是围绕CMS设计的。过去，我通常会先构建前端，然后将CMS融入HTML模板中，但现在我倾向于先构建网站的功能，忽略其外观，然后将设计或HTML模板（如果设计师提供了）集成到CMS中。对我来说，这非常有效。这意味着在某种程度上，内容驱动着设计。
我个人始终偏好前端优先。我发现，在引入CMS之前先构建网站的骨架有助于简化构建过程。它允许我更好地识别通用/共享元素，确定哪些需要动态化，哪些需要静态化，开始思考缓存规则并尽早识别任何潜在的痛点/风险。然后，选择最适合该任务的CMS，并逐一插入内容。只要你对网站内容有相当的了解，就可以在没有最终设计的情况下完成大部分工作。我发现这是一个相当流畅的过程。
我开始更喜欢将网页的前端/后端部分构建为特定的可重用组件，逐个解决每个组件的问题，然后将所有组件集成到每个页面上作为最后一步。这样做在范围方面有很多好处，但确实需要花费更长的时间。
Laura，你的方法绝对相似，但通过Webydo内置的CMS，客户能够更新网站内容，从而在您和您的客户之间实现完全协作的体验。它从根本上消除了先有鸡还是先有蛋的难题，让你拥有绝对的创意控制权。
我总是先在我的电脑上编写整个前端，然后在发布前尝试将部分内容塞进CMS。理想情况下，如果出现更改（比如CSS更改），我会更新我的本地SASS，编译并上传到CMS。但实际上，我最终会在CMS上直接编写快速修复，从而使我的本地副本立即过时。这是一种糟糕的做法。我宁愿有一个CMS，让我能够在本地编写编译文件并将它们暂存到服务器；这样就永远不会手动触碰服务器……迫使你确保本地和服务器始终保持一致。我不知道，在理想的世界里……
我通常也更喜欢前端优先，但是由于项目范围不断扩大，以及人们没有做好准备，最终变成了同时进行，这也会导致代码变得像蜘蛛网一样混乱。
说真的，我需要让人们开始以组件而不是整个页面布局的方式思考……
我发现你的文章很棒。但是，我在Tech Legends上使用WordPress。不过，我喜欢通过阅读你的一些文章来玩弄CSS代码:-)
而且，我特别喜欢修复数据库！我想是之前的那篇文章……
如果我们讨论的是重新调整和重新设计现有的网站，那么选项、偏好或流程是否会发生变化？假设重新设计还将包括对内容、内容类型和信息架构的更改。
使用ImpressPages CMS，您可以使用“一次性”方法。拖放小部件，原地编辑内容。
“通过真正的内联编辑和拖放界面，轻松管理网站。按您所见编辑页面，而不是从某个隐藏的地方编辑。拖放图片、视频、投票、菜单，任何您喜欢的元素。复制粘贴，它们将始终与您的当前样式匹配。”
https://www.impresspages.org/
最近，我能够先使用CMS方法，因为我的客户确切地知道她想要发布哪些数据。
这很棒。能够构建CMS内容模型（使用CraftCMS），然后使用真实数据创建前端，这是一种令人愉快的体验。而且这是一个非常快的过程。
但是，如果客户还不知道在页面上显示什么内容，除了前端优先方法之外，就没有其他真正的选择。
答案是视情况而定。项目的目标是什么？
现有代码（前端和后端）能够满足多少项目目标，以及哪些需要定制开发？成本更高的部分应该优先考虑，并尝试降低其成本。构建一些疯狂的新js小部件——前端优先。与CRM和表单框架集成——让后端领先。
你将从其他地方获取多少代码？如果答案是很多，那么在与这些关键代码脱节的情况下进行开发将是一场灾难，在工作量方面也是如此。
我还认为，那些认为前端仅仅是指HTML、CSS和Javascript的人与那些也认为需要进行工作以创建可在CMS环境中使用的模板的人之间存在差异。因为如果不是这样，则需要另一个“前端-后端”阶段来集成两者。
我认为上面的Lara有一个很棒的流程。我目前的想法是建议内容（CMS）优先，但这更多的是出于我想要通过强调他们最需要帮助的内容来提高非政府组织客户成功率的愿望。
Ryan，我同意，在确定CMS是否应该是流程的第一步时，项目的目标很重要。尝试新的方法来提高效率当然很好，但最终还是要看您最熟悉什么。我一定会尝试Lara的流程，并希望能够将其集成到我当前的工作流程中。http://www.quicksilk.com