Ultimate Multisite 101

Ultimate Multisite 是一个 WordPress Multisite plugin，可让你向客户提供 WaaS 或 Websites as a Service。在我们深入了解 Ultimate Multisite 如何帮助你的业务和客户之前，需要先掌握一些基础知识。

WordPress Multisite

我们大多数人都熟悉标准的 WordPress 安装。你可以通过托管服务提供商的控制面板创建它，或者对于勇敢者来说，可以搭建一台新的 Web 服务器和数据库，下载核心文件并开始安装流程。

这适用于全球数百万个 WordPress 站点，但从代理机构或托管服务提供商的角度来看，我们先花一分钟讨论一下规模问题。

虽然通过自动化控制面板创建一个 WordPress 站点，甚至一百个站点都很容易，但当需要管理这些站点时，问题很快就会显现出来。如果无人管理，你就会成为恶意软件的主要目标。管理意味着投入精力和资源，尽管有外部工具和 plugins 可用于帮助简化 WordPress 站点的管理和行政工作，但客户保留管理访问权限这一事实意味着这些努力很容易被破坏。

在其核心中，WordPress 提供了一项简单命名为“Multisite”的功能，其起源可追溯到 2010 年 WordPress 3.0 发布之时。自那以后，它经历了多次修订，旨在引入新功能并加强安全性。

本质上，可以这样理解 WordPress multisite：一所大学维护一个 WordPress 的单一安装，但每个院系维护自己的 WordPress 站点。

为了分解这句话，让我们看看一些基础术语，这些术语不仅出现在 Ultimate Multisite 的文档中，也广泛存在于 WordPress 社区中。

网络

在 WordPress 中，multisite 网络是指可以从单个 Dashboard 管理多个子站点的地方。尽管创建 multisite 网络的方式因托管服务提供商而异，但最终结果通常是在 wp-config.php 文件中添加几条额外指令，以便让 WordPress 知道它正在以这种特定模式运行。

multisite 网络与独立的 WordPress 安装之间存在许多明显差异，我们将简要讨论。

子域名与子目录

你需要做出的最直接决定之一，是 multisite 安装将使用 子目录 还是 子域名 运行。Ultimate Multisite 对两种选择都同样适用，但这两种配置在架构上存在一些差异。

在 子目录 配置中，网络站点会继承一个基于主域名的路径。例如，一个标记为“site1”的网络站点，其完整 URL 将是 https://domain.com/site1。在 子域名 配置中，网络站点将拥有从主域名派生出的自己的 子域名。因此，一个标记为“site1”的站点，其完整 URL 将是 https://site1.domain.com/。

虽然两种选项都是完全有效的选择，但使用 子域名 确实提供了许多优势，不过在其架构上也需要更多思考和规划。

就 DNS 而言，使用 子目录 带来的挑战相对简单。由于网络站点只是父路径的子项，因此只需要为主域名存在一条域名记录。对于 子域名，挑战稍微复杂一些，需要为每个网络站点单独设置 CNAME 记录，或者在 DNS 记录中设置通配符 (*) 记录。

另一个需要考虑的领域是 SSL，以及 SSL 证书的签发和使用。在 子目录 配置中，可以使用单个域名证书，因为网络站点只是主域名的路径。因此，domain.com 的证书将足以为 https://domain.com/site1、https://domain.com/site2 等提供 SSL。

在 子域名 配置中，使用通配符 SSL 证书是最常见的选项之一。这种类型的 SSL 证书为一个域名及其 子域名 提供加密。因此，通配符 SSL 证书将为 https://site1.domain.com、https://site2.domain.com 以及 https://domain.com 本身提供加密。

尽管还存在其他选项，但这些选项通常在范围和应用上有限，并且在适用性方面需要额外配置和考虑。

Plugins 和 Themes

