J’essaie de réduire le nombre de mots qui apparaissent dans « Discours » lorsque je publie un article dans WordPress. Mais au lieu de cela, je ne vois pas un seul mot ![]()
Utilisez-vous l’éditeur de blocs ou l’ancien éditeur classique pour publier l’article ?
Pouvez-vous partager un lien vers l’article ? Cela pourrait donner des indices sur ce qui ne va pas.
Que se passe-t-il si vous essayez d’ajouter manuellement un extrait à l’article :
Merci pour votre réponse. Nous utilisons toujours l’éditeur classique.
Cela nous arrive actuellement pour tous les articles, mais voici les liens :
- article source dans WordPress Fotky Google dostanou praktickou vychytávku. Oceníte ji?
- article cible dans Discourse Do aplikace Fotky Google se chystá praktická funkce. Usnadní procházení fotografií - Komentáře ke článkům - Komunita Svět Androida
Je ne sais pas si je comprends bien comment ajouter un extrait manuellement.
Nous n’avons pas utilisé « Extrait » pour les publications dans WordPress depuis quelques années maintenant, je ne l’ai pas bien compris tout de suite.
Mais il semble que lorsque je remplis « manuellement » dans WordPress, tout fonctionne bien.
Existe-t-il une solution pour que les X premiers mots soient envoyés à Discourse sans avoir à remplir manuellement « Extrait » ?
C’est logique. La logique utilisée pour créer l’extrait est différente lorsque l’extrait est créé manuellement et lorsqu’il est analysé par le plugin WP Discourse à partir du contenu de l’article.
Cela devrait fonctionner maintenant, mais il peut y avoir un conflit sur votre site entre le plugin Discourse et un autre plugin que vous avez installé. Une autre possibilité est que vous utilisiez des shortcodes dans l’article qui ne sont pas correctement analysés lorsque le plugin Discourse tente de créer l’extrait.
Utilisez-vous des shortcodes dans vos articles ?
Pour ma propre référence, le problème semble se situer ici : wp-discourse/lib/discourse-publish.php at main · discourse/wp-discourse · GitHub. Je suppose que quelque chose ne va pas avec l’appel à $excerpt = apply_filters( 'the_content', $raw );
Oui, nous utilisons des shortcodes. Je vais essayer de les désactiver temporairement et voir ce qui se passe. Merci pour les instructions. Je vous tiendrai au courant de ce que nous trouvons.
Si je désactive la plupart des plugins sur le site, tout semble fonctionner correctement. Merci pour les instructions. Je vais chercher le plugin problématique ![]()
Quelques heures plus tard :). J’ai déjà trouvé le coupable, le plugin Lnk.Bio – Plugin WordPressu | WordPress.org Česko fait-il le travail ? Des idées sur la façon de le réparer ?
Le plugin LnkBio a une fonction qui s’accroche à l’action 'wp_insert_post'. Cette fonction appelle unset($post->post_content) sur l’objet $post de WordPress. Théoriquement, cela ne devrait pas désactiver l’attribut post_content du post en dehors de la fonction LnkBio, mais lorsque je teste cela localement (en simulant les appels API du plugin LnkBio), l’appel à unset($post->post_content) désactive le contenu du post pour le plugin WP Discourse ici : wp-discourse/lib/discourse-publish.php at main · discourse/wp-discourse · GitHub.
Cela ne se produit que lorsque les posts sont publiés avec l’Éditeur Classique. Si les posts sont publiés avec l’Éditeur de Blocs, le contenu du post est disponible pour le plugin WP Discourse. Je suppose que c’est parce que les posts publiés avec l’Éditeur de Blocs sont publiés via une requête REST.
Notez que je rencontre le problème de contenu non publié sur Discourse, que je définisse une longueur d’extrait personnalisée ou que je sélectionne l’option WP Discourse “Utiliser le contenu complet du post”.
La solution la plus simple serait de passer à l’Éditeur de Blocs.
Une autre option serait de contacter LnkBio et de leur signaler le problème. Ils pourraient résoudre cela en trouvant un moyen plus sûr d’analyser le contenu du post pour leur requête API :
function lnkbio_api_sync($post_id, $post, $update) {
unset($post->post_content);
if ($post->post_status === 'publish') {
if (!get_option('lnkbio_id') || !get_option('lnkbio_secret')) {
return;
}
// url défini sur `example.com` pour tester sans compte lnkbio
wp_remote_post(
'http://example.com',
[
'blocking' => false,
'body' => [
'ACTION' => 'WP_sync',
'post_id' => $post_id,
'post' => json_encode($post),
'id' => get_option('lnkbio_id'),
'secret' => get_option('lnkbio_secret'),
'permalink' => get_permalink($post),
'is_pub' => true,
'image' => get_the_post_thumbnail_url($post_id, 'full'),
'group_id' => get_option('lnkbio_group'),
]
]
);
}
}
Modification : vous pourriez également simplement modifier le code du plugin LnkBio pour supprimer l’appel à unset($post->post_content); puis trouver un moyen de définir les valeurs appropriées pour l’objet $post qui est utilisé ici :
'post' => json_encode($post)
En général, modifier des plugins de cette manière est une mauvaise idée, mais cela fonctionnerait si vous êtes très prudent. Faites probablement cela uniquement si vous avez un moyen de tester vos modifications sur un site non productif.
Salut,
Ceci est le mainteneur du plugin Lnk.Bio pour Wordpress.
La fonction lnkbio_api_sync utilise uniquement la fonction unset sur la variable locale $post et cela ne devrait affecter aucun code en dehors de la fonction.
La variable $post n’est pas non plus passée par référence, donc elle est définitivement locale à cette fonction, sinon cela aurait un impact sur le post/extrait partout dans le code de WP.
Tout changement que nous apportons à $post est local à cette fonction uniquement, à moins que le code Discourse n’utilise d’une manière ou d’une autre des variables globales ?
Avez-vous une installation Discourse sandbox pour laquelle vous pouvez partager les identifiants API afin que nous puissions tester le plugin Discourse localement et voir comment il interagit avec notre code ?
Merci d’avance.
Oui, c’est ce que je pensais.
Le plugin WP Discourse utilise global $post à trois endroits :
Je ne suis pas sûr que cela puisse avoir un impact sur ce qui se passe. Je ne vois pas non plus de bonne façon d’éviter l’utilisation de global $post dans ces fichiers.
Ceci est intéressant : Global Variables « WordPress Codex
Il est conseillé aux développeurs de considérer ceci comme une liste de noms réservés et de ne pas créer de variables locales portant le même nom dans les plugins ou les thèmes. Dans certaines circonstances, la valeur de la variable globale sera remplacée par la valeur de la variable locale, provoquant des erreurs dans le cœur de WordPress difficiles à diagnostiquer.
Je pense que nous avons peut-être trouvé un cas extrême.
Non. Je fournis juste un support gratuit ici. Je sais que vous pouvez vous inscrire pour un essai gratuit sur Discourse pricing | Discourse - Civilized Discussion. Choisissez le plan Standard ou Business. Il ne faut que quelques minutes pour mettre en place un site.
Merci, j’apprécie le retour d’information.
Nous nous sommes inscrits à l’essai comme vous l’avez suggéré et avons pu reproduire le problème.
Nous avons découvert que même renommer $post en $local_post ou similaire ne résout pas le problème. La seule solution de contournement que nous avons trouvée est de json_encode puis json_decode le contenu, afin de créer un objet complètement séparé. Très laid.
Néanmoins, nous avons publié une mise à jour pour résoudre cette incompatibilité, même si la conception précédente était 100% correcte d’un point de vue code.
Voici le patch qui a déjà été publié
- unset($post->post_content);
+ $json = json_encode($post);
+ $local_post = json_decode($json);
+ unset($local_post->post_content);
if ($post->post_status === 'publish') {
if (!get_option('lnkbio_id') || !get_option('lnkbio_secret')) {
return;
@@ -138,7 +140,7 @@ function lnkbio_api_sync($post_id, $post, $update) {
'body' => [
'ACTION' => 'WP_sync',
'post_id' => $post_id,
- 'post' => json_encode($post),
+ 'post' => json_encode($local_post),
'id' => get_option('lnkbio_id'),
'secret' => get_option('lnkbio_secret'),
'permalink' => get_permalink($post),
Merci d’avoir fait cela !
Elle me semblait correcte. J’ai été surpris par ce qui se passait. Je suis désolé si j’ai semblé un peu dur dans mon premier message concernant le problème. J’y réfléchissais depuis quelques heures.
Vous n’avez pas été du tout dur, vous avez eu d’excellentes idées.
Après y avoir travaillé un peu plus, nous avons trouvé une solution meilleure et plus élégante en utilisant la fonction clone.
Ceci a déjà été publié dans le plugin Lnk.Bio mis à jour et le correctif est simplement
diff --git a/lnk.bio.php b/lnk.bio.php
index 65759fc..cc0c0d2 100644
--- a/lnk.bio.php
+++ b/lnk.bio.php
@@ -126,8 +126,7 @@ function lnkbio_api_post(string $url, array $data) {
}
function lnkbio_api_sync($post_id, $post, $update) {
- $json = json_encode($post);
- $local_post = json_decode($json);
+ $local_post = clone($post);
unset($local_post->post_content);
if ($post->post_status === 'publish') {
if (!get_option('lnkbio_id') || !get_option('lnkbio_secret')) {
Merci à tous les deux, vous avez toute mon admiration et mon respect pour la rapidité avec laquelle vous avez pu détecter et résoudre le problème. Prévoyez-vous d’intégrer officiellement cette amélioration dans la mise à jour du plugin Link.Bio ? Si oui, quand approximativement ?
Il semble que la mise à jour du plugin Lnk.Bio soit déjà terminée et fonctionne correctement (j’étais un peu confus que la version du plugin n’ait pas changé). Merci.



