禁用大选项的自动加载

[马克贾奎斯]

我在WordPress网站上经常遇到的一个问题是，由于有一个巨大的选项正在自动加载，速度极慢。有时，这是一种缓存选项，一个粗心的插件让它自动加载，并且已经增长到几十兆字节。

自动加载如此大的选项不仅会减慢选项加载查询的速度（在每次加载时可能不需要该选项），而且在具有对象缓存的站点上，它会导致分配选项缓存的大量磨损。把一个大的选项和一个经常更新的选项结合起来，你就有了一个非常缓慢的网站的诀窍。

我们应该考虑防止选项增长到一定大小时自动加载。在我的脑海中，100kb听起来是一个合理的上限。我们可以监视选项设置/更新并查看进入的选项的大小。如果它高于某个（可过滤）边界，我们可以强制关闭自动加载。

增加选项大小的硬限制为150kb。还将autoload的新默认值添加到default。

Trac票：https://core.trac.wordpress.org/ticket/42441

[spacedmonkey（空格键）]

我有一个公关的开始​#4881.

[弗利克索斯90]

根据我对公关的反馈，我认为它采用的方法太复杂，把太多的责任放在一个单一的职能上。所以我认为这需要一次迭代。

需要考虑的是，我们是否应该将这些值更改为默认-

​https://github.com/WordPress/WordPress-develop/blob/60d2d8ac75c4350a45e4c6970c7d0295b757f1f0/src/wp-admin/includes/schema.php#L593-L597型

​https://github.com/WordPress/WordPress-develt/blob/60d2d8ac75c4350a45e4c6970c7d0295b757f1f0/src/wp-includs/option.php#L1283-L1285码

[弗利克索斯90]

@markjaquith@boonebgorges任何机会你都可以看看公关​https://github.com/WordPress/WordPress-develop/pull/4881? 很高兴能了解您的想法。

[spacedmonkey（空格键）]

这张票在​WordPress核心性能聊天今天。大家一致认为，这张票需要更多的时间来烘烤和获得社区的反馈。打桩至WP 6.5

[spacedmonkey（空格键）]

我无法在WP 6.5中处理此票据，将自己作为所有者移除。

代码刷新

代码刷新

[伯恩]

我已经刷新了代码

我发现测试失败了
update_option（）函数正在正确清除缓存

已准备好合并

收盘时有利于#5671，对其进行迭代。

[弗利克索斯90]

我刚刚通过@pbearne查看了新的PR，尽管需要更多的更改，但它在功能上对我来说非常好。

另外，我想谈谈关于自动加载列返回到此票据，以与特定PR实现解耦。

包括新值（无论是否调用违约Y/默认-否或其他内容）不仅是此更改的“副作用”。要求使期权最大规模的阈值可靠工作。原因如下：

• 选项并不总是保持相同的大小。一个选项可能会添加一些非常小的起始/占位符值，但之后会变得更大，这取决于该选项的使用方式以及最终用户如何与相关功能交互。
• 因此，至关重要的是，我们不仅要在添加选项时执行最大大小检查，而且还要在更新选项时执行。
• 为此，除非开发人员显式地将值传递给更新选项（）（当您只想更新选项时，这样做并不直观价值)，我们需要看看之前存储的自动加载值是否是开发人员选择的显式值(是|否)或者不是(default-yes |默认否). 在后一种情况下，我们必须重新检查选项大小。但在第一种情况下，我们不能这样做，因为我们需要尊重开发人员的明确选择。
• 换句话说，要确定显式设置的自动加载值和“WordPress选择的”自动加载值，需要在数据库中进行这种区分。

我能想到的唯一替代方案是完全取消$自动加载参数，并将其作为设置注册或独立注册选项的自动加载值的单独方法的一部分进行处理。然而，这将产生更广泛的影响，并影响到比当前提议的增加对两个以上数据库值支持的实现多得多的插件。只有围绕自动加载选项实现其自身功能的插件（例如某些数据库优化插件）才需要更新当前的建议，而更广泛地转向自动加载注册将带来更大的破坏性，并影响各种插件。

[伯恩]

或者我们可以阻止所有大型选项自动加载

即使这样，也可以通过添加一个延迟过滤器将限制设置得足够高来解决问题

认为这是一个好的开始，但需要更多的考虑/改进，尤其是在工作方式上。为DB列添加两个新值的支持似乎不错，但更改函数签名却不行。添加了一些代码注释和建议。

还认为这个补丁应该引入一个过滤器，允许个人决定自动加载打开或关闭被插件覆盖。试图通过无效的（意思是“未决定”）添加新选项不是实现imho的好方法。

此外，此修补程序的想法需要进行彻底的性能测试。始终需要的自动加载选项对于提高性能至关重要，即使它们的值“很大”。额外前往数据库的费用通常要高得多。

也在想违约Y和默认-否听起来不太好，可能会误导人。在添加选项时，似乎有可能被误认为是默认选项，这是错误的。

怎么样自动挡（auto-yes）和自动-否? 有汽车在中，很明显此设置是自动的：）

[阿佐兹]

回复伯恩:

或者我们可以阻止所有大型选项自动加载

嗯，对于经常使用的选项来说，这将是一个巨大的性能损失。到DB的额外跳闸可能会慢数百倍。