WordPress 既给予也会收回，至少从客户的角度来看是这样。在独立的 WordPress 安装中，如果站点管理员安装了一个糟糕的 plugin，或者未能保持其安装为最新状态，那么这一行为唯一的受害者和损失方就是他们自己。然而，在 multisite 安装上，站点管理员安装一个糟糕的 plugin，会让网络中安装的每个站点都成为受害者。

因此，当配置为 multisite 时，WordPress 会移除站点管理员安装 plugins 和 themes 的能力，并将此能力转移给新创建的网络管理员或“超级管理员”角色。这个特权角色随后可以决定是否允许网络站点的管理员在其 Dashboard 中看到或访问 plugins 菜单；如果允许，还可以决定这些权限是否扩展到 激活 或 停用 plugins。

在这个范围内，网络管理员负责将 plugins 和 themes 安装到网络中，并将使用这些 plugins 和 themes 的权限委派给网络站点。站点管理员不能安装 plugins 和 themes，也不能访问未分配给其站点的 plugins 和 themes。

用户和管理员

在 WordPress Multisite 中，所有网络站点共享同一个数据库，因此共享相同的用户、角色和能力。最恰当的理解方式是：所有用户都是网络的成员，而不是某个特定站点的成员。

基于这种理解，允许创建用户可能并不理想；因此 WordPress Multisite 从站点管理员那里移除了此能力，并将其转移给网络管理员。相应地，网络管理员可以将必要的权限委派给站点管理员，使他们能够为自己的站点创建用户账户。

重申上面的说法，尽管用户账户看起来与站点相关，但实际上它们是分配给网络的，因此必须在整个网络中唯一。由于这个原因，可能会出现某些用户名无法注册的情况。

虽然这在企业系统中并不是陌生概念，但这种用户注册和认证的单一来源，对于熟悉独立 WordPress 安装的人来说往往难以理解，因为在独立安装中，用户管理相对更简单。

媒体

在 WordPress Multisite 中，网络站点共享单个数据库，但它们会在文件系统上为媒体文件保留单独的路径。

标准 WordPress 位置（wp-content/uploads）仍然存在；但是，其路径会被更改，以反映网络站点的唯一 ID。因此，某个网络站点的媒体文件会显示为 wp-contents/uploads/site/[id]。

固定链接

我们之前提到过，子域名 配置相比 子目录 配置有一些明显优势，这里体现为：路径。

在 子目录 配置中，主站点（网络建立时创建的第一个站点）和网络子站点必须共享从域名开始的同一路径。这可能会导致大量冲突。

对于文章，主站点会添加一个必需的 /blog/ 路径，以防止与网络站点发生冲突。这意味着像“文章名”这样的美观固定链接会呈现为 domain.name/blog/post-name/

在 子域名 配置中，不需要此操作，因为每个网络站点都受益于完整的域名隔离，因此无需依赖单一路径。它们会改为基于自己的 子域名 保留各自独立的路径。

静态页面

在 子目录 配置中，命名冲突的可能性也会延伸到静态页面，因为主站点和网络站点共享同一路径。

为防止这种情况，WordPress 提供了一种将某些站点名称加入黑名单的方法，使其不会与第一个站点的名称发生冲突。通常，网络管理员会输入主站点页面的根路径。

在 子域名 配置中，命名冲突的可能性会通过 子域名 得到缓解，因为它对于网络站点是唯一的，并且与主站点没有任何关系。

注册

在 WordPress Multisite 的网络设置中，有几个新的用户注册选项可用，允许新用户和现有用户创建站点。

与独立 WordPress 安装不同，网络站点不保留那些熟悉的选项来允许用户注册或将这些注册分配给角色。

创建用户账户时，这些账户是在网络级别生成的。因此，它们并不属于某一个特定站点，而是属于网络。这既有一些明显优势，也有一些明显劣势。

例如，假设你的 WordPress Multisite 从事新闻和信息业务。你会建立多站点，然后为金融、技术、娱乐和其他兴趣领域创建网络站点，同时保持对 plugin 和 theme 的总体控制。相比使用自定义文章类型或常规文章分类，每个网络站点反过来都能对其网络站点的外观、体验和用户体验拥有更高程度的控制。

