[RÉGLÉ] UP de lomart et recherche avancée

[Eddy.vh]

Bonjour.

Je viens de remarquer un petit problème que je ne vois pas comment résoudre.

Lorsque je lance une recherche sur mon site, les résultats s'affichent les uns sous les autres avec URL, titre de l'article et une partie de l'article contenant le terme recherché.
Si cette partie contient, dans l'article, un shortcode UP, il est affiché comme tel et n'est pas "traduit".

Y a-t-il possibilité de corriger cet affichage ?

Merci pour vos conseils.

[lomart]

Bonjour Eddy,

Tu mets le doigt sur un des soucis avec les shortcodes
Il faudrait faire une surcharge du résultat pour effacer tous les shortcodes. Cela me semble difficile car le shortcode peut être tronqué après x caractères. Et je ne parle pas des shortcodes imbriqués de UP qui ne peuvent pas être isolés par une simple regex
J'ai pris l'habitude de mettre les shortcodes de service comme addcsshead (incompréhensible pour un profane) en fin d'article.
Pour les autres, je me dis que les utilisateurs d'Internet ont l'habitude de voir des séquences HTML.
Le vrai danger est de révéler des informations présentes dans le shortcode PHP pour construire le HTML. Exemple le mot de passe pour file-download ou le contenu d'une action note

[woluweb]

Tiens, je croyais que la Recherche classique souffrait de ce problème (de ne pas "traduire" les shortcodes) mais que la Smart Search évitait justement ce problème.
Ce n'est pas le cas ??

Il y a deux dimensions à cette question:
1. est-ce qu'il cherche et trouve sur le rendu du shortcode
2. une autre question est ce qu'il affiche comme extrait sur la page de recherche)

[lomart]

Bonjour Marc,

Tiens, je croyais que la Recherche classique souffrait de ce problème (de ne pas "traduire" les shortcodes) mais que la Smart Search évitait justement ce problème.

Je le croyais aussi.

Voici la même recherche en J3 et J4

Je n'ai pas le shortcode sur J3, mais ce n'est pas toujours le cas.
Pour J4, j'ai le shortcode. Le premier est visible. C'est normal car il est dans une balise pre et codé pour ne pas être détecté. Le deuxième est celui qui est interprété par Joomla. Il ne devrait pas être visible. Il n'est pas non plus interprété. Je n'ai pas encore fouillé dans les paramètres du composant search

Pour info, voici le contenu affiché

[daneel]

Bonjour Eddy,

Tu mets le doigt sur un des soucis avec les shortcodes
Il faudrait faire une surcharge du résultat pour effacer tous les shortcodes. Cela me semble difficile car le shortcode peut être tronqué après x caractères. Et je ne parle pas des shortcodes imbriqués de UP qui ne peuvent pas être isolés par une simple regex

Bonjour Loïc,

On ne peut pas faire quelque chose comme ça ? C'est pas top mais c'est pour faire avancer l'idée (test sur https://regex101.com/ )



D'après les tests que j'avais fait à l'époque sous joomla 3, je pouvais retirer de la recherche en définissant la zone de recherche
puis en recréant la requête de recherche avec le contenu filtré par une regex... un peu trop complexe.

Mais dans la cas actuel avec la recherche avancée, je serai plutôt inspiré à copier la technique sur les custom field.
A savoir, de définir le contexte depuis l'évenement onContentPrepare
Si le contexte est com_finder.indexer alors le résultat de la balise sera vide sinon tu affichera le résultat tout simplement.
\plugins\content\fields\fields.php

[lomart]

Bonsoir Yann,

Merci pour tes tests.

Le problème ne doit pas concerner uniquement UP.

Un ensemble de shortcodes UP peut ressembler à ceci.
Sans parler du fait que l'on peut utiliser un autre mot que UP, mais je pense que personne n'utilise cette possibilité :

{up div=color:blue}
  {up osmap=48.865, 2.30}
    {marker=48.8709, 2.33223 | popup-text={up icon=plus} {up span=color:red}texte rouge{/up span} et bleu}
  {/up osmap}
{/up div}

N'utilisant pas les custom field, je les connais mal

En supprimant tous les contenus entre accolades des réponses, ce serait déjà bien.
Les 2 problèmes que je vois sont :
- une accolade justifiée (texte normal ou code dans un bloc pre)
- un texte retour tronqué

Un test de la regex \{(.*)(\})? sur le texte :