已经在公关上提到了这一点，认为这需要对不同的场景进行大量的性能测试。最重要的是，当每次页面加载或第二次页面加载时使用的大选项关闭自动加载时，会发生什么情况。

感谢你的反馈@azaozz，我对个人观点做出了回复。

关于这个名字，我同意违约Y和默认-否听起来不太好。我喜欢你的提议自动挡（auto-yes）和自动-否.

我会在这里回复，所以这也会显示在火车票上。发件人​https://github.com/WordPress/WordPress-develop/pull/5671#discussion_r1419653637:

@阿佐兹，我不认为这真的是卑诗省的休息。虽然函数上的值在默认情况下不再是yes，但有效结果。。。

这是一个常用函数中行为的变化。到目前为止，所有想要添加自动加载选项的扩展器都会忽略最后一个参数，因为它默认为对。但是，如果提交了此修补程序，情况将不再如此。值超过特定阈值的选项将设置为不自动加载。

这种做事方式还有另一个缺点。如果插件想要覆盖自动决策，它必须以不同的方式进行：一旦通过对添加选项时，然后使用wp最大自动加载选项大小（或者可以添加新的过滤器以使其更直观），以确保这在未来不会自动更改。非常令人困惑，为什么不直接使用过滤器？：）

更改默认值的原因是为了正确区分开发人员是通过了“是”还是只是默认的“是”/“自动”。

为什么这很重要？我认为这更多的是一个“这应该如何实际工作”的讨论。问题是：开发人员应该如何覆盖关闭自动加载的自动决策？

我希望每个选项都能使用一个过滤器，这是WP在许多不同情况下常用的方法。使用这种过滤器的另一个优点是，当选项值的大小超过阈值时，添加该选项的插件将能够覆盖将autoload设置为off的决定。（据我所知，当前代码没有涵盖这种情况）。

通常选择如下：

1. 要求扩展器更改代码并通过对用于在添加新选项时自动加载。此方法无法解决当选项在更新时变大时会发生什么情况的问题。当前的行为是，当它是一个预先存在的选项时，将其关闭自动加载，或者为应用此修补程序后将添加的选项打开自动加载（请参阅此处提前返回的代码：​https://github.com/WordPress/WordPress-develop/pull/5671/files#diff-ca21e48c46c9dd91f8e8b8837f147aed99457233f8a04ef458205d81e3R1173-R1180).
2. 添加一个新的过滤器，使扩展器始终覆盖由新的确定选项自动加载值（）功能。

发件人​https://github.com/WordPress/WordPress-develop/pull/5671#discussion_r1419698845:

与我在中的回复相关​https://github.com/WordPress/WordPress-develop/pull/5671#discussion_r1419694609，我们需要区分“默认/自动”和“手动”行为
...
此代码检查当前值是默认/自动值还是显式提供的值
...
如果我们强制使用新的自动化方法，我会认为这是BC中断。

是的，我理解。问题是，这种管理自动加载的方式似乎不直观，而且与现有代码正好相反。即，目前所有呼叫添加选项（_O）第三个参数可能依赖于自动加载选项。从现在起，情况将不再如此。更改默认值对到犹豫不决的也会改变函数的行为。

为了能够处理这个问题，我还认为我们可能会远离对和不作为值，并引入新值以强制自动加载（或同时强制自动加载和非自动加载？）。看起来这将以简单直观的方式解决这一问题，并且不会对现有行为带来任何改变。

@阿佐兹

这是一个常用函数中行为的变化。到目前为止，所有想要添加自动加载选项的扩展程序都会省略最后一个参数，因为它默认为对。但是，如果提交了此修补程序，情况将不再如此。值超过特定阈值的选项将设置为不自动加载。

没错，这是一个行为上的改变，但它只会影响很小的选项子集——150 KB是很大的一部分。另一个注意事项是，这乐观地假设extender_intentially_不会通过$自动加载参数，因为他们希望选项自动加载。由于自动加载选项本身是一个非常低级的概念，我的直觉是，大多数扩展器都没有太多考虑是否自动加载选项，换句话说，我经常认为这不是一个有意识的决定。

这种做事方式还有另一个缺点。如果插件想要覆盖自动决策，它必须以不同的方式进行：一旦通过对添加选项时，然后使用wp最大自动加载选项大小（或者可以添加新的过滤器以使其更直观），以确保将来不会自动更改。很困惑，为什么不直接使用过滤器？：）

这里并不是建议这样：建议的方法是$自动加载参数继续控制选项是否自动加载。如：如果扩展器通过对或不，WP核心将永远改变这一点。

如果我理解正确的话，你在这里描述的内容（需要使用一个新的过滤器来覆盖核心决策）将是一个突破性的变化，其影响将比上述更大：如果WordPress核心不再考虑_explicitly_ passed对或不，这比更改默认值更严重，因为这意味着$自动加载参数实际上变得毫无意义。

为什么这很重要？我认为这更多的是一个“这应该如何实际工作”的讨论。问题是：开发人员应该如何覆盖关闭自动加载的自动决策？

请参见上文。如果自动决策需要被过滤器覆盖，这是一个突破性的改变，因为这意味着WP核心不再尊重扩展器何时通过对或不到函数。

更改默认值对到犹豫不决的也会改变函数的行为。

这是正确的。尽管如上所述，但由于有意设置较高的阈值，实际变化的表面积非常小。更重要的是，这里的关键问题是当前的默认值对.IMO一开始就不应该有违约，否则应该一直默认“我们为您选择”。

