Distributor: La méta de poste n'est jamais réellement supprimée à la réception

Créé le 6 déc. 2018 · 3Commentaires · Source: 10up/distributor

Remarqué dans #258 / #259 :

set_meta() ne supprime jamais réellement aucune méta de publication. Cela semble avoir toujours été un problème, mais a été exacerbé par un bogue que nous avons introduit dans la version 1.3.4 qui dupliquait des méta-valeurs vides qui sont maintenant en quelque sorte bloquées en raison de la façon dont update_post_meta() fonctionne avec les valeurs précédentes.

Je ne sais pas encore quelle est la bonne chose à faire. Nous pourrions:

Soyez moins performant et effacez simplement tout ce qui n'est pas sur la liste noire avant d'ajouter à nouveau
Essayez de faire quelques astuces en découpant les méta-tableaux existants et en les comparant à la longueur des nouvelles données et en supprimant celles qui ne sont plus représentées. Le problème avec ceci est que pour ces situations où nous avons des valeurs dupliquées (je ne sais pas s'il y a jamais un moment où c'est une chose valable que les gens veulent faire ??), cela effacera toute la méta de poste avec cette même valeur quel que soit le nombre d'articles qu'il est censé y avoir. Ils seront probablement ajoutés, mais cela semble toujours être une routine étrange.
Quelque chose d'autre auquel je n'ai pas encore réussi à penser

Je suppose que la plus grande question pour commencer est la suivante : quel genre de situations y aurait-il où la publication distribuée aurait une méta que la publication d'origine n'avait pas et doit conserver ?

@tlovett1

bug meta needs discussion

Source

helen

Tous les 3 commentaires

Création d'un PR (https://github.com/10up/distributor/pull/419) où implémenté la fonctionnalité « delete meta ». Effectuer des vérifications lors de la post-redistribuer (dans la méthode SubscriptionsController::receive_item(..) ) en comparant les métadonnées de la demande précédente stockées (stockées dans la clé méta de post dt_subscription_update ) par rapport à la nouvelle et en supprimant la méta post qui existait dans la requête précédente mais n'existe pas dans l'actuel.

avag-novembit le 28 juin 2019

Nous avons discuté de ce problème avec @avag-novembit et j'aimerais ajouter mes réflexions, j'espère que cela donnera plus d'informations sur notre approche et expliquera les relations publiques envoyées par @avag-novembit.

La base est la suivante - C'est un must et il est sûr de supprimer une partie de la publication (dans ce cas, la méta de la publication), si elle a été ajoutée/modifiée par le distributeur. En d'autres termes, si vous supprimez une partie de la publication, qui a été générée par le distributeur, c'est OK et attendu, mais si nous supprimons les données non distribuées, générées d'une manière ou d'une autre directement dans la destination - ce n'est pas OK et inattendu.

Par exemple, nous pouvons avoir un plugin dans la source et la destination, et ce plugin peut ajouter/mettre à jour une méta sur certains événements, il peut également supprimer cette méta de tous les messages sur la désactivation, maintenant, quand nous désactiverons ce plugin dans la source et ensuite mettre à jour un message, le distributeur supprimera également cette méta dans la destination et cela peut générer des problèmes imprévisibles, mais ces problèmes sont attendus pour le mainteneur du site de destination, de la même manière que nous pourrions avoir des problèmes lorsque nous ajoutions des métadonnées à partir de la source.

La suppression sera inattendue pour le mainteneur si le Distributeur n'a jamais distribué ces données, mais tout à coup, il décidera de les supprimer. C'est pourquoi nous voulons nous assurer que la mise à jour la plus récente de la source a apporté ces données, que nous voulons supprimer maintenant.

Je ne sais pas si nous devons également comparer les méta-valeurs, en cas de méta-clés dupliquées, cela peut être très important, mais de l'autre côté, nous avons de nombreux filtres permettant au code tiers d'étendre et de modifier les méta-valeurs avant qu'elles ne soient inséré dans la base de données (par exemple, notre addon ACF mappera la méta-valeur, s'il contient un ID de pièce jointe), cependant, de mon point de vue, ces données sont toujours ajoutées par le distributeur et doivent être supprimées, donc, comparaison avec les méta-valeurs doit également tenir compte de ces modifications.

arsendovlatyan le 18 juil. 2019

👍1

Je déplace cela vers le jalon Future Release à considérer parallèlement à une approche large de la façon dont nous gérons la suppression/suppression des métas des sites distants. Toutes nos excuses pour le retard de réponse à celui-ci @arsendovlatyan , mais je veux être prudent avec la façon dont nous gérons la suppression des méta.