[spip-dev] Problème d'une recherche lorsqu'il existe plusieurs boucle sur le même type d'objet

Dev
1

Bonjour,

Après quelques heures de recherche, je n’ai pas de solution au problème suivant :

Soit 3 boucles de recherche consécutives sur un spip 3.2 :

<BOUCLE_pre1(ARTICLES){recherche}>#TITRE</BOUCLE_pre1>
<BOUCLE_pre2(RUBRIQUES){recherche}> #TITRE</BOUCLE_pre2>
<BOUCLE_pre3(ARTICLES){recherche}>#TITRE</BOUCLE_pre3>

La boucle “pre3” ne donne jamais de résultats sauf si :

  • Je déplace la boucle pre2 pour la positionner avant pre1 ou après pre3
  • Je modifie manuellement ma base de donnée pour mettre le champ spip_resultats > maj à “NULL” en une valeur par défaut (au lieu de current_timestamp() )

J’ai donc 2 questions :

  • La valeur par défaut du champ spip_resultats > maj doit-elle être réglée en current_timestamp() ?
  • Quelqu’un peut-il m’éclairer sur ce bug ?

Le plugin Fulltext ne change rien au schmilblick.

Cordialement,

2

Il va falloir que tu donnes plus d’infos : version exacte de SPIP, de PHP, quelle type de base ?…

Là comme ça je reproduis pas ni en SPIP 3.3dev ni en SPIP 3.2
Qui plus est si tu dis que tu as la même chose avec et sans plugin fulltexte ça me parait bien louche...

3

Alors je ne sais pas sur Fulltext, mais l'autre jour je signalais un truc à peu près à tcharlss en m'échinant pendant des heures à comprendre pourquoi ça sortait rien, et il ne reproduisait pas, et sur le site de dev en ligne non plus, ça marchait. Mais en local sur mon instance, dès qu'il y avait deux fois la même recherche, pour le même objet, alors ça ne sortait rien !

En local je suis en SQlite alors qu'en ligne c'est en MySQL.

C'est même pas dans le même squelette mais dans la même page : dans le racine je fais diverses boucles de recherche (une articles, une rubriques, une événements) pour avoir le total à mettre dans des onglets, et ensuite dessous j'appelle des INCLURE avec l'une des listes (soit les articles, soit les rubriques…). Et donc pour un même objet, mettons les articles, il y a deux mêmes boucles de recherche, une pour le total, puis une dans l'INCLURE pour la vraie liste.

Et bien pareil que décrit là, ça ne retourne rien pour la deuxième, alors que la première affiche le bon total, donc sort bien tous les résultats !

J'aimerais bien comprendre pour reproduire aussi puisqu'en ligne tout fonctionne…

4

Ah ben je reproduis le phénomène sur 2 sites où j'ai testé... comme s'il y avait {doublons} sur les boucles 1 et 3

Il va falloir que tu donnes plus d’infos : version exacte de SPIP, de PHP, quelle type de base ?…

SPIP 3.3.0-dev [24422]
PHP Version 7.2.26
MYSQL 5.7.23-23-log Percona

Composed-By: SPIP 3.3.0-dev @ www.spip.net + spip(3.3.0-dev),aide(1.1.0),archiviste(0.3.0),compagnon(1.7.0),dump(1.9.3),images(2.2.1),forum(1.13.0),jqueryui(1.12.1),mediabox(1.2.0),mots(2.11.1),organiseur(1.3.5),petitions(1.7.1),plan(2.3.1),porte_plume(1.20.0),revisions(1.10.3),safehtml(1.6.1),sites(2.0.2),squelettes_par_rubrique(1.3.0),stats(1.3.3),urls(2.3.2),vertebres(1.4.0),notation(2.4.5),memoization(2.1.9),accelerer_jobs(0.2.2),rechremp(1.4.0),macrosession(0.13.0),xray(0.25.0),declarerparent(1.3.5),switchcase(0.4.0),nospam(2.1.6),creer_sprites(2.1.2),crayons(2.0.9),alerte_urgence(2.2.0),facteur(3.7.2),iterateurs(1.0.6),queue(0.6.8),jquery(3.4.1),minidoc(1.0.3),ordoc(1.1.2),mejs(4.2.7),breves(1.5.2),compresseur(1.14.1),medias(2.25.3),svp(2.0.10),yaml(2.0.11),centre_image(0.10.7),verifier(1.9.6),saisies(4.0.0),duplicator(2.0.8),bigup(1.0.2),tw(1.6.5),htmlpurifier(5.0.0.5)

Avec var_mode=debug je vois que le code MYSQL généré est exactement le même pour pre_1 et pre_3, de même que les codes php générés (à part le préfixe du nom de la fonction, qui dépend du nom de la boucle).

JL

5

Ah en effet je reproduis en sqlite.
J’ai essayé PHP 7.2.x vs PHP 7.1.x et ça ne change rien : ça marche en mysql mais ça pouiche en sqlite.

Je me mets sur la piste du dahu

6

C’est donc corrigé sur dev
https://git.spip.net/spip/spip/commit/0880b517b0dd3464e5feb85bd6fbb392c3181f88
et reporté en 3.2

Le problème provenait d’un décalage entre la date php et la date sql, et pouvait donc se produire aussi bien en mysql qu’en sqlite
En principe le fix n’introduit pas d’autres bugs :stuck_out_tongue:

7

Je confirme que ça corrige bien chez moi, merci !