在这个意义上，当用户登录时，他们登录到网络，并最终也登录到每个网络站点，以提供无缝体验。如果你的新站点基于订阅，这将是理想的解决方案和结果。

但是，如果多站点的预期性质和目的，是提供彼此没有关系的不同网络站点，那么几乎总是需要外部或额外的 plugin 来操作用户角色。

域名和 SSL

让我们谈谈一个几乎被我们忽略的 WordPress Multisite 安装——Wordpress.com。这是目前最广泛的 Wordpress 多站点示例，并展示了它为实现某一目的而进行自定义和塑造的强大能力。

如今在现代互联网中，使用 SSL 几乎是强制性的，而 WordPress 多站点的网络管理员很快就会面临这些挑战。

在 子域名 配置中，站点是基于根域名创建的。因此，标记为“site1”的站点会被创建为“site1.domain.com”。通过使用通配符 SSL 证书，网络管理员可以成功应对这一挑战，并为网络提供 SSL 加密能力。

WordPress Multisite 包含域名映射功能，允许将网络站点与自定义域名或不同于网络根域名的域名关联起来。

对于网络管理员而言，这在域名配置以及 SSL 证书的签发和维护方面都带来了额外的复杂性。

在这种程度上，虽然 WordPress Multisite 提供了一种方式，可将 www.anotherdomain.com 映射到“site1”，但网络管理员仍面临着在外部管理 DNS 条目和实施 SSL 证书的挑战。

Ultimate Multisite

了解独立 WordPress 安装与 Multisite 安装之间的差异后，让我们看看 Ultimate Multisite 如何成为提供网站即服务的终极武器库。

介绍

在创建网站即服务（WaaS）方面，Ultimate Multisite 就是你的瑞士军刀。想想 Wix.com、Squarespace、WordPress.com，然后再想想拥有你自己的服务。

在底层，Ultimate Multisite 使用 WordPress Multisite，但它的使用方式不仅解决了网络管理员在 Multisite 安装中面临的众多挑战，还增强了能力，从而支持各种各样的使用场景。

在以下章节中，我们将了解一些常见使用场景以及支持这些场景所需的注意事项。

使用场景

场景 1：代理机构

通常，代理机构的核心技能在于网站设计，而托管或营销等方面则被列为附加服务。

对于代理机构而言，Ultimate Multisite 在单一平台上托管和管理多个网站的能力带来了极具吸引力的价值主张。对于将设计标准化到特定主题（例如 GeneratePress、Astra、OceanWP 或其他主题）的代理机构来说，更是如此，因为它们可以利用 Ultimate Multisite 的能力，为每个新站点自动激活这些主题。

同样，针对常见且流行 plugin 的代理机构定价优惠非常丰富，使用 Ultimate Multisite 可让代理机构通过提供一个通用平台来利用现有投资，在该平台上可以安装、维护并使用 plugin。

大多数情况下，可能会希望使用一种配置；幸运的是，Ultimate Multisite 通过与多个流行托管提供商以及 Cloudflare 和 cPanel 等服务的集成，使域名映射和 SSL 证书的处理变得极其容易。

因此，通过利用其中一个提供商，或将 Ultimate Multisite 放在 Cloudflare 后面，域名和 SSL 证书管理等方面就会变得相对简单。

偏好严格控制站点创建的代理机构会欣赏 Ultimate Multisite 简化界面带来的便利，他们可以轻松创建站点，并将站点与客户和 plan 关联起来。

通过 Ultimate Multisite 直观的界面，可以按 product 维度严格控制 plugin 和 theme，从而允许 plugin 和 theme 被设为可用或隐藏，并控制它们在为新站点实例化时的激活状态。

Theme 提供类似功能，允许在创建站点时激活或隐藏特定 theme。

Ultimate Multisite 让代理机构能够安心专注于他们最擅长的事情——设计出色的网站。

