据我所知,这里有2(3？)种可能的策略：
>’转储并加载’MySQL数据库从DEV到LIVE,并用最新更新替换wp-content文件夹.
>通过WP-importer导入更改,并将wp-content文件夹替换为最新更新.
>通过WP管理界面手动更改数据库,并将wp-content文件夹替换为最新更新(仅对较小的更改有用).
当我在我自己的独立环境中开发时,这是针对现有网站,该网站目前正在进行并将继续接收公众的更新,例如评论和条目到联系表单,因此我希望数据库现在与我发布时不同我的变化.
鉴于此,上述选项提供了以下问题.
1.转储和负载
“转储和加载”策略似乎是不可能的,因为我的数据正在幕后更新(这可能是我的首选方法,因为这很容易回滚).
结果：要求在发布后同步数据库以获取最新更新,TOO COMPLICATED.
2.使用进口商
使用WP-Importer plugin页面和帖子ID将得到更新,搞砸依赖于帖子ID的样式来激活.这反过来会产生一个我想避免的CSS噩梦,在发布后必须通过CSS来更新新的页面/帖子ID与数据库创建的.
结果：太挑剔,不是非常专业的方法导致漫长而复杂的发布过程.
3.手动更新数据库
此选项适用于较小的更改,但是对于更复杂的版本,PROD界面上要遵循的步骤列表变得冗长且难以遵循,从而容易出错.
结果：太容易搞砸,只是万不得已.
是否存在标准的wordpress发布现有网站的策略？
基本上,我的问题是：在更新现有网站时,其他wordpress开发人员会遵循哪些发布流程？是否有一个我未在下面列出的选项可以最大限度地减少麻烦并减少发布期间的时间和复杂性？
我已经使用GIT为站点设置了源代码控制,我习惯通过ANT或类似的发布脚本自动化事物,这对于当前项目来说可能有点过头但是至少知道更新wordpress的简单方法是理想的网站,并尽量减少搞砸的机会.
谢谢！
既然你说你正在进行修改,那么我可能会假设你知道你要做什么sql更改？只需确保您对数据库所做的所有更改都采用sql脚本文件的形式,而不仅仅是使用GUI进行编辑(您可以使用GUI来帮助编写查询,但保存实际的sql).完成所有更改后,您应该在开发过程中运行一堆sql脚本 – 您可以按顺序重新运行它们而不会遇到错误.
然后,当需要推向生产时,创建一个暂存版本的生产(这需要一个相当当前的生产数据库备份).在其上运行更新脚本并测试一切正常.如果是,那么你可以继续生产.
在运行任何更改之前,一定要备份生产！
