我不是 Wordpress 开发人员，但我正在尝试确定一个团队使用 Wordpress 的最佳方式。对于 Rails 项目或大多数其他项目，在本地工作和在上游部署很容易，但我的理解是 Wordpress 并没有让这变得那么容易。也许这是一个神话？
据我所知，将 URL 和文件路径存储在数据库中的情况并不少见，这似乎会使从 dev --> stg --> prd 部署 WP 项目变得困难（每个环境都有自己的 URL以及可能不同的文件路径），更不用说个别开发人员拥有自己的开发环境，需要“合并”到统一的副本中进行部署。
我可以将所有开发人员沙箱配置为使用单个数据库，但同样，如果存储了 URL 和文件路径，则什么也得不到。
这里有一系列较小的问题，但我越想这些，我就越意识到我真正想要的是关于如何构建事物以优化 WordPress 网站的建议，该网站将被黑客入侵开发人员团队。我更喜欢我们用于其他项目的沙盒方法，但我不知道一旦所有开发完成后是否/如何统一事物。
李来帮忙？
谢谢。
警告：传入的文字墙..
@Rob，当谈到团队合作时，WP 简直就是地狱；然而，通过一些工作（和一些符号链接魔法），您可以设置您的 WP 项目，以便您的主题或插件的工作文件可以独立于 WP 核心。其中一些使用 WP 的内置机制，其中一些与 SVN 外部相关（提示）。我会让你用谷歌搜索，因为它超出了你的问题范围。
警告：不要更换导向装置。WP GUID 可用于外部提要阅读器。提要阅读器使用 GUID 来确定内容是否是最新的。更改它基本上会告诉那些读者，提要中的每个条目都是新的（尤其是对于帖子）。这会为您不需要的遗留内容带来很多额外的开销。GUID 是一项旧功能，很久以前就应该更改为 UUID。从技术上讲，您可以使用 guid 字段中的任何内容，但 WP 使用永久链接来填充该字段 - 遗留。
唯一可以接受更改 GUID 的情况是新的 wp 项目，其中内容是全新的。
WP 在其数据库中的十几个地方存储对当前域的显式引用。这些位置很难追踪和更改，您最不想做的事情是手动编辑您要导入生产的 *.sql 转储文件。它只是带有不良开发实践的味道。
有几种方法可以解决这个问题，但如果您已经进入了开发生命周期，这意味着需要做一些工作。我将解决第一种情况。
当您开始项目时，您可能已经准备好开发沙箱和数据库。您现在可能已经安装了 WP，因此对于所有意图和目的而言，它基本上都是干净的。
您要做的第一件事是更改配置文件的工作方式。大多数人都保留标准wp-config.php文件（除了团队生产项目，实际上没有任何理由编辑它。）但是，您可以使用一些逻辑对其进行设置，以包含特定于开发人员或特定于环境的配置文件。例如：
wp-config.php
switch( $current_environment )
{
case 'jack.local' : include( 'wp-config-jack.php' ) break; // Jack's sandbox
case 'jill.local' : include( 'wp-config-jill.php' ) break; // Jill's sandbox
default : ... break; // Staging & Production
}
您要做的下一件事是将文件的正常内容包含wp-config.php在一个wp-config-remote.php文件中以用于登台/生产。接下来，编辑您的wp-config-remote.php文件，以便您可以在多个环境（暂存、生产）中使用 1 个配置文件。一个if(...)或switch(...)块就是你所需要的，例如
if( (strpos( $_SERVER[ "HTTP_HOST" ], "localhost" ) !== false) || (strpos( $_SERVER[ "HTTP_HOST" ], "local" ) !== false) )
（有更好的方法来写那个条件......这只是一个粗略的例子。）
配置特定于每个远程环境的所有 WP 设置。希望您将其签入源代码控制存储库。
这基本上可以让您腾出时间，让您的团队拥有特定于其环境的配置设置，同时让您检查每个远程环境的设置一次。
您要做的第二件事是建立一种机制来拦截和过滤特定于域的链接。此机制背后的意图是用令牌/占位符替换对当前域的任何引用。我在这里概述了执行此操作的技术：http: //www.farfromfearless.com/2010/09/07/url-token-replacement-techniques-for-wordpress-3-0/
它基本上相当于创建一个过滤器，在内容提交到数据库之前和内容呈现到页面之前对内容起作用。该技术是透明的，因为它不会影响正常的编辑实践。您仍然可以在编辑器中创建内容，参考其他页面、帖子、图像等，并且在不同环境中编辑时它们会很好地显示出来。
在最近的项目中，我将所有这些和其他一些 WP“规范化”功能打包到一个我设置并忘记的引导插件中。
现在，就您而言，您在开发生命周期中走得更远。替换这些域引用需要做一些工作，但如果您按照我在上面概述的步骤进行操作，您应该只需要执行一次。我在上面提供的链接为您提供了完成这项工作所需的 SQL。请务必注意，在多站点环境中，您需要为您创建的每个“子站点”执行此操作。
更新数据库后，我建议您实施案例 1中的步骤，这样您就不必再次重复这些步骤。
同步内容很痛苦。我在最近的项目中所做的是让客户在登台服务器上工作，并将变更上游推广到生产。那么，这让您可以将下游同步到您的沙箱。编写一个 shell 脚本，从暂存数据库中转储 SPECIFIC 内容表的副本，并将它们导入到沙盒数据库中（有效地替换内容表。）您应该能够看到域令牌替换技术的好处。
未检入源代码控制的图像（例如客户端图像）应推送到公共位置，例如 S3 存储桶。有 WP 插件可以帮助您。这将节省大量跨环境同步资产的时间。
我希望这对您有所帮助——如果没有，总会有 SilverStripe ;)
我自己在启动一个新网站时遇到了这个问题。我的解决方案是使用Vagrant。Vagrant 也与平台无关，因此您可以在 Mac 上进行开发，而队友正在使用 Windows。相同的 Vagrant 项目在两者上运行。
我写了一篇关于如何在你的机器上本地运行的生产环境中使用 Wordpress 设置 Vagrant 的指南。我不经常使用 Wordpress，但每次我在我的 Mac 上设置 Apache 和 PHP 总是很麻烦，然后确保所有 Wordpress 网站的 URL 都在数据库中更新。
一旦你配置了你的 Vagrant 项目，你的团队中的任何开发人员都可以通过一个命令来启动并运行本地的 Wordpress 实例。简而言之，Vagrant 会将你的项目目录从你的宿主机挂载到客户机上，并通过客户机运行 Apache、MySQL、PHP。您仍然使用主机的 IDE（如您通常那样）和主机浏览器。无需在任何地方上传文件，只需在本地计算机上编写代码、保存、刷新浏览器即可。
http://www.distilnetworks.com/wordpress-development-with-vagrant/ <- 解释如何使用 Vagrant 进行设置
https://gist.github.com/markmalek/fd2e6e65385400d9cd47 <- 配置 Vagrant 时的 shell 脚本
shell 脚本可能会好很多，这对我有用，但我很想听听一些更好的建议或想法。我是 Vagrant 的新手，现在将它用于我们的其他一些项目，所以我认为它也很适合这里。
我确实更新了 shell 脚本中的 GUID，我在另一个你不应该这样做的答案中读到了它，因为提要阅读器使用它。在这种情况下，它无关紧要，因为它仅适用于您的本地 Wordpress 实例，但我不会在生产中进行此更改。请参阅此答案以获得更好的解释。
我们很容易在开发服务器上构建并使用以下 sql 查询移动到实时服务器：
UPDATE wp_posts SET guid = REPLACE(guid, 'devserver.com', 'liveserver.com');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'devserver.com', 'liveserver.com');
UPDATE wp_options SET option_value = REPLACE(option_value, 'devserver.com', 'liveserver.com');
去年，我编写了一个 bash 脚本，将实时 MU 安装镜像到沙箱中。它不是完美的，也不是理想的，而是一个很好的起点。它包括镜像数据库、文件和重写镜像数据库以反映沙箱。
请参阅http://pp19dd.com/2011/01/bash-script-to-mirror-wordpress-mu-installation-into-a-sandbox/
对于开发人员来说，能够获取实时和准确的内容快照以复制条件非常重要。
没什么大不了的，只需使用一个 wp 迁移插件备份您的整个站点并在实时服务器安装时导入，插件将自动替换所有 url。