虽然这个默认更改确实是一个突破性的更改，但我认为这是一个非常低严重性的突破性更改，不会影响许多插件/选项，也不会对现有站点产生太大影响，因为这些选项已经存在于数据库中对或不。在这种情况下，我认为这种突破性的小变化带来的好处大于其成本。

为了能够处理这个问题，我还认为我们可能会远离对和不作为值，并引入新值以强制自动加载（或同时强制自动加载和非自动加载？）。看起来这将以简单直观的方式解决这一问题，并且不会对现有行为带来任何改变。

这实际上是无效的价值在PR中的含义与当前相同。但是，只要对仍然是默认值，这不会有多大帮助，因为对根本不是一个好的违约（基于上述原因）。

@felixantz感谢您的回复和澄清。

没错，这是一个行为上的改变，但它只会影响很小的一部分选项——150 KB对于单个选项来说是很大的。

是的，我同意这个机会很渺茫。但如果这种情况发生在一个更流行的插件中，那么可能会有数千个网站受到影响。理想情况下不应该有这样的机会：）

如果延长线通过“是”或“否”，WP核心将永远不会改变这一点。
...
请参见上文。如果需要用过滤器覆盖自动决策，这是一个突破性的更改

是的，有道理。因此，对于现有插件，更改自动加载永远不应该自动进行，因为直到现在为止，假设没有使用第三个参数添加选项（_O）表示该选项将自动加载。这是多年来的默认情况。那么，WP更改自动加载的唯一方法就是插件选择插入，对吗？

但更重要的是，这里的关键问题是当前的默认值是对.IMO一开始就不应该有违约，否则应该一直默认“我们为您选择”。

哼，是的，如果我们能回到过去，把它设置成那样，那就太完美了
（如果我没记错的话，早期版本的WP没有自动加载。它是在2.3或2.5中添加的。这就是违约的原因对因为这是一个巨大的性能改进。）

这就是PR中null值的实际含义

是的，在某种程度上。然而，它的缺点是不够清晰，改变了函数的当前行为，而且我认为通过无效的可以使用（或曾经使用）来关闭自动加载。所以使用无效的没有合适的。

坦率地说，我认为对和不应该是“软deprecated”，并且应该有全新的值来更好地控制自动加载。也许在思考启用，已禁用,自动启动的和“自动禁用”最有意义。

然后对将保留为默认参数值，以支持大量现有插件，并将作为启用。在某种程度上，甚至现在，WP可能会开始发出“弃用值”警告，因此插件将逐渐更新，以决定是自动设置自动加载还是关闭自动加载，并使用新值。

另一件我仍有点不确定的事是，当每次加载页面时都需要一个“大选项”时会发生什么。如果未自动加载此选项，将单独访问数据库以获取它。似乎这将是一个相当大的性能下降，需要在添加此修补程序之前解决？

也在想违约Y和默认-否听起来不太好，可能会误导人。在添加选项时，似乎可能会与默认值发生错误，这将是错误的。

怎么样自动-yea和自动-否? 有汽车在中，很明显此设置是自动的：）

改变

oload将单独访问数据库以获取它。看来这将是一个相当大的性能下降，需要在之前解决

使用过滤器，开发人员可以允许/强制加载大选项

[伯恩]

我已尝试清除已发行的募集资金
请重新检查

我修复了测试不工作（主要是由于过滤器名称更改
但在strlen（）中也存在PHP 8+不喜欢null的问题

正如我所想的那样，我认为我一直坚持的是，如果core不能区分由于默认或出于意图而添加到数据库中的选项和autoload值为“yes”的选项，那么目前就无法改善自动加载的情况，这就是让这些决定变得困难的原因。

我认为，如果解决方案是禁用一些自动加载选项，而不考虑更改数据库中默认值记录方式的路径，那么不仅考虑到这一点，而且考虑到未来的增强功能，我们将处于劣势。

看看@azaozz的建议：

坦率地说，我认为“是”和“否”应该是“软编码”，应该有全新的值来更好地控制自动加载。思考启用、禁用、自动启用和自动禁用可能是最有意义的。

然后yes将保留为默认参数值，以支持大量现有插件，并将作为启用状态保存到DB。在某种程度上，甚至现在，WP可以开始发出“deprecated value”警告，因此插件将逐渐更新，以决定是可以自动设置自动加载，还是可以关闭自动加载并使用新值。

我认为“是”的轻蔑是一种解决方案，但我认为“否”是可以信任的，因为这必须显式传递给选项。另一个选项是对标记为“yes”的现有选项运行更新例程，并将其更改为“enabled”。我们可以将此与将默认参数保存到数据库的方式的行为更改相结合，从那时起，自动加载选项的值如下：

• 对–该值添加了一个显式值“yes”
• 启用–该选项添加了未知的显式值，但之前设置为“yes”
• 违约–如果没有传递显式值，WP可以决定在未来更改默认行为（最初将自动加载）
• 禁用–添加该选项时没有明确的“是”或“否”自动加载值，WP已选择禁用该选项。
• 不–该选项添加了显式自动加载值“no”。

这将使我们处于未来的状态，我们可以更改未来的自动加载默认值，并在数据库中区分依赖默认行为的选项、已显式设置的选项、以编程方式启用的选项（例如，因为它们是现有值）或禁用的选项（比如，因为它们太大）。

