内容管理系统的版本控制?

发布于 2024-08-29 01:32:29 字数 1278 浏览 4 评论 0原文

我在我们编写的 CMS 应用程序中具有以下目录结构:

/application
/modules
   /cms
      /filemanager
      /block
      /pages
      /sitemap
   /youtube
   /rss
/skin
   /backend
      /default
         /css
         /js
         /images
   /frontend
     /default
         /css
         /js
         /images

应用程序包含特定于当前 CMS 实现的代码,即该特定 cms 的代码。 模块包含我们跨项目共享的可重用代码部分,例如使用 youtube 或 rss feed 的库。我们将这些作为 git 子模块包含在内,以便我们可以更新任何网站中的模块并将更改推送到所有其他项目。它使得对我们的代码应用更改并分发它变得非常容易。我们希望将 CMS 变成一个模块,这样我们就可以获得相同的好处 - 我们可以在源代码控制下运行整个项目,然后通过 git-submodule 根据需要更新 CMS。然而我们遇到了一个问题: cms 需要 javascript/images/css 才能正常工作。

我们考虑过的事情:

  • 我们可以创建 2 个子模块,一个用于 cms-skin,一个用于 cms,但是这个意味着您无法“git pull”一个版本而不知道哪些版本的皮肤可以与哪些版本的 cms 配合使用。即版本 1.2.2 CMS 可能与 1.0.3 CMS-Skin 存在问题

  • 我们可以将皮肤添加到 cms 模块,但这存在以下问题:

    1. 皮肤应该在文档根目录上可用,模块代码不应该是可用的,如果是,则可能应该通过 .htaccess 进行保护
    2. 将资源与 php 代码捆绑似乎没有任何意义
    3. 我们可以在 /skin/backend/ 之间创建一个符号链接以转到 /modules/cms/skin,但这会导致任何安全问题吗?我们是否需要类似符号链接的东西才能使应用程序正常工作?
    4. 我们可以为 git 或 shell 脚本创建一个钩子,在更新发生时将文件从modules/cms/skin复制到skin/backend,但这意味着我们失去了在项目中编辑CMS核心文件然后推送它们的能力返回

能力这通常是在大型CMS中完成的?如何获得版本控制下的 cms 源代码,为客户端开发应用程序,然后将源代码更新为版本并由供应商提供? Magento 或 Drupal 等应用程序如何做到这一点?

I have the following directory structure in the CMS application we have written:

/application
/modules
   /cms
      /filemanager
      /block
      /pages
      /sitemap
   /youtube
   /rss
/skin
   /backend
      /default
         /css
         /js
         /images
   /frontend
     /default
         /css
         /js
         /images

Application contains code specific to the current CMS implementation, i.e code for this specific cms.
Modules contain reusable portions of code that we share across projects, such as libraries to work with youtube or rss feeds. We include these as git submodules, so that we can update the module in any website and push the changes back across all other projects. It makes it really easy to apply a change to our code and distribute it. We wanted to turn the CMS into a module so we get the same benefit - we can run the entire project under source control, then update the cms as required through a git-submodule. We have run into a problem however:
the cms requires javascript/images/css in order for it to work correctly.

Things we have thought about:

  • We could create 2 submodules, one for cms-skin and one for cms, but this means you cannot "git pull" one version without having some idea of which versions of skin work with which versions of cms. i.e version 1.2.2 CMS might have issues with 1.0.3 CMS-Skin

  • We could add the skin to the cms module but this has the following problems:

    1. Skin should be available on the document root, module code shouldn't be, and if it is it should probably be secured via .htaccess
    2. It doesn't seem to make any sense bundling assets with php code
    3. We could create a symlink between /skin/backend/ to go to /modules/cms/skin but does this cause any security problems, and do we want to require something like a symlink for the application to work?
    4. We could create a hook for git or a shell script that copies files from modules/cms/skin to skin/backend when an update occurs, but this means we lose the ability to edit CMS core files in a project then push them back

How is this typically done in large scale cms's? How is it possible to get the source code for a cms under version control, work on the application for a client, then update the sourcecode as releases and given by the vendor? How do applications like Magento or Drupal do this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

南烟 2024-09-05 01:32:29

我不熟悉 CMS 项目,但是您可以:

  • 创建 2 个子模块,一个用于 cms-skin,一个用于 cms
  • 使用 cms-skin 作为 cms 内的嵌套子模块

cms 将是 cms-skin 的“主项目”,这意味着每次提交 cms 时,您都会先提交 cms-skin,并且“cms 提交”将启动提交时使用的 cms-skin 的确切 SHA1 引用。

这样你就可以只拉取 cms,并且随之而来的是你需要的 cms-skin 的确切版本。

有关更多信息,请参阅此关于真实本质的SO答案子模块。

I am not familiar with CMS projects, but could you:

  • create 2 submodules, one for cms-skin and one for cms
  • use the cms-skin as a nested submodule within cms

cms would be a "main project" for cms-skin, meaning each time you commit cms, you would have committed cms-skin first, and the "cms commit" would embark the exact SHA1 reference of the cms-skin used at the time of the commit.

That way you can pull only cms, and with it will come the exact version of cms-skin you need.

For more, see this SO answer about the true nature of submodules.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文