Woo-poly-integration: WooCommerce 3.6 问题

你好。 这是与您上面提到的内容相关的错误。

您能否在默认的 Wordpress 主题（例如 Storefront）上重现此问题？
是的

当除 WooCommerce、Polylang 和 Hyyan WooCommerce Polylang 集成之外的所有其他插件都被禁用时，您能否重现此问题？
是的

出现此问题时，您使用的是哪些产品版本和设置？
PHP：7.3.1
WordPress：5.1.1
WooCommerce：3.6.1
多语言：2.5.3
Hyyan WooCommerce Polylang 集成：1.3.0
浏览器：Chrome、火狐

重现步骤
使用至少 2 种语言设置 Polylang
以默认语言创建可变产品
创建产品的翻译

我所期望的
翻译的产品也是可变的。

相反发生了什么
当我点击添加产品的翻译时，该翻译的产品类型设置为简单。
产品类型不同步。

产品类型已确认 3.6.x 问题 - 我也可以重现此问题，并在https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/ 上报告

产品类型问题可能是由于添加到产品类型的缓存引起的https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
这意味着在 woopoly 更新产品类型的情况下，缓存不会失效，因此它显示为 Simple..

这是一个与新产品数据查找表不同但相似的问题：基本上所有更新现在都需要通过 woocommerce api 以确保缓存和查找表得到更新。
目前，该插件扩展了 Polylang 复制后期元和分类法的功能，对哪些元和分类法需要复制或翻译的必要了解最少。
现在应通过 WooCommerce api 本身处理预定义的 WooCommerce 项目。

我在处理 WooCommerce 代码方面没有太多经验，但是否有关于 WooCommerce 缓存的任何信息，以便我们可以尝试找到解决这些问题的方法？ 根据你的发现， Meta.php中的copyTerms()函数需要更新吗？

https://github.com/hyyan/woo-poly-integration/blob/1d83ef23e96f35c2bb008b5fa37e5157bfc388e4/src/Hyyan/WPI/Product/Meta.php#L341

理想情况下，所有更新都应使用 woocommerce Product 对象而不是 wordpress Post 对象，以确保任何 woocommerce 级别缓存和中间表（以及未来的 Product 表）始终保持一致。 这可能并不像听起来那么困难。

或者，也应该可以按原样更新并强制 woocommerce 重新缓存和重新计算相关对象，但通过 api 更新将更具前瞻性，我们都可以减少维护，减少未来 woocommerce 版本的问题.

有关更改的信息都在此线程的第一个链接中，以及从那时起的点版本的发行说明。 我通过查看链接到 github 修复程序的发行说明找到了上面的 woocommerce github 链接。

在非常旧的插件版本中，在Meta.php的syncProductsMeta()函数末尾调用了$this->syncSelectedproductType($ID); Meta.php 。 如果我重新添加这个，可变产品的新翻译会在产品类型下拉列表中选择正确的选项。

@mrleemon是的，修复了变体产品类型问题，做得好！

这有点像黑客工作——它实际上并没有纠正潜在的问题，而是使用了一些 javascript 来同步翻译的新产品表单和一些 woopoly 元数据，以便在保存产品时它可以正常工作。

一般的产品同步似乎也可以（需要更多测试），只有新的 wc_product_meta_lookup 表没有更新，我相信目前只影响排序。

所以，我们需要使用 WooCommerce CRUD 函数直接复制产品属性，而不是像现在一样依赖pll_copy_post_metas过滤器，对吗？

