Woo-poly-integration: WooCommerce3.6の問題

こんにちは。 これがあなたが上で述べたことに関連したバグです。

この問題をデフォルトのWordpressテーマ（ストアフロントなど）で再現できますか？
はい

WooCommerce、Polylang、Hyyan WooCommerce Polylang Integrationを除く他のすべてのプラグインが無効になっている場合、この問題を再現できますか？
はい

この問題が発生したときに使用している製品バージョンと設定は何ですか？
PHP：7.3.1
WordPress：5.1.1
WooCommerce：3.6.1
ポリラン：2.5.3
Hyyan WooCommerce Polylang統合：1.3.0
ブラウザ：Chrome、Firefox

再現する手順
少なくとも2つの言語でPolylangを設定する
デフォルト言語で変数製品を作成する
製品の翻訳を作成する

私が期待したこと
翻訳された製品も可変です。

代わりに何が起こったのか
クリックして製品の翻訳を追加すると、その翻訳の製品タイプがSIMPLEに設定されます。
製品タイプが同期されていません。

製品タイプが確認されました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アイテムは、WooCommerceAPI自体を介して処理される必要があります。

私はWooCommerceコードを扱った経験があまりありませんが、WooCommerceのキャッシュに関する情報がどこかにあるので、これらの問題を修正する方法を見つけることができますか？ あなたの調査結果によると、ないcopyTerms()で関数をMeta.php更新する必要がありますか？

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

理想的には、すべての更新でワードプレスのPostオブジェクトではなくwoocommerce Productオブジェクトを使用して、woocommerceレベルのキャッシュと中間テーブル（および将来のProductテーブル）の一貫性を確保する必要があります。 これは思ったほど難しくはないかもしれません。

あるいは、そのまま更新してwoocommerceに関連オブジェクトの再キャッシュと再計算を強制することも可能ですが、APIを介した更新はより将来性があり、将来のwoocommerceリリースからのメンテナンスと問題が少なくて済みます。 。

変更に関する情報はすべて、このスレッドの最初のリンクにあり、それ以降のポイントバージョンのリリースノートにあります。 上記のwoocommercegithubリンクは、githubの修正にリンクされているリリースノートを調べて見つけました。

プラグインの本当に古いバージョンでは、への呼び出しがあった$this->syncSelectedproductType($ID);の終わりにsyncProductsMeta()での関数Meta.php 。 これを再度追加すると、可変製品の新しい翻訳で、製品タイプのドロップダウンから正しいオプションが選択されます。

バリエーションの製品タイプの問題を修正する@mrleemonうん、よくやった！

これはちょっとしたハック作業です-根本的な問題を実際に修正するのではなく、代わりに少しのjavascriptを使用して、翻訳された新しい製品フォームを少しのwoopoly metaと同期し、製品が保存されたときに正常に機能するようにします。

一般的な製品の同期も問題ないようです（さらにテストが必要です）。新しいwc_product_meta_lookupテーブルのみが更新されておらず、現在は並べ替えにのみ影響すると思います。

したがって、今のようにpll_copy_post_metasフィルターに依存するのではなく、WooCommerceCRUD関数を使用して製品プロパティを直接コピーする必要があります。

メタ自体は機能しているようですが、キャッシュされる可能性があるというリスクがあります。たとえば、バリエーション属性に追加された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テーブルを更新する必要があります。これは、productクラスを介して特定のフィールドを更新することで個別に実行できますが、すべての更新を_relevant_ productクラスを介して実行すると、データベース呼び出しが繰り返されないようにするため、より効率的です。 製品タイプが異なれば処理も異なるため、おそらく_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の長期的な目標は、postsテーブル自体から製品データを移動することであるように見えましたが、それによってすべての拡張プラグインが破損するため、並べ替えに使用されるメインデータフィールドのパフォーマンス制限を緩和するためにこのルックアップテーブルを考案しました。

やあ！ このバグは修正されましたか？ 最後の変更ログエントリには、WC 3.6との互換性が修正されたと記載されていますが、この問題は未解決のままです。 ステータスはどうなっていますか？ また、WP（https://wordpress.org/plugins/woo-poly-integration/）によって配布されたプラグインを更新することは可能ですか？

