バグを説明する
Advanced Custom Fieldsプラグインで作成されたすべてのフィールドグループは、それらのフィールドグループの場所のルールに関係のない投稿を編集すると、空の表示メタボックスとして表示されます。
上の画像は、Hello World投稿を編集するときに、すべてのフィールドグループを空のメタボックスとして示しています。
バグを理解する
これは、グーテンベルクが初期化中にメタボックスの可視性を削除/変更したためです。 問題を再現するには、以下のサンプルコードを参照してください。
ここに問題の背景と、5.0がリリースされる前にこれを修正することが重要である理由があります...
ACFは、すべてのフィールドグループをメタボックスとして登録し、JSを使用して、ロケーションルールに基づいてそれらを非表示/表示します。 これにより、投稿属性(category、post_format、post_parentなど)が編集されているときにメタボックスを動的に更新できます。 このアプローチにより、ACFは、メタボックス内をドラッグするときに設定されたカスタムメタボックスの順序と位置の設定を尊重することができます。
Gutenbergをアクティブ化(またはWordPress 5.0 RC2)すると、すべてのメタボックスが表示されます。 グーテンベルク内の一部のJSコードは、メタボックスがカスタムJSによって既に非表示になっているかどうかを確認せずに、メタボックスの可視性を設定していると思います。
これを修正する必要がある理由
これを修正する必要がある理由はたくさんありますが、いくつかの理由であなたを引き継ぐようにします。
再現するには
問題を示すためのサンプルコードと添付ファイルを次に示します。
<?php
// Register a metabox.
add_action('add_meta_boxes', 'test_add_meta_boxes', 10, 2);
function test_add_meta_boxes( $post_type, $post ) {
add_meta_box( 'test-metabox', 'Test Metabox', 'test_render_meta_box', $post_type, 'normal', 'high' );
}
// Render metabox HTML.
function test_render_meta_box() {
?>
<script type="text/javascript">
(function($) {
$('#test-metabox').hide();
$('#test-metabox .inside').html('This should be hidden.');
})(jQuery);
</script>
<?php
}
?>
予想される行動
カスタムJSを介して非表示になっているメタボックスは非表示のままにする必要があります。
追加のコンテキスト
これは、 MetaBoxVisibility
がマウント時にstyle.display
を''
するために発生します。
簡単な修正の1つは、メタボックスを_非表示_にする必要がある場合にのみDOMを更新するようにこれを更新することです。
componentDidMount() {
if ( ! this.props.isVisible ) {
this.updateDOM();
}
}
ただし、ユーザーは_Options_を開き、そのメタボックスのチェックボックスをオフ/オンに切り替えることで、メタボックスを再度表示できます。
@elliotcondon :CSSで非表示にする代わりに、 remove_meta_box()
を使用してメタボックスの登録を解除できますか? このようにして、メタボックスはエディターと_Options_モーダルの両方から削除されます。
@noisysocks返信と情報をありがとう。
メタボックスを動的に更新するための代替ソリューションを検討できてうれしいですが、木曜日のWP5.0リリースより前にすべてのユーザーに更新を公開することはできません。
「表示」スタイルを削除せずにメタボックスを「マウント」することは可能ですか?
これにより、グーテンベルクは期待どおりにメタボックスHTMLを継承できます。
「表示」スタイルを削除せずにメタボックスを「マウント」することは可能ですか?
はい、これは基本的に私が上で提案した変更が行うことです。 ただし、Gutenbergはstyle.display
を''
または'none'
設定して、ユーザーが_Options_モーダルを介してメタボックスを有効または無効にできるようにする必要があるため、バグを軽減するだけです。
それは理にかなっている。 これは5.0リリースにプッシュするのに十分簡単ですか?
申し訳ありませんが、これを5.0で修正するにはリリースサイクルが遅すぎて、これはブロッキングの問題ではありません。 12月6日に5.0がリリースされてから2週間を目標とする5.0.1マイルストーンに追加しました。
回避策として、 style.display
変更しないアプローチを使用して、要素を非表示にすることを検討できます。
- $('#test-metabox').hide();
+ $('#test-metabox').addClass( 'hidden' );
何百万ものサイトがACFとACFProを使用していて、これが影響することに気づいていませんか? 5.0リリースの前にこれを修正しないことは、そのような人気のあるプラグインを壊すコードをリリースすることをいとわないことをばかげて信じられないほど失望させます。 この問題がJetpackまたは他のAutomatticプラグインに影響を与えた場合、数分で修正され、5.0リリースに魔法のように追加されると思います。
*これはACFのみの場合です
私は、ACFを活用する200人以上のサイト所有者と、ACFProを使用する別の31人を管理しています。 このリリースサイクルは、私が遭遇した中で最も残念なものの1つです。 この問題を2週間以上パントするのは恥ずべきことです。
この問題がJetpackまたは他のAutomatticプラグインに影響を与えた場合、数分で修正され、5.0リリースに魔法のように追加されると思います。
アーメン
クラシックエディタを有効にすると、この問題が修正されると思いますか? グーテンベルクのコードがまだどれだけ含まれているかわからない
@elliotcondonこれはリグレッションですか、それともずっとこのように機能していますか?
これは、 https://github.com/WordPress/gutenberg/pull/11084によって1か月前に導入されたリグレッションである可能性があり
話題にとどまりましょう。 これは、5.0リリースプロセスについて議論する場所ではありません。
https://github.com/WordPress/gutenberg/pull/11084の「スーパーハッキーアプローチ」とはどういう意味ですか?
WordPress 5.0は「準備ができている」ので、「ハッキーでないアプローチ」を使用する方が良いのではないでしょうか。 それともそうではありませんか?
@noisysocksは、 @ youknowriadが推奨するように、マージの前に事前にACFに対してプルリクエストを正常にテストしましたか?
申し訳ありませんが、ワイヤーを交差させました。 このリグレッションは、6週間前にhttps://github.com/WordPress/gutenberg/pull/10676によって4.1で導入されました
こんにちは、みんな。 この問題に関するサポートチケットがたくさん見られ始めています。 このGitHubチケットを、問題に対処するための計画で更新しておいてください。
$( '#test-metabox' ).addClass( 'hidden' )
またはwp.data.dispatch( 'core/edit-post' ).removeEditorPanel( 'meta-box-test-metabox' )
を使用してメタボックスを非表示にすることをお勧めします。
今後は、このような場合にremoveEditorPanel()
またはremove_meta_box()
を使用することをお勧めします。
これを修正するには、アップデートをリリースする必要があるようです。
このような小さな修正がリリース前にWP5.0に追加できなかったのは残念です。
これは、5.0に更新するすべてのACFユーザーに直接影響します。
これを修正するには、アップデートをリリースする必要があるようです。
このような小さな修正がリリース前にWP5.0に追加できなかったのは残念です。
これは、5.0に更新するすべてのACFユーザーに直接影響します。
WordPressは本当にグーテンベルクで犬を台無しにしました。 彼らは彼らが彼らのユーザーに耳を傾けると言います、しかし明らかにそうではありません。 誰もこの怪物を望んでいません。
WPのねじ込みを修正してくれた@elliotcondonに感謝します。
はい、5.0コードのフリーズに間に合うようにこのバグが発見され、修正されなかったことは残念です。
_お願い_話題にとどまりましょう。 GitHubは私たちの職場です。 既存の寄稿者が最善の仕事をすることができ、新しい寄稿者がプロジェクトに歓迎されるように、ここでの会話を友好的でトピックに保つことが重要です。
@noisysocks ...お詫びします。 舌を噛もうと思います。 しかし、あなたがしたことは何百万ものWPユーザーに悪影響を及ぼし、間違いを修正するためにそのプラグインの開発者にそれを置くだけであることを知っておく必要があります。 修正を出すのはWPであり、ACFではありません。
はい、5.0コードのフリーズに間に合うようにこのバグが発見され、修正されなかったことは残念です。
たぶん、このリリースがそれほど急いでいなかったら、それは見つけられたでしょう。 グーテンベルクが常に下位互換性を破っていなければ、そもそもそれを見つける必要はなかったでしょう。
エリオットが数週間後にグーテンベルクによって壊されただけでACFが正常に機能した回数は、ばかげています! これがリリースされたという事実は、それが何百万ものサイトを壊そうとしていたことを知っていて、同様にばかげています。
@noisysocksが述べたように、このリポジトリは私たちが働く場所です。誰かのオフィスに迷い込んで彼らや彼らの仕事を口にしないのと同じように、ここでそれを行うことも同様に受け入れられません。
特に本番環境で管理しているサイトに影響を与える場合、バグに遭遇するのはイライラすることを理解しています。 ただし、それはバグレポートでフラストレーションを解消する言い訳にはなりません。バグレポートは、特にそのバグを修正する目的で存在します。
その間、私はこのスレッドでトピック外のコメントを非表示にしました。 トピックについてさらに議論を続けてください。
それでも、5.0を更新した後にこの問題が発生します
運が良ければ?
@pento ...ユーザーのフィードバックを検閲するAutomatticのように。 コメントが気に入らない場合は、自分のものをまとめるより良い仕事をしてください。 このような大きなバグを修正するために2週間待つのは楽しいことだと思います。 そんなに長く待つなんてことはありません。 そもそもこういうゴミは出さなかったでしょう。
最も参考になるコメント
何百万ものサイトがACFとACFProを使用していて、これが影響することに気づいていませんか? 5.0リリースの前にこれを修正しないことは、そのような人気のあるプラグインを壊すコードをリリースすることをいとわないことをばかげて信じられないほど失望させます。 この問題がJetpackまたは他のAutomatticプラグインに影響を与えた場合、数分で修正され、5.0リリースに魔法のように追加されると思います。
*これはACFのみの場合です