感谢您的额外反馈@azaozz@joemgill。我认为一个贬低策略是可行的。然而，我想确保它的好处不仅仅是命名。根据您的建议，以下内容如何：

1. 对和不将不赞成启用和禁用.
2. 将出现弃用警告来替换这些用法，但最初没有功能更改：最初启用将以与对和禁用行为方式与不.
3. 在未来的WordPress核心版本中（在上面的版本已经推出之后），新的行为将到位：
   • 对将被视为非上市价值。任何对传递给函数或存储在数据库中的可能会被WordPress自己的“决策过程”覆盖（即。自动启动的除非选项值太大，否则它将变为自动禁用).
   • 不仍然可以被视为显式值，即其含义与禁用.
   • 函数将获得一个新的默认值，允许WordPress做出决定。可能是这样无效的或自动启动的例如，我们喜欢哪一种。
   • 可能有一个数据库清理例程来迁移所有不值到禁用以及所有对值到自动启动的（潜在的相关人员甚至自动禁用). 不过，这对功能来说并不重要，主要是为了清理，并立即为现有选项带来好处。

我认为这将为站点和插件提供一个良好的迁移路径，并且在核心端不需要迁移例程（这只是一个很好的选择，也就是说，如果它没有运行，比如在一个非常大的站点上，仍然可以正常工作）。

唯一棘手的部分是：如果我们反对对和不但仍然保持对默认情况下，我们会向那些甚至没有传递弃用参数的人发出大量弃用通知。如果我们想遵循这样的假设，即一些开发人员会忽略参数来获取对。但在弃用值实际上没有传递给函数的情况下触发弃用通知仍然有点奇怪。🤔

回到我的建议，我认为如果我们执行以下操作，就根本不需要触发任何否决通知：

1. 使用自动更新数据库中的所有选项自动加载设置为对到启用.
2. 更改默认值$自动加载的值添加选项（_O）从对到无效的（匹配更新选项（）已经）。
3. 保存使用创建的任何新选项$autoload=空值为违约.
4. 更新此PR，以便添加自动加载值为的任何新的大型选项无效的改为设置为禁用.
5. 更新自动加载功能，以便将任何选项设置为对,启用，或违约自动加载（保持当前行为）。
6. 鼓励开发人员更新代码以显式传递$自动加载的值对或真的如果大多数请求都需要该选项。
7. 考虑将来的更改，停止自动加载设置为的选项违约.

理想情况下，我们能够从存储的DB值中区分该选项是否显式设置为autoload，是否由core启用/禁用，或者是否设置为默认值且不受core影响。

@乔麦吉尔谢谢你的澄清，我想我现在明白你的意思了。

我相信你的提议与公关迄今为止的提议基本一致，除了命名。你的提议中有一点我不明白：目的是什么启用? 看起来它只能替代对? 在这种情况下，与只使用现有的对价值？

就我所知，我会同意你的提议。但我认为它并没有解决@azaozz所表达的担忧，即它仍然会涉及更改函数的默认行为（从“总是自动加载”更改为“仅当选项值不太大时才自动加载”）。

enabled的用途是什么？看起来它只会取代yes？在这种情况下，仅仅坚持现有的“是”值有什么好处？

目前，站点在数据库中有自动加载值设置为“yes”的选项，但无法知道这些选项是显式设置的还是默认设置的。将这些更改为启用允许我们出于向后兼容性的原因尊重他们当前的行为，并在未来的状态中知道显式设置的选项之间的差异（即。，对)或依赖默认行为（即。，违约). 我认为，能够做出这些决定对我们适应未来需求至关重要（尽管我对所使用的确切值没有强烈的感觉）。

为了解决@azaozz的担忧，我们可能会无意中停止自动加载实际用于大多数请求的大型选项启用value还为我们提供了以编程方式标记自动加载选项的机会，即使它没有显式设置。作为一个假设的例子，我们可以开始监控设置为违约然后将它们设置为启用或禁用取决于使用情况，而不仅仅是大小。

没有一些值来区分显式(对)和默认的自动加载，我不确定我们如何才能安全地改变行为。

@乔麦吉尔

目前，站点在DB中有自动加载值设置为“yes”的选项，但无法知道这些选项是明确设置的还是默认设置的。将这些更改为启用允许我们出于向后兼容性的原因尊重他们当前的行为，并在未来的状态中知道显式设置的选项之间的差异（即。，对)或依赖默认行为（即。，违约). 我认为，能够做出这些决定对我们适应未来需求至关重要（尽管我对所使用的确切值没有强烈的感觉）。

我懂了。所以在你看来对是显式值，并且启用非plicit/潜在WordPress已确定？

我想我们可能只是被对方的命名搞糊涂了。100%我们需要能够区分显式集合对与a相比对默认情况下。到目前为止，在讨论中，这将通过以下方式实现对与自动挡（auto-yes），或在我最近的提案中​https://github.com/WordPress/WordPress-develop/pull/5671#问题评论-1852837985通过启用与自动启动的.

当我们试图确定解决方案时，命名当然是次要的。所以我认为我们基本上是在用稍有不同的方法说同样的事情（例如，是否有一个反对/过渡期来准备行为的改变）。

