适用于所有开发人员的WordPress多站点和单一数据库

2 回答

• 0

  好的，我带你去旅行吧 .

  您的集中式开发环境听起来非常独特，但我认为我们可以使用它 . 我有一个类似的系统设置：我们有一个"staging"服务器，带有一个公共域/ ip供客户端查看，每个开发人员都有一个完整的副本，通过git在他们的本地机器上使用本地Apache服务器 . 我们将本地开发站点指向中央登台服务器数据库，以便内容/设置保持一致 . 我们使用自定义本地域（如 http://example.local ）访问我们的本地开发站点，暂存站点为 http://example.staging.com ，实时站点为 http://example.com .

  顺便说一句，我们在 .gitignore 中有 wp-config.php ，因此我们可以在本地副本上自定义它 . 通常我们将暂存和实时版本保存为不同命名的文件，如 wp-config-live.php ，并将它符号链接到实时服务器上的 wp-config.php 等，这样我们也可以在我们的私有git仓库中保留配置设置 .

  现在，我们希望在 example.local 处理多站点的本地副本，并通过子文件夹（ example.local/site2/ ）或我们在每台计算机上的vhost设置（ example2.local ）中别名的其他自定义域访问其网络站点 . 此外，登台站点应该在服务器上没有任何内容的情况下运行.1863698_ . 最重要的是，实时网站也应该使用简单的 git pull 而不进行任何数据库编辑 . 我们如何实现这一目标？

  首先，我们在所有live / staging / dev环境中的 wp-config 应该包含标准的多站点设置：

  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 是实时域名！为了使整个系统工作，我们数据库中定义的域应该都是活动域，我们将使用以下内容处理每个staging / dev站点，也在 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 是我们自己的自定义常量，我们将使用它来检查是否需要更改域（我意识到您在设置中也使用了子域，但是我想在尝试之前描述一些稍微更多的方法.1863707_适合您的具体情况） . SUNRISE 常量内置于WP多站点中，如果存在则只包含 /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 文件是 ONLY INCLUDED VIA WP-CONFIG ON DEV/STAGING ，永远不会在实时服务器上！这会过滤获取网络的请求"site by path"，这意味着它会查看从客户端请求的域和路径，并匹配 wp_blogs 表中的域和路径 . 我们正在检查域名中的实时TLD（在这种情况下， .com ）并将其替换为当前的TLD环境（我们的本地副本是 .local ，登台服务器是 .staging.com ） . 它还会过滤底部每个站点的 WP_HOME 和 WP_SITEURL 选项 .

  而且，就是这样！正在为您的本地/临时站点设置正在翻译数据库中的实时域名！只要您使用子文件夹或在本地虚拟主机设置中设置别名，这应该有效 .

  现在，对于使用子域的情况，您可能必须对域进行更彻底的过滤，而不是仅替换TLD . 也许你满足于数据库中的"canonical"域 multisite.dev 然后在你的 sunrise.php 文件中只需追加本地用户's subdomain instead of replacing the TLD, and then do replacements in the database for the live domains once you'准备好迁移 .

  感谢"laubsterboy"让我开始寻求这个解决方案：https://www.laubsterboy.com/blog/2014/08/running-development-copy-wordpress-multisite-update/

  回复于 2024-04-27T06:00:10+08:00
• 4

  This advice applies to plugin development. Not "design" or client specific theme development:

  如果您从头开始设置WordPress开发商店，我强烈建议您使用Codeception中的WordPress模块学习如何进行行为和测试驱动开发 . 它可以从不同的角度进行各种测试[验收，WPunit测试，功能测试等] . 它可以轻松地在需要整个数据库转储，没有转储，URL替换，空白数据库等的测试之间切换，并且可以根据您的需要进行混合和匹配 .

  进行TDD的主要原则之一是测试应该至少相互依赖 . 您正在谈论的这些共享设置是什么？应尽可能减少这些 . 当你这样做时，你可以逐个列出它们，而不是将你的设置视为某种有机整体 .

  例如，假设您正在创建一个插件，无论出于何种原因需要特定类型的永久链接结构 . 实现这一点的一种方法是你所建议的：即拥有某种共享服务，开发人员可以访问他们可以获得所需永久链接结构的环境 . 所有猪都去吃的troth .

  另一种方法是将此要求放入单元测试环境中，然后直接进入git仓库 . 该需求随git中的代码一起分发 . 然后，当你正在开发时，除了你正在处理的要求之外，你的工作从绝对没有任何存在的角度出发 . 该模块从空白的WordPress安装开始 . 在这种情况下，除了我们正在做的事情之外，它将是完全空白的，这将是一个特定的永久链接结构 . 但它可以是任何东西：自定义帖子类型，特定数据集，整个数据库，客户端数据等等 .

  而不是试图在一系列设置中捕获所有这些设置，只需捕获您正在处理的设置并将其置于测试的前端和中心 . 因此，需要此特定永久链接的插件应该适用于任何其他设置 . 例如，插件应该适用于任何主题 . 既然您的需求已经内置到测试中，那么您的程序员正在使用哪种环境并不重要 . 这使您可以使用远程外包商，并为您的团队提供灵活性 . 如果有人想在笔记本电脑上使用Eclipse而有人想在基于 Cloud 的PHPstorm IDE上工作，那就无所谓了 . 他将代码中的项目和相关设置拉下来 . 这使得您的代码更加稳定，因为它是从任何环境中开始工作而设计的 .

  以下是使用此结构设置插件的教程：https://wordpress-bdd.com/wp-codeception-tutorial/

  回复于 2024-04-27T06:00:10+08:00