几年前，我实现了一个类似于此的MU站点，在实现此方向之前，您需要考虑一些注意事项。
认为MU安装是访问管理多个，independent WordPress安装。它的运行方式与您在站点“/”的根目录中安装一个博客，然后在“/”子网站1”中安装另一个博客没有太大区别。
不同之处在于，您可以轻松地在一个站点到另一个站点的管理之间移动，以及跨站点管理插件、主题、更新和用户。但对于每一个其他管理任务，您都必须登录到实际安装。
因此，要编辑根目录上的内容，您必须登录到“/wp admin/”，要编辑“/subsite1”上的内容，您必须登录到“/subsite1/wp admin/”。
如果您在“/”和“/子网站1/”上具有相同的凭据，则可以通过菜单在它们之间移动，但它们是完全独立的站点。
最大的考虑是共享区域。正如我所说，MU站点彼此隔离。这意味着您不能在单个视图中与“/”（root）共享来自“/子网站1”的帖子，也不能在站点之间共享“交叉帖子”。如果您的需求要求跨“协会”共享帖子，或者协会将帖子共享到根站点，那么MU将不适用于您。
还有一些其他问题也阻碍了这一进程：
如果您有许多子网站（作为参考，我在这个安装中有100多个），管理是痛苦的。网站无法排序，下拉菜单溢出。因为它们是独立的站点，所以每个站点都必须单独添加用户，并且不能跨站点共享权限或特定于站点的配置。
而用户——我不会在这些网站上花一个月的时间，没有人在错误的网站上创建一系列帖子，并希望他们移动到另一个网站——用户很难判断他们正在编辑哪个网站。
MU+子域--这是一个很酷的特性，但我无法让一台主机来启用它。如果您有一台主机，它将为您在子域上运行MU做出更改，这太棒了——但您最好确保他们愿意先这样做。
有一些插件不能很好地与MU安装配合使用。
我不想听起来像是在抨击MU——我以10个站点的MU配置运行我家人的网站。它使插件和主题的更新变得轻而易举，大大缩短了我的管理时间。只要点击一个按钮，我就可以在任何时候出于任何原因创建一个新站点——这对于实验来说很方便。
但如果您需要它做更多的事情，那么MU可能不是您所需要的。
