我有多个共享数据库的Wordpress安装。我被特别要求不要使用Multisite。安装也共享相同的wp-content文件夹。这些网站是否也可以共享相同的插件选项？我找到了一种在网站上共享同一用户表的方法 - 但我不需要这些功能。我只需要能够在所有站点上全局设置插件选项。
如果这不可能或不实用，因为网站会有不同的网址等，如果我基本上可以拍摄主安装的插件设置的快照并在安装时将这些设置粘贴到数据库中，我可以解决它新安装。
我构建的是Wordpress安装启动器，它启动全新的wordpress安装，其中包含一组预定义的主题，插件，页面和设置。我已经完成了大部分工作。目前我可以填写一个表格然后解压缩自定义的基本wordpress包并安装它，创建页面内容，激活自定义主题和插件。所以，我现在需要构建此功能的最后一件事是在安装过程中设置一大堆选项。例如，我希望能够设置的一个选项是每次安装的标准默认徽标。另一个例子是我想为我正在使用的主题自动设置谷歌地图api键。我希望你明白这一点。
我在codex中找到了这个有用的页面： https://codex.wordpress.org/Creating_Tables_with_Plugins
所以在这一点上我认为我需要做的是从构建所有新安装镜像的镜像的基础wordpress中检索我需要的各种选项/设置，然后使用这样的代码：
$wpdb->insert(
$table_name,
array(
'time' => current_time( 'mysql' ),
'name' => $welcome_name,
'text' => $welcome_text,
)
);
以及上述codex链接中的其他相关代码，以便在安装过程中将所有数据插入到新的Wordpress安装中。
我认为我正在寻找的问题是：这看起来是正确而有效的方法吗？其次：在我的基本安装中检索所有现有插件的所有设置的工作感觉就像是一项费力的苦差事。有关快速识别和检索特定插件的选项/设置信息的方法的任何建议？
答案 0 :(得分：1)
网站是否也可以共享相同的插件选项？
没有
这看起来是正确且最有效的方法吗？
不，当然不是。它使您成为您使用的每个插件的开发人员。那是完全不合理的。
安装程序也共享相同的wp-content文件夹。
如果这样可行，那将是一个奇迹。 WordPress的一部分根据自己的数据库表中的内容将文件名分配给该文件夹中的文件。你怎么可能防止碰撞？
我被特别要求不要使用Multisite。
拒绝此请求。 跑步，不走路，远离傻瓜做出这种完全无理的要求。或者花费你生命中的下一年使用FrankenPress安装，总是脆弱。可以从中获得的唯一好处是什么？你会有一个有趣的提交给http://thedailywtf.com/，所以我们其余的人可能会悲伤地摇头。
让我向您提供一些您可以使用这种方法的论据。
WordPress是一个长期存在的代码库。它有许多核心开发人员和成千上万的插件开发人员。多年来，它已经为各种组件的合作建立了一套标准。有些，但绝不是全部，这些标准是正式的。允许插件和主题开发人员做他们想要的任何不违反正式标准的事情，并且不会破坏WordPress。实际上，他们被允许打破WordPress。如果他们这样做，他们的插件和主题得分很低。它是一个庞大的软件生态系统，是最大的软件生态系统之一它几乎可以工作。
WordPress的创建者已将单站点和多站点安装方案放在一起。这些方案已在各地进行了大规模测试，而不是偶然在WordPress.com上进行测试。他们几乎工作。
但是，插件，主题和WordPress核心的更新源源不断。这些更新解决了安全问题并添加了功能。 “他们想要的任何东西”规则适用于更新和新项目。所以，如果你认为你知道一个特定的插件如何工作，并且作者更新了它，你就不知道明天它是如何工作的。或者，也许你明天知道它是如何工作的，但你必须检查代码或测试它。
WordPress团队建立了Multisite来处理您的雇主似乎想要的东西。您的雇主似乎已说服您构建另一个版本的Multisite。除非你的名字恰好是Matt Mullenweg，否则你的生命中可能没有足够的时间来做到这一点。即使你十五岁。
犯错的后果将是严重的。现场安全和稳定性将受到影响。插件更新将中断。有些主题可行，有些则不行。某些网站访问者将看到属于他们访问过的网站以外的网站的内容。
你的老板可以说，“我想乘火车前往纽约市。但我不想坐火车。这是一个火炬：把一些钢轮焊接到我的车上。顺便说一句，你是和我一起来。“你有什么要说的？你可以谈谈铁路信号，关于安全，交换机，各种列车的运行速度，以及大中央车站的复杂情况等等。而且，你可以说，“不。”如果你愿意，可以说出所有的东西。但请说“不”。
有些插件可以很好地快速克隆WordPress安装以支持新安装。它们保留了插件设置。