场景 2：垂直领域提供商

有句老话说：“做一件事，并把它做好”。对许多专家来说，这意味着围绕一个单一核心理念创建 product 或服务。

也许你是一名狂热的高尔夫爱好者，向俱乐部推广网站；或者你可能是一名狂热的电竞玩家，为战队提供网站。也可能是一个人向餐厅推广预订服务？

出于许多原因，你会希望基于通用框架和平台提供服务。可能是你已经设计或投资了定制 plugin 来提供所需功能，也可能是行业最佳实践要求在设计上采用某种标准化方法。

Ultimate Multisite 的创新功能之一是使用模板站点。模板站点是指已安装并激活 theme、已安装并激活必要 plugin，并创建了示例文章或页面的站点。当客户基于模板创建新站点时，模板的内容和设置会被复制到新创建的站点。

对于垂直领域站点和服务提供商而言，这在能够即时创建一个带有自定义 plugin 和设计、可立即投入使用的站点方面提供了无与伦比的优势。客户只需提供最少的输入即可完成服务。

根据需求，subdirectory 或 subdomain 配置都可能适用，在这种情况下，架构选择将在适用于 subdirectories 的简单 SSL 证书与适用于 subdomains 的通配符 SSL 证书之间进行。

场景 3：WordPress 网站托管

托管 WordPress 站点有无数种方式，但很少会像向客户提供带有预安装 WordPress 版本的网络空间那样简单。这是因为需要综合考虑许多决策和因素，才能提供有意义的服务。

Ultimate Multisite 在这一领域表现出色，它为 WordPress 站点托管提供了全面的交钥匙解决方案。该解决方案包含用于提供订阅服务、收款、checkout 表单、折扣券和客户沟通的核心机制。

正确安装、配置和维护 WordPress Multisite 所需的大部分核心工作都由 Ultimate Multisite 来促进完成，以至于网络管理员只需要考虑与其服务或垂直领域相关的方面，例如 product 层级、定价和服务报价。

对于希望与 Ultimate Multisite 集成的开发者，该解决方案还提供全面的 RESTful API 和 Webhooks，用于事件通知。

无需依赖大量外部插件和许可证，Ultimate Multisite 提供了功能丰富且可与 Wix、Squarespace、WordPress.com 等相媲美的解决方案。

架构注意事项

虽然这不是一份全面指南，但以下项目应作为指导，帮助你正确选择支持 Ultimate Multisite 安装的技术。

共享主机与专用主机

遗憾的是，并非所有托管服务提供商都一样，有些会采用极高的服务器密度。低成本提供商通常通过最大化服务器密度来创造收入。因此，你的 Ultimate Multisite 安装可能只是同一台服务器上数百个站点中的一个。

如果提供商没有适当的防护措施，共享服务器上的站点会遇到“吵闹邻居”问题。也就是说，同一台服务器上的某个站点消耗了大量资源，导致其他站点不得不争夺剩余资源。这通常表现为站点速度缓慢，或无法及时响应。

如果你自己也是网站托管服务提供商，这种连锁影响将意味着你的客户会经历较差的速度、较低的页面排名和较高的跳出率，最终常常导致客户流失，转而寻求其他服务。

简而言之，便宜并不意味着好。

已知 Ultimate Multisite 可与多家优秀托管服务提供商配合使用，并能很好地与其环境集成，以提供域名映射和自动 SSL 等功能。这些提供商重视性能，并提供比共享主机更高等级的服务。

如需兼容提供商列表以及每个提供商的完整设置说明，请查看兼容提供商文档。

性能注意事项

Ultimate Multisite 并不是一个慢速应用；相反，它非常快。不过，它的表现只能与底层应用和基础设施一样好，并且只能利用它能够访问到的资源。

考虑一下：你是一个拥有 100 个站点的 Ultimate Multisite 安装的网络管理员。其中一些站点运行良好，每天吸引一定数量的网站访问者。

