Cela se produit parce que MetaBoxVisibility définit style.display à '' lors du montage:

https://github.com/WordPress/gutenberg/blob/69b55c70443762c1d302e982a5f91196ff0892f4/packages/edit-post/src/components/meta-boxes/meta-box-visibility.js#L8 -L10

Une solution simple serait de mettre à jour cela pour ne mettre à jour le DOM que si nous avons besoin de _hide_ la méta-boîte:

componentDidMount() {
    if ( ! this.props.isVisible ) {
        this.updateDOM();
    }
}

Cependant, l'utilisateur pourra toujours afficher à nouveau la méta-boîte en ouvrant _Options_ et en désactivant / activant la case à cocher de cette méta-boîte.

@elliotcondon : désinscrire la méta box en utilisant remove_meta_box() au lieu de la cacher avec CSS? De cette façon, la méta-boîte sera supprimée à la fois de l'éditeur et du modal _Options_.

@noisysocks Merci pour la réponse et les informations.

Je suis heureux de rechercher une solution alternative pour mettre à jour dynamiquement les métaboxes, cependant, il ne sera pas possible de déployer une mise à jour pour tous les utilisateurs avant la version WP5.0 de jeudi.

Est-il possible de "monter" les métaboxes sans supprimer leur style "affichage"?
Cela permettrait à Gutenberg d'hériter du code HTML de la métabox comme prévu.

Est-il possible de "monter" les métaboxes sans supprimer leur style "affichage"?

Oui, c'est essentiellement ce que ferait le changement que j'ai proposé ci-dessus. Cela ne fait qu'atténuer le bogue, cependant, puisque Gutenberg doit définir style.display sur '' ou 'none' afin que l'utilisateur puisse activer et désactiver les méta-boîtes via le modal _Options_.

Ça a du sens. Est-ce assez simple pour intégrer la version 5.0?

Je suis désolé de dire qu'il est trop tard dans le cycle de publication pour que cela soit corrigé pour la version 5.0 et que ce n'est pas un problème de blocage. Je l'ai ajouté au jalon 5.0.1 qui est ciblé pendant deux semaines après la sortie de 5.0 le 6 décembre.

Pour contourner ce problème, vous pouvez chercher à masquer l'élément en utilisant une approche qui ne modifie pas style.display , par exemple

- $('#test-metabox').hide();
+ $('#test-metabox').addClass( 'hidden' );

Ne réalisez-vous pas combien de millions de sites utilisent ACF et ACF Pro que cela va affecter? Ne pas résoudre ce problème avant la version 5.0 est ridicule et incroyablement décourageant de savoir que vous êtes simplement prêt à publier un code qui brise un plugin aussi populaire. Je parie que si ce problème affectait Jetpack ou un autre plugin Automattic, il serait corrigé en quelques minutes et ajouté comme par magie dans la version 5.0.

* C'est juste pour ACF uniquement

Je gère plus de 200 propriétaires de sites qui utilisent ACF et 31 autres utilisant ACF Pro. Ce cycle de publication a été parmi les plus décevants que j'ai rencontrés. Honteux de lancer ce problème pendant deux semaines, voire plus.

Je parie que si ce problème affectait Jetpack ou un autre plugin Automattic, il serait corrigé en quelques minutes et ajouté comme par magie dans la version 5.0.

Amen

Je suppose que l'activation de l'éditeur classique résout ce problème? Je ne sais pas combien de code Gutenberg est toujours inclus avec

@elliotcondon Est-ce une régression ou a-t-il fonctionné de cette façon depuis le

Il s'agit probablement d'une régression introduite il y a un mois par https://github.com/WordPress/gutenberg/pull/11084.

Restons sur le sujet. Ce n'est pas le lieu de discuter du processus de publication 5.0 qui est ce qu'il est.

Que signifie «approche super hacky» dans https://github.com/WordPress/gutenberg/pull/11084 ?

Ne serait-il pas préférable d'utiliser une "approche non hacky", puisque WordPress 5.0 "est prêt" maintenant? Ou n'est-ce pas?

@noisysocks avez-vous testé avec succès votre pull request par rapport à ACF avant la fusion comme @youknowriad recommandé?