是的，我确实认为我们很接近。我看到的主要区别是，我还希望能够区分应用默认行为的选项和受核心影响的选项（例如，默认与启用/自动或禁用/自动否）。我也不记得有人建议将当前设置的值从“yes”更改为其他值，以便使“yes（是）”前进到显式设置的值，尽管我可能刚刚错过了它。

@乔麦吉尔

我看到的主要区别是，我还希望能够区分应用默认行为的选项和受核心影响的选项（例如，默认与启用/自动或禁用/自动否）。

我当然也想要。公关部目前通过以下方式实现对和自动挡（auto-yes）.

我也不记得有人建议将当前设置的值从“yes”更改为其他值，以便使“yes（是）”前进到显式设置的值，尽管我可能刚刚错过了它。

没错，这确实不是公关中的内容，也不是我提议的内容。在我看来，所有存在的对数据库中的值将被简单地视为显式的，尽管其中许多可能不是。换句话说，新的行为只会在WordPress中启动时开始。旧的价值观保持不变，即随着时间的推移，这将逐渐导致改善。

虽然我不反对你提议的迁移程序，但我认为保留旧的价值观并假定它们明确（出于安全原因）的好处是：

• 没有迁移失败的风险（例如，在大型站点上，这些问题可能会引起关注）。
• 降低生态系统中大规模负面影响的风险：即使插件不迁移（或不立即迁移）到新推荐的方法，对最终用户的负面影响也有限。由于DB中的现有选项将继续像以前一样工作，因此只会影响新站点或新安装插件的站点。这当然不会降低风险，但它大大降低了出现“红色代码”问题的可能性。

@felixantz在几周后回到这里，我认为澄清我认为我们应该处于的最终状态可能会有所帮助，而不是专注于一些命名/实现细节。在我们现在进行任何更改之前，先将已经存储在数据库中的任何选项放在一边，将来我们希望能够区分具有显式设置的自动加载值的选项，以及基于类似于此的启发式（即选项大小）设置的自动加载值，以及那些仅仅依赖WordPress默认行为的选项。为了避免与当前的是/否值混淆，我们假设数据库中至少有三个值：

• 在–该选项添加了明确的真实自动加载值（即不依赖默认参数），并将自动加载
• 汽车–添加该选项时未传递显式自动加载值。根据当前行为，这些仍将自动加载。
• 远离的–该选项添加了明确的错误自动加载值，不会自动加载。

这将允许我们做出明智的决定，确定添加选项时是否明确表示要自动加载，而不是当前状态，我们不知道选项的自动加载值是“是”，是因为开发人员的意图，还是因为他们没有指定任何自动加载值。在我看来，如果我们希望能够做出明智的决定，决定DB中已经存在的选项是否可以在未来停止自动加载，或者甚至在极端情况下决定WP在默认情况下不再自动加载选项，那么这种区别是至关重要的。

也就是说，该PR引入了一个新概念，其中添加了一个没有显式自动加载值的选项，将添加一个自动加载值，该值将允许我们在默认情况下不自动加载。为此，我们需要在上述三个值中引入第四个值，例如。，自动关闭，这意味着该选项是在没有显式自动加载值的情况下添加的，但不会根据某些条件自动加载（本例中为选项大小）。我们可以暂时停止这四种状态，但在我看来自动关闭意味着需要自动接通值，这意味着该选项应该自动加载，即使将来我们决定默认停止自动加载。对于这样一个值，一个完全理论化但有效的用例将是一个很大的选项，我们已经确定自动加载应该是安全的，因为在每次加载页面时都会调用它。因此，我建议我们在数据库中为选项（最终值名称待定）提供5个新的可能自动加载值：

• 在–该选项添加了明确的真实自动加载值（即不依赖默认参数）。此选项必须自动加载。
• 自动打开–添加选项时没有明确的自动加载值，但应该自动加载。
• 汽车–添加该选项时没有明确的自动加载值。WordPress可以确定此选项是否应自动加载（为了与过去的行为保持一致，我们最初仍会自动加载这些值，但将来可能会改变）。
• 自动关闭–添加选项时没有明确的自动加载值，但不应自动加载。
• 远离的–该选项添加了一个显式错误的自动加载值，不得自动加载。

由于以上是我建议我们瞄准的未来状态，我们需要考虑如何处理数据库中已经存在的选项，在这些选项中，我们无法确定是基于显式还是隐式（默认）意图自动加载选项。我之前建议添加一个DB更新例程，将之前设置的所有选项都设置为对到新的自动接通价值观是对新的意图充满信心的一种方式在值。然而，我承认这会带来一些风险，所以我很高兴前面的建议只是贬低旧的对和不值，并用一组新值替换它们，因为这两个值都解决了相同的问题。

此线程中似乎存在一些分歧的最后一个考虑因素是应该对默认参数的添加选项（_O）函数以实现此新的自动加载策略。在这里，我看到了三个选项：

1. 保持原样，$autoload=“是”，但使用类似于函数获取args（）以确定是否传递了显式值。如果不是，那么我们可以确定该选项是否应该自动接通,汽车，或自动关闭然而，如果我们反对对IMO，将其作为默认值有点奇怪。
2. 将默认值更改为既不真实也不虚假的新值，以指示该选项可能不会自动加载。我想$autoload=空有道理，或者类似的$autoload=“默认”或$autoload=“自动”以便更好地向开发人员传达此默认的意图。其中之一是我的偏好。
3. 只要默认情况下我们仍然自动加载大多数选项，就可以将默认参数值更新为与新策略一致的不同真实值。就个人而言，我只需要更新代码，使其成为布尔值真的默认值，已受支持，不推荐使用对或不，但我们也可以设置默认值在或者不管新的显式DB值最终是什么。