如果规模较小，比如一到五个站点，这种情况会有所不同，但不久之后，规模问题就会显现出来。

如果不加处理，单个 Ultimate Multisite 站点将负责满足所有站点访问者的请求。这些请求可能是动态 PHP 页面，也可能是样式表、JavaScript 或媒体文件等静态资源。无论是一个还是一百个站点，这些任务都会变得重复、单调且浪费。当每次请求的输出都是相同的静态信息时，使用 CPU 能力和内存来处理 PHP 文件是不必要的。

同样，对 PHP 或 HTML 页面的一个请求会进而生成多个后续请求，用于脚本、样式表和图像文件。这些请求会直接指向你的 Ultimate Multisite 服务器。

人们可以通过升级服务器轻松解决这个问题，但这并不能解决另一个问题——地理延迟。只有在多个位置部署多台服务器，才能妥善解决这个问题。

因此，大多数网络管理员会使用前端缓存解决方案和内容分发网络（CDN）来满足静态页面的请求。在请求到达服务器之前满足这些请求并提供资源，可以节省处理资源、消除延迟、避免不必要的升级，并最大化技术投资。

Ultimate Multisite 包含一个复杂的 Cloudflare add-on，使网络管理员能够将其安装置于 Cloudflare 之后，并不仅利用其缓存能力，还能利用 DNS 托管、SSL 证书和安全机制。

备份

你可以向 50 个人询问备份建议，并收到 50 种不同的备份策略意见。答案是：视情况而定。

没有争议的是，备份是必需的，而且几乎无法想象它们不由提供商管理，尤其是提供托管式服务的提供商。因此，客户会期望网络管理员提供并管理这项服务。至于网络管理员依赖谁，则是一个完全不同的问题。

就本节而言，让我们同意：备份是在启动备份时系统状态的某个时间点副本。简单来说，备份时系统处于什么状态，该状态就会被捕获并锁定在备份中。

基于这一理解，如何实现备份以及什么最适合你的环境，在很大程度上取决于你的需求以及托管服务提供商满足这些需求的能力。不过，按照从最有立场到最少立场的顺序，下面的选项应能提供一些指导。

快照

快照是备份的灵丹妙药，因为它们简单、不复杂（直到你想要恢复时）并且“就是能用”。不过，它确实需要提供商的一些帮助，并且大多只适用于你拥有 VPS（虚拟专用服务器）或类似服务的情况。我们“兼容提供商”文档中列出的若干提供商提供备份，无需网络管理员进一步干预或考虑。

传统备份针对文件和数据库，而快照针对整个磁盘。这意味着快照中不仅捕获了站点的数据，还包括操作系统和配置。对许多人来说，这是一个明显优势，因为可以几乎瞬间从快照生成一个新系统，并将其投入运行以替换出现问题的实例。同样，检索文件的恢复过程只需要将快照镜像作为磁盘挂载到现有实例，以便访问和复制文件。

快照可能会让托管服务提供商收取额外费用，但它是一份防范意外的保险。

外部脚本

似乎并不缺少用于备份 WordPress 和 MySQL 资源的外部脚本和解决方案，而这些方案也非常适用于 Ultimate Multisite，因为它是一个使用 WordPress 文件系统和数据库的 WordPress plugin。因此，能够备份 WordPress 站点的解决方案就足以覆盖 Ultimate Multisite 的需求。

我们无法推荐某一个脚本优于另一个，但我们的总体建议是运行多次备份和恢复测试，以确保结果符合预期，并通过持续评估脚本及其功能来“确保万无一失”，尤其是在应用了某种差异备份策略的情况下。

需要注意的是，这些脚本在运行时会增加系统负载，应将这一点纳入考虑。

Plugins

在 WordPress 中，几乎没有无法通过 plugin 解决的问题；如果管理外部脚本不是你的兴趣所在，那么 plugin 也许就是次佳选择。