Toutes mes excuses, j'ai fait passer mes fils là-bas. Cette régression a été introduite en 4.1 il y a six semaines par https://github.com/WordPress/gutenberg/pull/10676.

Salut à tous. Nous commençons à voir de nombreux tickets d'assistance concernant ce problème. Veuillez garder ce ticket GitHub à jour avec vos plans pour résoudre le problème.

12628 résout le problème et sera livré avec WordPress 5.0.1 dans environ 2 semaines.

Le masquage de la méta-boîte en utilisant $( '#test-metabox' ).addClass( 'hidden' ) ou wp.data.dispatch( 'core/edit-post' ).removeEditorPanel( 'meta-box-test-metabox' ) reste la solution de contournement préférée.

À l'avenir, nous recommandons que removeEditorPanel() ou remove_meta_box() soit utilisé pour de tels cas.

Il semble que nous devrons publier une mise à jour pour résoudre ce problème de notre côté.
Il est dommage qu'un si petit correctif n'ait pas pu être ajouté à WP 5.0 avant la sortie.
Cela affecte directement chaque utilisateur ACF qui passe à la version 5.0.

Il semble que nous devrons publier une mise à jour pour résoudre ce problème de notre côté.
Il est dommage qu'un si petit correctif n'ait pas pu être ajouté à WP 5.0 avant la sortie.
Cela affecte directement chaque utilisateur ACF qui passe à la version 5.0.

WordPress a vraiment foutu le chien avec Gutenberg. Ils disent écouter leurs utilisateurs, mais apparemment pas. Personne ne veut de cette monstruosité.

Merci beaucoup à @elliotcondon pour avoir

Oui, il est regrettable que ce bogue n'ait pas été découvert et corrigé à temps pour le gel du code 5.0.

_S'il vous plaît_ restons sur le sujet. GitHub est notre lieu de travail. Il est important que nous maintenions la conversation ici amicale et sur le sujet afin que les contributeurs existants puissent faire leur meilleur travail et que les nouveaux contributeurs soient les bienvenus dans le projet.

@noisysocks ... mes excuses. Je vais essayer de me mordre la langue. Mais vous devez savoir que ce que vous avez fait a eu un impact négatif sur des millions d'utilisateurs WP uniquement pour le mettre sur le développeur de ce plugin pour corriger votre erreur. Ce devrait être WP qui publie le correctif et non ACF.

Oui, il est regrettable que ce bogue n'ait pas été découvert et corrigé à temps pour le gel du code 5.0.

Peut-être que si cette version n'était pas si précipitée, elle aurait été trouvée. Peut-être que si Gutenberg ne rompait pas constamment la rétrocompatibilité, il n'aurait pas dû être trouvé en premier lieu.

Le nombre de fois qu'Elliot a fait fonctionner ACF correctement uniquement pour qu'il soit cassé des semaines plus tard par Gutenberg, est ridicule! Le fait que cela ait été publié, sachant que cela allait casser des millions de sites, est tout aussi ridicule.

Comme @noisysocks l'a mentionné, ce référentiel est l'endroit où nous travaillons: de la même manière que vous ne vous

Je comprends que c'est frustrant de se heurter à un bug, en particulier s'il affecte les sites que vous gérez en production. Cependant, ce n'est pas une excuse pour exprimer votre frustration dans un rapport de bogue, qui existe spécifiquement dans le but de corriger ce bogue.

12628 sera dans WordPress 5.0.1, qui sortira dans ~ 2 semaines. Si vous souhaitez vous assurer qu'il est complètement corrigé, je vous encourage à tester ce PR et voir s'il résout le problème pour vous, en particulier pour les configurations ACF plus complexes.

En attendant, j'ai caché les commentaires hors sujet dans ce fil. Veuillez poursuivre la discussion sur le sujet.

Toujours, avez ce problème après la mise à jour 5.0

Une chance?

@pento ... Tout comme Automattic pour censurer les commentaires des utilisateurs. Si vous n'aimez pas les commentaires, faites un meilleur travail en rassemblant vos affaires. Je pense que c'est hilarant que vous allez attendre 2 semaines pour corriger un bug majeur comme celui-ci. Il n'y a aucune chance que j'attende aussi longtemps. Heck, je n'aurais pas mis ce genre de déchets en premier lieu.