希望这么长时间（对不起😬 ) 解释有助于澄清我认为我们应该达到的目标，并制定一些可能的下一步行动。

@乔姆吉尔谢谢你的详细报道，这很符合我的想法。其他一些想法/注意事项：

• 我真的很喜欢在和远离的作为新条款。IMO它们与自动-前缀比启用和禁用我还认为它们在语义上更接近于自动加载的“是”和“否”。无论如何，我对所选的名字没有强烈的感觉（除了它们应该与对和不)特别是因为我认为从外部开发人员API的角度来看，鼓励使用布尔值是最有意义的真的和假大多数插件开发人员不需要担心数据库中实际存储了哪些字符串，这只对一小部分明确关注自动加载选项的插件来说很重要。
• 我认为自动接通,汽车和自动关闭这是有意义的，特别是因为它允许将来对逻辑进行优化，以决定是在核心还是插件中自动加载。我最初以为只有自动打开和自动关闭，但很好的一点是，从这张罚单开始，核心将做出的唯一决策是“不”决策。虽然到今天为止，任何不是“否”的东西都会自动加载，但我同意有必要区分“核心决定是”和“核心根本不知道”。从今天起，两者都将自动加载，但它允许差异化，这对于进一步增强自动加载优化的潜力至关重要。
• 如果在调用时没有提供显式值，可能应该存在某种过滤器，以允许附加逻辑来决定“自动”值添加选项（_O）例如，它可以是wp默认自动加载值过滤器，可以返回真的,假，或无效的，这将被解释为自动接通,自动关闭、和汽车分别。
• 关于添加选项（_O）默认，我认为应该改为无效的，原因如下：
  • 它是一个中性值，没有任何意义。
  • 它与中已使用的默认值相同更新选项（）.
  • 它是向后兼容的，因为今天显式传递无效的（这没有多大意义，但有可能）将获得与通过相同的结果对.
• 根据我的第一点，我建议我们鼓励开发人员通过真的,假，或者什么都没有(无效的)至添加选项（_O）.对和不BC仍需要支持，我们甚至可以支持在和远离的，但我认为这毫无意义，因为从插件开发人员的角度来看，所有这些都是相同的。示例代码/文档应始终使用真的和假，参数doc可能会说类似“为了向后兼容，支持值‘yes’和‘no’。”。

谢谢@felixantz。考虑到你上面的前2点，听起来我们同意使用5个值，现在可能只需使用该命名即可。我很高兴我们能够在DB中继续使用“yes”和“no”值（就像上面的@azaozz一样），所以这似乎是一个很好的下一步。

我完全同意您的观点，添加过滤器以允许第三方代码覆盖/增强WP的决策可能是有意义的，并且符合您的建议要求。

我还同意将默认的自动加载参数值从“是”到无效的这是最有意义的。同时无效的在某些情况下可以评估为假，我同意这里最好将其解释为中性值，并更好地符合不传递显式值_could_会导致选项未自动加载的期望。

我现在没有什么要补充的了😄

[伯恩]

我已经更新了拉请求以匹配新值

我相信我已经做出了所有的改变

关于当前方法的几个悬而未决的问题：

• PR当前将序列化的选项值传递给新函数以确定自动加载值，并从那里传递给新过滤器。这是个好决定吗？我意识到当前的用例只需要序列化数据，但我觉得这对于API来说有点奇怪。我认为传递常规选项值会更干净。如果我们想避免打电话可以序列化（）再说一次，也许我们应该通过价值$_和_$serialized_value（美元序列化值）功能？
• 现在有4个值需要自动加载，在（显式），对（传统），自动接通（“开”，但由默认启发式确定），以及汽车（默认试探法没有做出明确的决定，但仍需要自动加载以实现向后兼容性）。IMO它很容易出错，不得不到处记住这些单独的值（在代码审查期间已经发生了几次），从扩展程序的角度来看，这也不太好（想想那些专门做自动加载选项的小插件）。也许我们应该有这样的功能wp_autoad_values_to_autoad（）或者像这样返回这些值的数组？也许有一个更好的函数名，但我认为这对核心插件和相关插件都很有用。

@请让我知道你对这些观点的看法。如果您能再次对该方法进行评估（当然还有实施该方法的公关部门），那将是一件非常棒的事情。

关于当前方法的几个悬而未决的问题：

• PR当前将序列化的选项值传递给新函数以确定自动加载值，并从那里传递给新过滤器。这是一个好决定吗？我意识到当前的用例只需要序列化数据，但我觉得这对于API来说有点奇怪。我认为传递常规选项值会更干净。如果我们想避免打电话可以序列化（）再说一次，也许我们应该通过价值$_和_$serialized_value功能？
• 现在有4个值需要自动加载，在（显式），对（传统），自动接通（“开”，但由默认启发式确定），以及汽车（默认试探法没有做出明确的决定，但仍需要自动加载以实现向后兼容性）。IMO——在任何地方都必须记住这些单独的值是很容易出错的（在代码审查期间已经发生过几次了），从扩展程序的角度来看（想想少数专门针对自动加载选项的利基插件），这也不太好。也许我们应该有这样的功能wp_autoad_values_to_autoad（）或者像这样返回这些值的数组？也许有一个更好的函数名，但我认为这对核心插件和相关插件都很有用。

