Wordpress 网站的团队开发 [英] Team Development of a Wordpress Site
问题描述
我不是 Wordpress 开发人员，但我正在尝试确定一组人员使用 Wordpress 的最佳方式.对于 Rails 项目或大多数其他项目，在本地工作并在上游部署很容易，但我的理解是 Wordpress 并没有让这一切变得那么容易.也许这是一个神话?
据我所知，将 URL 和文件路径存储在数据库中的情况并不少见，这似乎会使从 dev --> stg --> prd(每个环境都有它是自己的 URL 和可能不同的文件路径)，更不用说个人开发人员拥有自己的开发环境，需要合并"到一个统一的副本中进行部署.
我可以将所有开发人员沙箱配置为使用单个数据库，但同样，如果存储了 URL 和文件路径，则一无所获.
这里有一系列较小的问题，但我对这些问题考虑得越多，我就越意识到我真正需要的是关于如何构建将被黑客入侵的 WordPress 网站的最佳开发的建议由一组开发人员进行.我更喜欢我们用于其他项目的沙盒方法，但我不知道一旦所有开发完成后是否/如何统一事情.
我会在这里帮忙吗?
谢谢.
警告:文本墙..
@Rob，说到团队合作，WP 简直是地狱；然而，通过一些工作(和一些符号链接魔法)，您可以设置您的 WP 项目，以便您的主题或插件的工作文件可以与 WP 核心分开驻留.其中一些使用 WP 的内置机制，其中一些与 SVN 外部(提示)有关.我会让你谷歌一下，因为它超出了你的问题范围.
关于 WP GUID 的说明
警告:请勿替换 guid.WP GUID 可用于外部提要阅读器.订阅源阅读器使用 GUID 来确定内容是否是最新的.更改它基本上告诉那些读者，提要中的每个条目都是新的(尤其是对于帖子).这会为您不需要的遗留内容带来很多额外的开销.GUID 是一个很早以前就应该更改为 UUID 的遗留功能.从技术上讲，您可以在 guid 字段中使用任何内容，但 WP 使用永久链接来填充该字段 - 遗留.
唯一可以接受更改 GUID 的情况是内容是全新的 wp 项目.
回答您的问题:
WP 在其数据库的十几个位置存储对当前域的显式引用.这些位置很难跟踪和更改，您要做的最后一件事是手动编辑要导入到生产环境中的 *.sql 转储文件.这只是糟糕的开发实践的味道.
有几种方法可以解决这个问题，但如果您的开发生命周期已经更远，这意味着需要做一些工作.我将处理第一种情况.
案例 1:项目启动
当您开始项目时，您可能已经准备好开发沙箱和数据库.您现在可能已经安装了 WP，因此对于所有意图和目的来说，它基本上都是干净的.
您要做的第一件事是更改配置文件的工作方式.大多数人都使用标准的 wp-config.php 文件(除了团队生产项目，实际上没有任何理由对其进行编辑.)但是，您可以使用一些逻辑来设置它以包含开发人员-特定或特定于环境的配置文件.例如:
wp-config.php
switch( $current_environment ){case 'jack.local' : include( 'wp-config-jack.php' ) 中断；//杰克的沙箱case 'jill.local' : include( 'wp-config-jill.php' ) 中断；//吉尔的沙箱默认值:...中断；//分期 &生产}接下来您要做的是将 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规范化"功能包装到我设置的单个引导插件中 &忘记了.
案例 2:正在进行的项目
现在，就您而言，您的开发生命周期更进一步.替换这些域引用需要一些工作，但是如果您按照我上面概述的步骤进行操作，您应该只需要执行一次.我在上面提供的链接为您提供了完成这项工作所需的 SQL.请务必注意，在多站点环境中，您需要为您创建的每个子站点"执行此操作.
更新数据库后，我建议您执行案例 1 中的步骤，这样您就不必再次重复这些步骤了.
奖励:同步内容
同步内容很痛苦.我在最近的项目中所做的是让客户在登台服务器上工作并将更改提升到生产的上游.那么，这就让您在下游同步到您的沙箱.编写一个 shell 脚本，从暂存数据库转储特定内容表的副本，并将它们导入沙箱数据库(有效替换内容表).您应该能够看到域令牌替换技术的好处.
未签入源代码管理的图像，例如客户端图像应该被推送到一个公共位置，例如一个 S3 存储桶.有 WP 插件可以帮助您解决这个问题.这将节省大量时间，无需跨环境同步资产.
我希望这能帮到你——如果没有，总会有 SilverStripe ;)
I'm not a Wordpress developer, but I'm trying to determine the optimal way for a team of folks to work with Wordpress. For a Rails project or most anything else, it's easy to work locally and deploy upstream, but my understanding is that Wordpress doesn't make this quite as easy. Maybe this is a myth?
From what I gather, it's not uncommon for URLs and file paths to be stored in the database which seems like it would make it difficult to deploy a WP project from dev --> stg --> prd (where each environment has it's own URL and possibly different file paths), much less for individual developers to have their own dev environment that would need to be "merged" into a unified copy for deployment.
I could configure all developer sandboxes to use a single database, but here again, if URLs and file paths are stored then nothing is gained.
There are a series of smaller questions here, but the more I think about those, the more I realize that what I'm really asking for is advice about how to structure things for optimal development of a WordPress site that will be hacked on by a team of developers. I'd prefer the sandboxed approach we use for other projects, but I have no idea if/how things can be unified once all development is complete.
Li'l help here?
Thanks.
Warning: incoming wall of text..
@Rob, WP is hell when it comes to working in teams; however, with a little work (and some symlink magic) you can set up your WP projects so that your working files for your themes or plugins can reside separately from the WP core. Some of this uses WP's built in mechanisms, some of it is related to SVN externals (hint). I'll let you google that since it's outside the scope of your question.
A note on WP GUIDs
WARNING: DO NOT replace guids. WP GUIDs are there for external feed readers. Feed readers use the GUID to determine if the content is recent. Changing it basically tells those readers that every entry in the feed is new (especially for posts.) That introduces a lot of extra overhead for legacy content that you just don't need. GUID are a legacy feature that should have been changed a long time ago to UUIDs. Technically, you can use anything int he guid field, but WP uses the permalink to populate that field -- legacy.
The only time it is ever acceptable to change the GUID is for new wp projects where content is brand-spankin' new.
To answer your question:
WP stores explicit references to the current domain in a dozen places in it's DB. These locations are a pain to track down and change, and the last thing you want to do is deal with manual edits to a *.sql dump file that you're going to import into production. It just smacks of bad development practices.
There's a couple ways to get around this, but it means a little bit of work if you're already further down your development lifecycle. I'll address the first case.
Case 1: Project Onset
When you're starting the project, you'll likely have a development sandbox and DB ready. You'll likely have WP already installed by now, so it's essentially clean for all intents and purposes.
The first thing you're going to want to do is change how your config file works. Most folks keep with the standard wp-config.php file (beyond a team production project, there's not really any reason to edit it.) However, you can set it up with some logic to include developer-specific or environment-specific config files. For example:
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
}
The next thing you're going to want to do is include the normal contents of the wp-config.php file in a wp-config-remote.php file for use on staging/production. Next, edit your wp-config-remote.php file so that you can use 1 config file across multiple environments (staging,production). An if(...) or switch(...) block is all you need, e.g.
if( (strpos( $_SERVER[ "HTTP_HOST" ], "localhost" ) !== false) || (strpos( $_SERVER[ "HTTP_HOST" ], "local" ) !== false) )
(There are better ways to write that condition... this is just a crude example.)
Configure all of your WP settings specific to each of your remote environments. Hopefully you'll be checking this into a source control repository.
That basically frees you up to let your team have config settings specific to their environment, while letting you check in settings for each of the remote environments once.
The second thing you're going to want to do is build a mechanism to intercept and filter domain-specific links. The intent behind this mechanism is to replace any references to the current domain with a token/placeholder. I've outline the technique to do this here: http://www.farfromfearless.com/2010/09/07/url-token-replacement-techniques-for-wordpress-3-0/
It basically amounts to creating a filter that acts on the content before it's submitted to the DB and before the content is rendered to the page. The technique is transparent in that it won't affect normal editing practices. You can still create your content in the editor, reference other pages, posts, images, etc. and they'll show up just fine while editing in different environments.
In recent projects, I've wrapped all of this and a few other WP "normalization" features into a single bootstrap plugin that I set & forget.
Case 2: Project Ongoing
Now, in your case, you're further along in your development lifecycle. It's going to take some work to replace those domain references, but if you follow the steps I've outline above you should only ever have to do this once. The link I supplied above gives you the SQL you'll need to do that job. It's important to note that in a multi-site environment, you'll need to do this for every "sub-site" you've created.
Once you've updated your DB, I suggest implementing the steps in CASE 1 so you don't have to repeat the steps again.
Bonus: synchronizing content
Synchronizing content is a pain. What I've done in recent projects is had clients work on the staging server and promote changes upstream to production. So then, that leaves you with synchronizing downstream to your sandbox(es). Write a shell script that dumps a copy of SPECIFIC content tables from your staging DB, and imports them into your sandbox DB (effectively replacing content tables.) You should be able to see the benefit of the domain-token-replacement technique.
Images that aren't checked into source control, e.g. client images should be pushed to a common location, e.g. an S3 Bucket. There are WP plugins that can help you with that. That'll save a lot of time having to synchronize assets across environments.
I hope this helps you out -- if not, there's always SilverStripe ;)
这篇关于Wordpress 网站的团队开发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
