WordPress 页面和版本控制
我们是一家软件开发公司，使用 Wordpress 来实现网站的静态部分。当然，我们所有的工作流程都是围绕版本控制构建的：多个开发人员 ->持续集成->分期->部署。
我们将 Wordpress 集成到我们的工作流程中的挑战是它的数据库像喉咙里的骨头一样卡住：你无法将其放入版本控制中，轻松回滚，从暂存升级到生产等。
我想知道人们在类似情况下会做什么？我想找到一种将 WP 集成到开发工作流程中的方法，而不是相反:-)
澄清我们希望在临时系统上“开发”和测试页面，准备好后移动它们作为版本升级过程的一部分移交给生产。我们不想将临时数据库完全复制到生产环境。
We are a software development company and are using Wordpress for static portion of the web site. Naturally, all our workflow is built around version control: multiple developers -> continious integration -> staging -> deployment.
Our challenge with integrating Wordpress into our workflow is that its database is stuck like a bone in the throat: you cannot put it into the version control, easily roll back, promote from staging to production etc.
I am wondering what people do in similar situations? I would like to find a way to integrate WP into the development workflow and not the other way around :-)
Clarification we want to "develop" and test pages on the staging system and when ready then move them over to the production as part of the version upgrade process. We don't want to do full replication of the staging database to production.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个常见问题，也是我一直在努力解决的问题。我已经编写了一些代码来解决这些问题，尽管代码尚未准备好分发。基本上，其想法是创建脚本来导入内容，然后对脚本进行版本控制。 （实际上，我的方法使用了自定义导入/导出格式，旨在易于手动修改，但想法是相似的。）
无论如何，StackOverflow 的姊妹网站上有一些相关问题WordPress 答案：
更新
根据澄清，这可能也会有帮助：
希望这会有所帮助。
-麦克风
That's a common question and one that I've worked on tackling. I've written some code to address these issues albeit the code's not ready for distribution. Basically the idea is to create scripts to import the content and then version control the scripts. (Actually my approach uses a custom import/export format designed to be easy to hand-modify, but the idea is similar.)
Anyway, there are some related questions over on StackOverflow's sister site WordPress Answers:
UPDATE
Per the clarification, this would probably be helpful too:
Hope this helps.
-Mike
我刚刚遇到了同样的问题。目前，我们使用 MySQL 转储文件来导出/导入数据库内容，但如果有几个人致力于数据库更改，情况会变得很糟糕。
由于从事该项目的团队都是内部团队，并且只有几个人，因此我正在考虑在 VCS 中锁定数据库转储文件的方向。 Subversion 内置了此功能，但我们使用的是 git，我认为这在概念上与任何类型的锁定相反。
也许我们会有一个带有预提交挂钩的解决方法脚本来检查转储旁边是否存在锁定文件。提交锁定文件的人将是唯一允许提交转储的人。一旦他完成工作，他将需要提交锁定文件的删除。
我知道这听起来很丑。但我思考了一段时间，还没有找到一个优雅的解决方案。
I've just hit the same problem. For now we are using MySQL dump files to export/import database content, but it gets ugly with several people working on the database changes.
Since the team that works on the project is all internal and consists of just a few people, I'm thinking into the direction of locking the database dump file in VCS. Subversion had this functionality built-in, but we are using git, which, I think, is conceptually opposite of any kind of locking.
Probably we'll have a workaround script with pre-commit hook to check for the existence of a lock file next to the dump. The person who committed the lock file will be the only one allowed to commit the dump. Once he finishes the work, he will need to commit the removal of the lock file.
It sounds ugly, I know. But I've thought about it for a while and don't see an elegant solution yet.
如果您仅将 WordPress 用于静态内容，那么任何用于版本控制数据库的工具/方法都应该有效 - 例如，将 mysql 命令行工具应用到 CI 和部署例程中。
If you're only using WordPress for static content, then any tool/methodology for version controlling databases should work - for example, work the mysql command line tools into your CI and deployment routines.