@请让我知道你对这些观点的看法。如果能再次获得您对该方法的评估（最全面的概述请参见​#5671（评论）)当然，公关部也在实施。

我同意这两点

[伯恩]

进行了更改

[伯恩]

我已经修复了tests/wp_load_alloptions（）函数

让我们尽早在6.6之前标记这个

[弗利克索斯90]

公关部​https://github.com/WordPress/WordPress-develop/pull/5671看起来很不错。提前将其标记为6.6，以获得一些额外的时间来解决潜在的怪癖。

@乔麦吉尔很想得到你的反馈​https://github.com/WordPress/WordPress-develop/pull/5671#discussion_r1522049679从API的角度来看，这有点难看（我们不应该“支持”不支持的值），但足够简单，从向后兼容性的角度来看也不错。例如，如果一个插件传递如下内容1今天，我认为继续将其视为明确的“是”正如今天评估的那样，纯粹是为了不列颠哥伦比亚省。另请参阅我的评论​https://github.com/WordPress/WordPress-develop/pull/5671#discussion_r1522051375这就是我最初指出的潜在问题。

让我知道你的想法。

@felixantz我留下了关于​您的评论在里面​我的公关审查。但由于这在Trac中没有显示，我将总结一下：

从技术上讲，我同意，但我认为最好还是暂时保持原样，而不是创造机会让意外值被支持为“真”，然后等待真正的错误报告来确定是否需要处理其他值。

@joemgill回复您的反馈：

从技术上讲，我确实同意@felixantz的担忧​在这里尽管我认为最好是暂时保持原样，而不是创造机会让意外值被支持为“true”，然后等待真正的错误报告来确定是否需要扩展switch语句中的检查。

我大体上同意您的评估，但忽略这一点实际上破坏了以前存在的单元测试。对我来说，这是一个合理的指标，我们需要有这个条件来将技术上不支持的值转换为真的对于BC。这并没有真正改变这是否是一个理论问题，但我们之前添加了测试，确保这些不支持的值的计算结果为真的，所以我会对删除这些测试感到不安。

LMKWYT。

啊，我错过了之前的测试。在这种情况下，我会优先考虑确保以前的测试仍然通过，尽管可能值得回顾一下为什么测试是以他们本来的方式编写的，以查看它们是否不必要地广泛

@乔麦吉尔看看这些测试的来源，它们都很古老，来自https://core.trac.wordpress.org/tickt/31119/https://core.trac.wordpress.org/changeset/31278.

因为当时是一个布尔值假最终成为“是”当然毫无意义，添加了这些测试，它们还断言，几乎所有其他东西最终都会“是”.

不管怎样，我对这里的行动方针都没有强烈的感觉。我不认为改变这些测试实际上有很大的危险，因为它不太可能像数组（）传递给此函数-为什么有人会这样做？：）和往常一样，我确信这会发生，但这可能与大规模谈话无关。更重要的是，如果我们删除BC处理，这样的选项通常会导致汽车，这将导致它仍然自动加载。因此，该更改唯一真正的“风险”是，该值不再被视为显式的，因此可能在某些时候被核心覆盖。

最后，我可以删除BC处理并调整相关测试以断言“自动”而不是“是”。考虑到其他情况，如果你仍然支持，请告诉我。

@felixantz我想我错过了什么。看看这个公关​您引用的测试用例似乎没有改变（除了改变是/否到开/关).

