bik*_*y77 3 database wordpress workflow multisite
我正在为 WordPress 多站点设置规划开发团队工作流程。我们选择多站点是因为我们想要限制更新/升级过程，并且因为我们的绝大多数客户在后端具有相同的网站结构/要求。对于前端，我们使用“vanilla”主题，其中包含我们的 css/js 框架和主要设置、帖子类型、选项等，我们将基于我们的 vanilla 主题构建所有网站，并为每个主题扩展它客户端通过子主题。我决定将所有内容都置于版本控制 (Git) 之下，甚至是 WordPress 核心文件。
就我们当前的开发环境而言：我们一直在使用集中式 Web 服务器，而不是 LAMP 堆栈或 VVV/Docker 设置，每个开发人员都通过使用单独的 vhost 每个映射到其本地存储库的 url 访问他的项目项目（现场）。因此，在处理 projectA 时，John 的 url 是http://john.projectA.dev，而 Jack 的 url 是http://jack.projectA.dev。
最初为所有开发人员使用相同的数据库似乎是确保数据一致性、通用设置等的“合乎逻辑”的方式，但我还没有能够结束。由于 WordPress 在 wp_options 表中存储 siteurl 和 homeurl URL 的方式，我未能找到一种方法将 John 映射到他将通过 URL 工作的站点，或者允许所有开发人员访问公共多站点的 wp- admin 默认为用户的 URL 之一（即http://bob.wpmulisite.dev，其中 Bob 是最初设置多站点环境的开发人员。我尝试通过在每个开发人员的自定义 wp-configs 中定义它们来覆盖 url，但是WP_HOME 和 WP_SITEURL 在 WP 多站点中被忽略了。
我不喜欢必须使用 db 转储、替换转储中的 url 并将其导入到每个用户的数据库中的想法，因为我担心该过程很快会导致问题并且会造成过多的合并，差异-ing 等 但是，我可能是错的，我绝对愿意接受任何建议。
我已经在上面概述了我的主要问题，如果您觉得不清楚，我会很乐意重新表述。在这一点上，我不太确定您可能感兴趣的详细程度，所以请问我，我会深入研究。
好吧，让我带你去旅行。
你的集中式开发环境听起来很独特，但我认为我们可以使用它。我有一个类似的系统设置：我们有一个带有公共域/ip 的“暂存”服务器供客户端查看，每个开发人员通过 git 在他们的本地机器上有一个完整的副本，本地机器上有一个本地 Apache 服务器。我们将本地开发站点指向中央登台服务器数据库，以便内容/设置保持一致。我们使用自定义本地域访问我们的本地开发站点，例如http://example.local临时站点是http://example.staging.com，实时站点将是http://example.com。
顺便说一句，我们有wp-config.phpin .gitignore，所以我们每个人都可以在我们的本地副本上自定义它。通常我们将暂存版本和实时版本保存为不同名称的文件，例如wp-config-live.php并将其符号链接到wp-config.php实时服务器等，以便我们也可以在我们的私有 git 存储库中保留配置设置。
现在，我们想要处理多站点的本地副本，example.local并通过子文件夹 ( example.local/site2/) 或我们example2.local在每台计算机上的vhost 设置 ( ) 中别名的其他自定义域访问其网络站点。此外，临时站点应该git pull在服务器上没有任何东西的情况下工作。最重要的是，实时站点还应该使用简单的，git pull无需任何数据库编辑。我们如何实现这一目标？
首先，我们wp-config所有的 live/staging/dev 环境都应该包含标准的多站点设置：
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
请注意，这DOMAIN_CURRENT_SITE是实时域！为了让整个系统正常工作，我们数据库中定义的域都应该是实时域，我们将使用以下内容处理每个临时/开发站点，也在wp-config（仅在开发/临时配置上，而不是在实时配置中） ：
/** Set this to your local tld setup */
define( 'WP_HOME', 'http://example.local');
define( 'WP_SITEURL', 'http://example.local');
/** Include wp-content/sunrise.php */
define( 'SUNRISE', true );
/** This should be the TLD in the database */
define( 'WP_PROD_TLD', '.com' );
/** This should be the tld of your local copy */
define( 'WP_DEV_TLD', '.local');
在WP_PROD_TLD和WP_DEV_TLD我们将用它来检查，如果我们需要改变域（我知道你也使用子域名在你的设置，但我想尝试之前，描述一个略微更“标准”的做法是我们自己的自定义常量适合您的具体情况）。该SUNRISE常量内置于 WP multisite 中，它只是说/wp-content/sunrise.php如果存在则包括在内。这是我们的sunrise.php文件：
<?php
/**
* File sunrise.php
*
* This allows us to copy the production multisite database to staging/dev and still use
* it directly without altering domains
*/
/**
* Filter /wp-includes/ms-load.php get_site_by_path to find production domains
**/
function dev_get_site_by_path($_site, $_domain, $_path, $_segments, $_paths) {
global $wpdb, $path;
// Get our actual domain in the database (should be set to production domain)
// The domain coming in should be the request domain
$domain = str_replace( WP_DEV_TLD, WP_PROD_TLD, $_domain);
// Search for a site matching the domain and first path segment
$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $domain, $_paths[0] ) );
$current_path = $_paths[0];
if ($site === null) {
// Specifically for the main blog - if a site is not found then load the main blog
$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $domain, '/' ) );
$current_path = '/';
}
// Set path to match the first segment
$path = $current_path;
return $site;
}
add_filter('pre_get_site_by_path', 'dev_get_site_by_path', 1, 5);
add_filter('pre_get_network_by_path', 'dev_get_site_by_path', 1, 5);
/**
* Filter the site_url and home options for each site, and
* filter /wp-includes/link-template.php::network_site_url()
* and /wp-includes/link-template.php::network_home_url()
* so that our network site link is correct in the admin menu
*/
function dev_network_url( $_url = '' ) {
return str_replace( WP_PROD_TLD, WP_DEV_TLD, $_url );
}
add_filter( 'network_site_url', 'dev_network_url' );
add_filter( 'network_home_url', 'dev_network_url' );
add_filter( 'option_siteurl', 'dev_network_url' );
add_filter( 'option_home', 'dev_network_url' );
请注意，该sunrise.php文件仅通过 WP-CONFIG ON DEV/STAGING 包含，从不在实时服务器上！这是过滤请求以获取“按路径站点”的网络，这意味着它查看从客户端请求的域和路径，并匹配wp_blogs表中的域和路径。我们正在检查我们的实时 TLD（在本例中为.com）的域，并将其替换为当前环境的 TLD（我们的本地副本是.local，临时服务器是.staging.com）。它还在底部过滤每个站点的WP_HOME和WP_SITEURL选项。
而且，就是这样！数据库中的实时域正在为您的本地/临时站点设置即时翻译！只要您使用子文件夹或在本地虚拟主机设置中设置了别名，这应该可以工作。
现在，对于您使用子域的情况，您可能需要对域进行更彻底的过滤，而不仅仅是替换 TLD。也许您满足于数据库中的“规范”域multisite.dev，然后在您的sunrise.php文件中只附加本地用户的子域而不是替换 TLD，然后在准备好迁移后在数据库中替换实时域。
感谢“laubsterboy”让我开始使用这个解决方案：https ://www.laubsterboy.com/blog/2014/08/running-development-copy-wordpress-multisite-update/