好吧，元本身似乎正在工作，只是存在可能被缓存的风险，例如这里是为变体属性添加的 woocommerce 缓存：

    public function read_variation_attributes( &$product ) {
        global $wpdb;

        $variation_attributes = array();
        $attributes           = $product->get_attributes();
        $child_ids            = $product->get_children();
        $cache_key            = WC_Cache_Helper::get_cache_prefix( 'product_' . $product->get_id() ) . 'product_variation_attributes_' . $product->get_id();
        $cache_group          = 'products';
        $cached_data          = wp_cache_get( $cache_key, $cache_group );

不知何故，我认为缓存正在被清除并且这是有效的，这可能是运气而不是设计。
仍然需要更新 wc_product_meta_lookup 表，这可以通过通过产品类更新特定字段来单独完成，但如果所有更新都通过 _relevant_ 产品类完成以避免重复的数据库调用，则效率会更高。 它可能需要是 _relevant_ 产品类，尽管不同的产品类型有不同的处理。

不知道下面的WC函数对新建翻译时复制产品数据是否有用：

https://docs.woocommerce.com/wc-apidocs/source-class-WC_Admin_Duplicate_Product.html#134

它使用woocommerce_duplicate_product_exclude_meta过滤器来排除被复制的元字段，并使用woocommerce_product_duplicate_before_save钩子在产品对象创建之前进一步修改它。

@mrleemon谢谢...我们不会像那样复制产品，但也许我们可以.....？

与此同时，我确实有另一个解决方案，我将检查。

@mrleemon我接受了你对 $this->syncSelectedproductType($ID) 的建议； 并添加了一个功能以确保清除翻译产品缓存并更新查找表。

这解决了迄今为止报告的所有 3.6 问题。
但这不是完整的代码审查......

@mrleemon谢谢...我们不会像那样复制产品，但也许我们可以.....？

是的我知道。 但是，考虑到 WC 团队计划在未来将所有产品元数据移出 wp_postmeta 表，从长远来看可能有必要考虑使用 WC 核心功能复制产品。

新产品帖子由 Polylang 创建为空白帖子，其中包含语言和链接翻译的分类数据以及选定的元数据，该插件以通用方式对其进行扩展，以处理元选项以及附加术语和分类法。

以通用方式复制术语和分类法实际上更好，因为它们（通常）适用于（或可以与过滤器一起使用）任何产品类型（包括我们不知道的产品类型）和任何插件向产品添加元数据或分类法（标准 woocommerce 对象不知道）。

WooCommerce 的长期目标似乎是从帖子表本身移动产品数据，但这会破坏每个扩展插件，这就是为什么他们提出这个查找表来减轻用于排序的主要数据字段的性能限制。

你好！ 这个bug修复了吗？ 最后的变更日志条目提到与 WC 3.6 的兼容性已得到修复，但此问题仍然存在。 什么状态？ 另外，是否可以更新由 WP (https://wordpress.org/plugins/woo-poly-integration/) 分发的插件？

顺便说一句，非常感谢您为所有相关人员维护这个插件！

这是 woo3.6 问题的一般主题，不涉及单个问题。 迄今为止报告的特定问题已从 github 上此插件的第一个 3.4 版本中修复。 源现在是 3.4.3，我将在重新检查一些点后在 github 上发布。

在 WordPress 完全发布之前，最好从早期采用者那里获得更多反馈：有太多不同的设置和使用场景，实际上不可能进行全面测试，尤其是在考虑其他插件时 - 我已经不得不在接受后恢复一个更改因为为了一个插件的利益而进行的兼容性更改破坏了其他插件的兼容性（命名您的价格与货币切换器）。

昨天，WooCommerce 在之前接受了我对 WooCommerce 3.6+ 的相关拉取请求后拒绝了它 - 考虑到他们不想让其他插件能够重新同步产品查找表 - 所以从长远来看，任何将产品视为产品的 wordpress 插件使用 WordPress API 发帖会有问题。 同时，迄今为止复制任何产品（包括具有我们不知道的数据的自定义产品类型）的产品数据的唯一可靠方法是复制所有存在的元数据和分类数据（根据设置和可过滤的课程）。
在 3.4 中添加的解决方法仍然有效，但我会在任何发布之前再看看它。

我仍然在 wp5.2.2 上的 Hyyan WooCommerce Polylang 集成版本 1.4.3 上遇到此错误

加载可变产品的编辑器会删除可变产品数据，即使重新保存可变产品数据也无效。

禁用和重新启用 Hyyan 不会改变此行为
最近对 Polylang 进行了更新
https://wordpress.org/plugins/polylang/#developers
2.6.2 (2019-07-16)
优点：在无法访问翻译更新服务器的情况下修复缓慢的管理员
优点：修复转发器中 ACF 克隆字段的值未正确转换的问题
修复通过 WPML 兼容性注册时混合的字符串翻译。 第381章

嗨， @Oclair请注意，即使使用最新的 Polylang 和 WooCommerce 更新，该修复程序仍然有效，因此，如果您遇到问题，请作为单独的 github 问题提出并提供完整的详细信息。

请注意，解决方法确实包括 javascript，因此除了检查服务器端错误之外，还值得使用 Chrome 开发人员工具检查并检查 javascript 控制台是否有任何错误。

另一个问题或其他插件可能会以某种方式影响这一点。

嘿，感谢您的响应和解决方案，而不是启用 javascript 的微不足道的警告！
如果这个 javascript 有问题，插件可能会通知管理员？ 因为如果他们只需要更新一些文本，大多数人不会检查产品变量......

再次感谢，祝您愉快！

嗨， @Oclair请注意，即使使用最新的 Polylang 和 WooCommerce 更新，该修复程序仍然有效，因此，如果您遇到问题，请作为单独的 github 问题提出并提供完整的详细信息。

请注意，解决方法确实包括 javascript，因此除了检查服务器端错误之外，还值得使用 Chrome 开发人员工具检查并检查 javascript 控制台是否有任何错误。

另一个问题或其他插件可能会以某种方式影响这一点。

如果这个 javascript 有问题，插件可能会通知管理员？
检测和采取行动可能是一个困难的情况：如果 javascript 问题是它永远不会执行，那么它就无法发出警报..

我实际上在几个版本之前删除了这个解决方法，因为我不喜欢它并且发现它没有必要。 不幸的是，WooCommerce 的更改再次使它成为必要，我找不到更好的选择。