texte début
{up div=color:blue}
{up osmap=48.865, 2.30}
{marker=48.8709, 2.33223 | popup-text={up icon=plus} {up span=color:red}texte rouge{/up span} et bleu}
{/up osmap}
{/up div}
texte final
Essai avec contenu entre shortcodes
{up div=color:red}toto{/div}
Essai avec balise non fermée
{up div=color:red}
{up osmap=48.865, 2.30}
{marker=48.8709, 2.33223

voir https://regex101.com/r/quoJRY/1

[Eddy.vh]

Bonjour tous,

lomart : La regex \{(.*)(\})? ne peut fonctionner, la fin recherche une accolade fermante ou pas… c'est à dire… rien et elle sélectionne dont toute accolade ouvrante suivie de tout le texte qui suit, qu'il y ait une accolade fermante ou non et dans une recherche, il se peut que la balise fermante soit suivie d'autre texte.

La regex de Yann ne peut fonctionner parfaitement non plus, il existe des codes UP sans balise fermante ou des codes qui seraient en fin du texte des résultats de recherche et non affichés complètement.

Concernant les champs perso, s'ils apparaissent dans les résultats de recherche, ils sont bien "traduits" par le composant de recherche avancée.

[daneel]

Bonjour tous,

La regex de Yann ne peut fonctionner parfaitement non plus, il existe des codes UP sans balise fermante ou des codes qui seraient en fin du texte des résultats de recherche et non affichés complètement.

Effectivement, j'ai bien compris ! Cependant, on peut déjà réfléchir et tester en adaptant le code suivant... une idée ?

public function onContentPrepare($context, &$item, &$params, $page = 0)
{

if ($context === 'com_finder.indexer') {
// Don't run this plugin when the content is being indexed and we have no real context
return; }

} 

Logiquement on pourrait également exclure les flux rss.

[lomart]

lomart : La regex \{(.*)(\})? ne peut fonctionner, la fin recherche une accolade fermante ou pas… c'est à dire… rien et elle sélectionne dont toute accolade ouvrante suivie de tout le texte qui suit, qu'il y ait une accolade fermante ou non et dans une recherche, il se peut que la balise fermante soit suivie d'autre texte.

Elle fonctionne. Elle ne sélectionne pas jusqu'à la fin si une accolade fermante est trouvée. Voir les textes hors shortcodes dans https://regex101.com/r/quoJRY/1
Ses défauts sont :
- ne pas afficher le texte entre shortcodes (le contenu d'une action tab)
- ne rien retourner si le texte à afficher est uniquement des shortcodes

Bonjour daneel

Je n'ai pas compris où tu mets ce code.
C'est la recherche simple de J3 ou celle de J4 ?

[Eddy.vh]

Loic,

Oui parce que tu as des retours chariot. Dans les résultats de recherche, il n'y en a pas…

Ouvre ta régex https://regex101.com/r/quoJRY/1 et testes-y le texte suivant :

fichiers de langue française pour ContentBuilder {up file-download=fr-FR_ContentBuilder_gn_2020-07-30.zip | prefset = down} Merci à G. NEDELEC pour son fichier de traduction Pour installer ces fichiers de langue, dézippez le téléchargement sur votre...

Tu verras qu'elle sélectionne tout le texte (le point d'interrogation signifie "présent ou pas" en regex).
Enlève le point d'interrogation en fin de regex et elle sélectionne bien tout ce qui se trouve entre l'accolade ouvrante et la dernière fermante.

Mais peut-être que l'insertion de la regex dans un fichier de dev sera valide, là, je ne m'y connais pas assez…

[lomart]

Eddy.vh

Oui parce que tu as des retours chariot. Dans les résultats de recherche, il n'y en a pas…

Tu as raison. Mais rien n'empêche d'ajouter un saut de ligne (\n) après les } avant de tester la regex

Tu verras qu'elle sélectionne tout le texte (le point d'interrogation signifie "présent ou pas" en regex).
Enlève le point d'interrogation en fin de regex et elle sélectionne bien tout ce qui se trouve entre l'accolade ouvrante et la dernière fermante.

Je sais, mais le but est de capturer un shortcode ouvert et non fermé

[daneel]

com_search, c'est le composant de recherche simple, com_finder étant celui de la recherche avancée.
En pratique, mis à part les migrations, la recherche simple ne fait pas partie des sites J4 par défaut donc autant se concentrer sur com_finder.

Cette ligne se retrouve sur beaucoup de plugins utilisant les shortcodes afin que le plugin ne soit pas exécuté.
Elle se place dans la fonction onContentPrepare, evenement que tu gère dans le fichier up.php.

if ($context == 'com_finder.indexer') {
return false;
} 

Après je suis en train de chercher comment exclure de l'indexation. Dans la fonction onContentPrepare dans le fichier up.php, si on se place avant de déterminer si on est en front ou backend (l'indexation se déclenche en backend du composant) et en indiquant le contexte de l'indexation si $context === 'com_finder.indexer' alors le contenu de la recherche avancé est bien filtré des balises up en effectuant un str_ireplace.

Donc je ne suis pas loin, il ne manque plus que la bonne expression régulière...

[lomart]

Merci Yann,

C'est tellement évident que je n'y avais pas pensé

Le fait d'indexer ou non n'empêchera pas l'affichage du shortcode.

Sauf erreur, le texte à afficher est calculé en ligne 24 de components\com_finder\tmpl\search\default_result.p hp
Je ne vois pas d'appel aux plugins de contenu. On récupère le texte brut.
Il faudrait donc supprimer ou calculer les shortcodes à ce niveau

[Eddy.vh]

Je vous laisse faire, vous êtes bien plus calés que moi pour résoudre ce problème.
Passez un excellent weekend.

[daneel]

Sauf erreur, le texte à afficher est calculé en ligne 24 de components\com_finder\tmpl\search\default_result.p hp
Je ne vois pas d'appel aux plugins de contenu. On récupère le texte brut.
Il faudrait donc supprimer ou calculer les shortcodes à ce niveau

Apparemment l'évenement onpreparecontent est bien pris en compte dans le contenu avant indexation.
Donc si on modifie en remplaçant les shortcode par du vide uniquement dans le contexte com_finder.indexer, alors c'est ok.
Je ne vois plus le code UP quand j'essaye de rechercher un terme avant ou après la balise,
les balises en elle-même sont introuvables car absentes du contenu indexé. Je te confirme que cela fonctionne pour moi.

Il ne reste vraiment qu'à me plonger de nouveau dans les regex pour finaliser la solution.

Je vous laisse faire, vous êtes bien plus calés que moi pour résoudre ce problème.
Passez un excellent weekend.

Ce n'est pas mon fort les regex car je ne pratique pas tous les jours... si quelqu'un a une solution, on est preneur !