@乔麦吉尔这是我的观点。他们现在没有改变，因为公关包括额外的业务连续性处理。但如果我删除它，它们就会失败，因此需要进行更改以期望“自动”而不是“打开”(“是”传统）。

@felixarntz公司

这就是我的观点。他们现在没有改变，因为公关包括额外的业务连续性处理。

这就是我错过的😄 — 我以为你是在问我们是否应该在这个公关中添加一些业务连续性处理，而不是我们是否应该删除已经实施的业务连续性管理。感谢您的澄清。

实际上，我认为我更喜欢您上面建议的更改来处理不支持的值，就像它们是无效的并使用默认逻辑对它们进行处理（这在功能上仍然会导致它们被自动加载，所以这并不是真正的BC）。添加doing_it_wrong（）您以前使用BC逻辑来鼓励开发人员将代码更新为支持的值。

[弗利克索斯90]

由于PR看起来很棒，并且有两个批准，我计划很快提交，以便在6.6版本之前进行大量测试。在此处标记此内容以获得潜在的其他反馈，但我们也可以进行一些小的更改作为后续操作。

[弗利克索斯90]

在57920:

选项，Meta API：对自动加载选项使用更合理的默认值，允许WordPress核心做出决定。

过多的自动加载选项是导致数据库响应缓慢的常见原因，有时是由非常大的单个自动加载选项引起的。由于在向数据库添加选项时不必提供自动加载值，因此它往往会被忽略，再加上默认值“是”和缺乏文档可能会导致上述问题。

此变更集以多种方式增强了选项自动加载行为：

• 更新函数文档以鼓励使用布尔值真的或假为选项显式提供自动加载值。
• 使用新的字符串值在和远离的对于存储在数据库中的显式提供的值对和不，自对不允许确定它是由开发人员故意设置还是仅作为默认设置。
• 有效地否决这些值对和不。它们仍然支持向后兼容性，但现在不鼓励使用。
• 使用无效的作为的新默认自动加载值添加选项（_O）。如果开发人员没有提供显式值，这将触发WordPress逻辑来确定要使用的自动加载值：
  • 如果WordPress确定该选项不应自动加载，则它将作为自动关闭作为这个变更集的一部分，为此引入的单一启发式是检查选项大小是否大于150k字节的阈值。此阈值可通过新的wp最大自动加载选项大小过滤器。
  • 如果WordPress确定该选项应自动加载，则该选项将作为自动接通。作为此变更集的一部分，没有引入用于做出此类决策的逻辑，而是引入了一个新筛选器wp_default_autoload_value（wp_default_autoload_value）可用于定义此类启发式，例如通过优化插件。
  • 如果WordPress无法确定是否自动加载选项，则会将其存储在数据库中汽车.
  • 这实际上意味着，任何没有开发人员提供显式自动加载值的选项都将以自动加载值存储汽车，除非选项的大小超过上述阈值。值为的选项汽车到目前为止，仍然是自动加载的，最重要的是向后兼容性。新功能wp_autoad_values_to_autoad（）返回指示自动加载选项的autolaod值列表和新筛选器wp_自动加载值_自动加载可用于更改该列表。

这些行为变化鼓励开发人员更加注意自动加载，同时为WordPress核心和优化插件提供了对自动加载选项启发式的额外控制，其中没有明确的自动加载值。

同时，从功能角度来看，这些更改完全向后兼容，唯一的例外是，如果开发人员没有明确要求自动加载非常大的选项，那么现在将不再自动加载这些选项。WordPress核心和插件都无法覆盖显式提供的值，这是为了继续让开发人员完全控制自己的选项。

道具pbearne、flixos90、乔麦吉尔、阿佐兹、spacedmonkey、瑞士口香糖、口香糖27、马克贾奎斯。
修复#42441.

在中提交https://core.trac.wordpress.org/changeset/57920

[乔麦吉尔]

在58105:

选项：更新核心中使用的默认自动加载值。

这将更新用于$自动加载参数，分别将“yes”和“no”替换为“on”和“off”。

后续行动[57920].

道具pbearne，mukes27，乔麦吉尔。
修复#61045。请参阅#42441.

[彼得威尔逊公司]

正在为重新打开42441-esc-sql.diff​为自动加载数据库查询添加一些防御性代码。

虽然现在是安全的，但如果API被修改为允许开发人员添加值，我们就不要相信我们未来的自己会抓住它。

Trac票：

降低时间的优先级wp_filter_default_autoload_value_via_options_size（）（工作过滤器默认值_自动加载值_变量_选项_大小）被新事物所吸引wp默认自动加载值筛选，以便第三方开发人员可以根据默认优先级筛选较大的选项大小值。

Trac票：https://core.trac.wordpress.org/ticket/42441

[乔麦吉尔]

@彼得威尔森立方厘米42441-esc-sql.diff对我来说，这是一个很好的建议。已将其转换为以前链接的，以便CI可以运行。：thumbsup：提交。

无关，我喜欢您在开发说明草稿中的建议，即我们应该将wp过滤器默认自动加载值通过选项大小过滤器打开wp默认自动加载值设置为较低的优先级，以便可以使用默认优先级覆盖它，因此我为该更改打开了一个额外的请购单。

[彼得威尔逊公司]

在58380:

选项、元API：添加SQL转义以查询加载“所有选项”。

转义的返回值wp_autoad_values_to_autoad（）用于加载“所有选项”的数据库查询。这是一个加固修复程序，用于防止将来对选项API进行更改，从而允许开发人员进一步自定义wp_自动加载值_自动加载过滤器。

后续行动[57920].

道具彼得威尔森，乔麦吉尔。
修复#42441.

坚信的58380兰特/​https://github.com/WordPress/WordPress-develop/commit/9955b87bcef14b69f66fe18ff336aa5fbba76f25

[彼得威尔逊公司]

在58381:

选项，Meta API：默认自动加载阈值过滤器的优先级较低。

降低优先级wp_filter_default_autoload_value_via_option_size（）注册为在上运行wp_default_autoload_value（）过滤器。默认过滤器现在以优先级5运行。

这是为了允许第三方开发人员修改是否使用默认优先级10自动加载选项，而不是要求他们注册代码以更高的优先级运行。

后续行动[57920].

道具彼得威尔森，乔麦吉尔。
修复#42441.

坚信的58381兰特/​https://github.com/WordPress/WordPress-develop/commit/48497199e15c024fadca0b7af93982335ae43f30

[乔麦吉尔]

在58416:

选项：修复核心中使用的一些默认自动加载值。

这修复了中更新的一些自动加载值[58105]使用数据库值的“打开”和“关闭”而不是布尔值真的和假当被传递给添加|更新选项（）.

道具乔麦吉尔、德斯罗什、拉金沙瓦尔。
修复#61045。请参阅#42441.

[赛博（Cybr）]

卸载大型选项可以节省多少时间？对于卸载的选项，额外的数据库请求需要多长时间？卸载的好处是否大于其他数据库请求的负面影响？

另外，为什么选择150kB？为什么不是200kB或50kB？