ところで、関係者全員にこのプラグインを維持してくれてありがとう！

これは、単一の問題に言及していないwoo3.6の問題の一般的なトピックです。 これまでに報告された特定の問題は、githubでのこのプラグインの最初の3.4リリースから修正されました。 ソースは3.4.3になりました。これは、さらにいくつかのポイントを再確認した後、githubでリリースします。

WordPressで完全にリリースされる前に、アーリーアダプターからより多くのフィードバックを得ることが常に望ましいです：非常に多くの異なる設定と使用シナリオがあるため、特に他のプラグインを考慮した場合、完全なテストは実際には不可能です-私はそれを受け入れた後、すでに1つの変更を元に戻す必要がありました1つのプラグインの利益のための互換性の変更により、他のプラグインの互換性が失われたためです（価格と通貨スイッチャーの名前を付けてください）。

昨日、WooCommerceは、以前に受け入れた後、WooCommerce 3.6+への関連するプルリクエストの1つを拒否しました-他のプラグインが製品ルックアップテーブルを再同期できるようにしたくないことを考慮して-したがって、長期的には、製品を製品として扱うワードプレスプラグインはWordPressAPIを使用した投稿には問題があります。 同時に、これまでのところ、任意の製品（不明なデータを持つカスタム製品タイプを含む）の製品データをコピーする唯一の信頼できる方法は、存在するすべてのメタデータと分類データをコピーすることです（設定に従って、コース）。
3.4で追加された回避策は引き続き機能しますが、リリース前にもう一度確認します。

wp5.2.2のHyyanWooCommerce PolylangIntegrationバージョン1.4.3でまだこのバグが発生しています。

可変製品のエディターをロードすると、可変製品データが削除されます。可変製品データを再保存しても効果はありません。

Hyyanを無効にしてから再度有効にしても、この動作は変わりませんでした。
最近、Polylangが更新されました
https://wordpress.org/plugins/polylang/#developers
2.6.2（2019-07-16）
プロ：翻訳更新サーバーに到達できない場合の遅い管理を修正
Pro：リピーターのACFクローンフィールドの値が正しく変換されない問題を修正
WPML互換性を介して登録されたときに混合された文字列の翻訳を修正しました。 ＃381

こんにちは、 @ Oclairは、最新のPolylangおよびWooCommerceのアップデートでも修正が機能していることに注意してください。問題が発生した場合は、詳細を記載した別のgithubの問題として提起してください。

回避策にはjavascriptが含まれているため、サーバー側のエラーをチェックするだけでなく、Chrome開発者ツールで調べてjavascriptコンソールにエラーがないかチェックする価値があることに注意してください。

別の問題または他のプラグインが何らかの形でこれに影響を与えている可能性があります。

javascriptを有効にする些細な警告ではなく、応答と解決策に感謝します！
このjavascriptに問題がある場合、プラグインが管理者に通知する可能性がありますか？ ほとんどの人は、一部のテキストを更新するだけでよい場合、製品変数をチェックしないためです。

もう一度ありがとう、素敵なものを持っています！

こんにちは、 @ Oclairは、最新のPolylangおよびWooCommerceのアップデートでも修正が機能していることに注意してください。問題が発生した場合は、詳細を記載した別のgithubの問題として提起してください。

回避策にはjavascriptが含まれているため、サーバー側のエラーをチェックするだけでなく、Chrome開発者ツールで調べてjavascriptコンソールにエラーがないかチェックする価値があることに注意してください。

別の問題または他のプラグインが何らかの形でこれに影響を与えている可能性があります。

このjavascriptに問題がある場合、プラグインが管理者に通知する可能性がありますか？
検出して対処するのは難しい状況かもしれません。javascriptの問題が実行されないことである場合、アラートを作成することはできません。

私は実際にこの回避策を数バージョン前に削除しました。これは気に入らず、必要ないことがわかったためです。 残念ながら、WooCommerceの変更により再び必要になり、より良い代替手段を見つけることができませんでした。