尽管各个 plugins 在选项和功能上有所不同，但它们大多执行相同的功能，即复制 WordPress 文件和数据库内容。之后功能会有所差异，因为某些 plugins 可以将备份发送到 Google Drive 或 Dropbox 等外部服务，或发送到某种兼容的对象存储服务，例如 S3、Wasabi 或其他服务。更全面的 plugins 会提供差异备份，或某种仅备份已更改数据的策略，以节省外部存储成本。

在选择 plugin 时，请务必确认它支持 multisite。由于其运行方式，在备份运行期间，你可以预期服务器会有临时负载，直到该过程完成。

Domain 和 SSL

关于 multisite subdomain 模式中的域名，前面已经讨论了很多。对于网络管理员来说，一个几乎通用的解决方案是使用通配符 DNS 条目。

这种类型的 DNS 条目会将诸如 ‘site1.domain.com’ 和 ‘site2.domain.com’ 这样的 subdomains 成功解析到 1.2.3.4 这个 IP 地址，从而支持 Ultimate Multisite，并在更大范围内支持使用 subdomain 模式的 WordPress Multisite。

对于 HTTP 来说，这可能运行得非常好，因为目标主机是从 HTTP headers 中读取的；但如今的 Web 很少如此简单，安全的 HTTPS 事务几乎已成为必需。

幸运的是，SSL 证书有一些简单选项。在 subdirectory 模式中，可以使用常规域名证书。这些证书可以很容易地从托管服务提供商处免费获得，他们可能使用免费的 LetsEncrypt 服务或其他来源。否则，如果你能够生成证书签名请求，也可以从证书颁发机构商业购买。

对于 subdomain 模式，使用通配符 SSL 证书将与通配符域名完美配合，并允许该证书在无需额外配置的情况下对根域名及所有 subdomains 具有权威性。

不过需要注意的是，通配符 SSL 证书可能无法与 Cloudflare 等服务配合使用，除非你使用的是企业 plan，或者将条目设置为仅 DNS，在这种情况下，所有缓存和优化都会被绕过。

Ultimate Multisite 开箱即用地提供了一个解决此问题的方案，体现了我们对 WordPress multisites 需求的丰富经验。启用这个简单的 add-on 后，Ultimate Multisite 将使用你的 Cloudflare 凭据，自动为 Cloudflare 中的网络站点添加 DNS 条目，并将其模式设置为 ‘proxied’。通过这种方式，每个网络子站点在创建时都会拥有 Cloudflare 的完整保护和优势，包括 SSL。

根据你的 Ultimate Multisite 安装的性质和用途，客户可能需要使用自己的域名。在这种情况下，网络管理员需要解决两个问题。第一，域名的托管；第二，该域名的 SSL 证书。

对许多人来说，使用 Cloudflare 是一个简单的选择。客户只需将他们的域名放到 Cloudflare 上，将 CNAME 指向 Ultimate Multisite 的根域名，并在 Ultimate Multisite 中映射他们的域名，即可开始利用他们的自定义域名。

除此之外，还需要寻找替代解决方案，这也是 Ultimate Multisite 推荐 Compatible Providers 列表的原因。因为设置 DNS 和 SSL 的过程可能并不简单。不过，通过 Ultimate Multisite 与这些提供商的集成，复杂性被大大降低，流程也实现了自动化。

Plugins

你很可能需要额外的 plugins 来为你的客户或网络站点提供功能。所有 plugins 都能与 WordPress Multisite 和 Ultimate Multisite 一起使用吗？嗯，这取决于具体情况。

虽然大多数 plugins 都可以安装在 WordPress Multisite 中，但它们的启用和授权方式因作者而异。

挑战在于授权的应用方式，有些 plugins 要求按每个域名进行授权。这意味着对于某些 plugins，网络管理员需要在每个新站点上手动为每个 plugin 激活许可证。

因此，最好向 plugin 作者确认他们的 plugin 将如何与 WordPress Multisite 配合使用，以及授权它所需的任何特殊要求或流程。