[spip-dev] Correction bug debut_

Dev
1

Salut,

Dans la 1.3 b 4, nouvelle version de:
/inc-calcul-squel.php3

qui corrige le probl=E8me signal=E9 par Raphael, qui bloquait le
fonctionnement des "d=E9buts d=E9cal=E9s" dans les boucles
("{debut_articles,50}" par exemple).

Le probl=E8me venait du nouveau moteur: dans les squelettes
interm=E9diaires ("skel_..."), le $debut_articles =E9tait en r=E9alit=E9
remplac=E9 par sa valeur au moment du calcul du squelette
interm=E9diaire, et non plus en tant que variable PHP. La nouvelle
version devient un poil compliqu=E9e (pas tr=E8s jolie?):
- c'est bien le nom de la variable PHP qui est pass=E9e dans le
squelette interm=E9diaire;
- du coup, dans la fonction ainsi cr=E9=E9e
("squelette_rubrique_executer..."), il faut ajouter un "global" pour
cette nouvelle variable, d'o=F9 l'apparition d'un:
$result->variables_globales
qui reprend le principe utilis=E9 par ailleurs, mais dont je ne suis
pas particuli=E8rement fier;
- et comme il faut d=E9terminer si $debut_articles existe dans l'URL ou
non, en r=E9alit=E9 la requ=EAte ainsi cr=E9=E9e est un poil plus compliqu=
=E9e
que simplement =E9crire 'LIMIT $debut_articles,50', mais elle est
transform=E9e en un test PHP du type:
'LIMIT ".($debut_articles ? $debut_articles : "0").",50'

Tout cela ne me semble pas d'une grande limpidit=E9, mais je n'ai pas
trouv=E9 plus simple.

ARNO*

2

Salut,

Diverses modifs dans la beta4.

Le bug de l'inscription rédacteurs est corrigé. En fait ça
buggait uniquement en php3, à cause du fonctionnement différent
de include(). D'ailleurs, le bug existe probablement depuis
longtemps....

Pour y pallier, il y a maintenant un include_local() dans
inc_version, qui sert à inclure un fichier dans un contexte
de fonction, sans risquer de sortir de la fonction s'il y a
un return dans le fichier inclus (cas typique : if defined(...)
return). include_local() teste en même temps si le fichier
a déjà été inclus, c'est Nicolas qui va être content...
(malheureusement, cette fonction est compatible avec très
peu de fichiers inclus, à cause des variables globales ;
là c'est inc_connect qui posait problème).

J'ai également modifié inc_base.php3 pour les histoires de
forums effacés. Je ne sais pas si c'est bien ça, vu que
personne n'a répondu, mais ça en a tout l'air. J'ai également
modifié la 1.2 courante (faut refaire un .sit). Cependant,
si ça devrait éviter le problème à ceux qui ne l'ont pas encore,
pour ceux qui l'ont déjà il faudra faire une nouvelle version
spécialement.

Ce bug est a priori dû aux divers cafouillages dans les modifs
de la base de données effectuées entre la 1.0.6 et la 1.2.
Il y avait un id_message BIGINT qui s'est transformé en NOT NULL
un peu trop tard. Ceux chez qui le id_message est NULL par défaut
voient leurs forums systématiquement effacés par optimiser.php3,
à la ligne :

  $query = "DELETE FROM spip_forum WHERE id_message NOT IN (0,$messages)";

Si id_message est à zéro par défaut, l'effacement est évité (normal),
mais dans les versions foireuses de la base il est à NULL et passe
le test de la requête MySQL.

J'attends confirmation (?) de ceux de la liste SPIP....

J'ai modifié la correction du $debut_chose. Je n'ai rien pour tester,
donc je ne sais pas si ça marche, mais il y a des chances. Si quelqu'un
peut reprendre inc-calcul-squel....

a+

Antoine.

3

Sur linuxfrench nous avons le ID_MESSAGE à NULL par défaut (spip 1.2.1). Nous
n'avons pas constaté de pb pour l'instant.

Devons nous mettre à jour inc_base ?? Le tarball de spip 1.2.1 contient il le
nouveau inc_base ?

4

Herve LEFEBVRE wrote:

Sur linuxfrench nous avons le ID_MESSAGE à NULL par défaut (spip 1.2.1). Nous
n'avons pas constaté de pb pour l'instant.

Vous n'avez jamais utilisé la messagerie interne, si ?
(si la réponse est non, ne l'utilisez pas tout de suite ;-)).

Il n'y a pas encore de version intégrant la correction de la base
quand elle présente le bug (car on ne sait pas si le bug est
réellement à cet endroit). Tu peux directement lancer la requête
suivante :
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null

a+

Antoine.

5

Herve LEFEBVRE wrote:
> Sur linuxfrench nous avons le ID_MESSAGE à NULL par défaut (spip 1.2.1).
> Nous n'avons pas constaté de pb pour l'instant.

Vous n'avez jamais utilisé la messagerie interne, si ?

Oh que si !!

(si la réponse est non, ne l'utilisez pas tout de suite ;-)).

Il n'y a pas encore de version intégrant la correction de la base
quand elle présente le bug (car on ne sait pas si le bug est
réellement à cet endroit). Tu peux directement lancer la requête
suivante :
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null

Le temps de faire un backup, et j'alter ma table :slight_smile:

Merci

6

Herve LEFEBVRE wrote:

Oh que si !!

Marrant... j'ai vérifié chez moi, et le id_message est aussi à NULL
par défaut. Sauf que quand on cherche id_message NOT IN (0), les entrées
à NULL ne sont pas retournées. Apparemment ceux qui ont des problèmes
sont chez Altern, où la version de MySQL est plus ancienne (3.22.x) et
a probablement un comportement différent....

a+

Antoine.

7

Antoine Pitrou, le 1/11/01 0:17, a =E9crit=A0:

=20
J'attends confirmation (?) de ceux de la liste SPIP....

Ca a l'air stable, r=E9ponses =E0 l'article, nouvel article cr=E9=E9 avec r=E9ponse,
puis repass=E9 en =E9valuation, puis remis en ligne (la r=E9ponse est l=E0), puis
supprim=E9, pas de souc dans les autres forums...
Quand tout avait disparu, il ne me restait que le dernier message dans le
forum interne.
J'ai fait la m=E0j en 1.2 en automatique, mes anciens squelettes sont donc
rest=E9s en place. Je n'ai utilis=E9 que "sommaire.html"
C'est en ligne sur www.cyberpatrouille.com si qqn veut un pass d'admin...
Je bosse presque toute la journ=E9e n'h=E9sitez pas =E0 me demander des tests.
Merci =E0 toute l'=E9quipe.
JMi

8

Antoine Pitrou, le 1/11/01 0:17, a =E9crit=A0:

=20
J'attends confirmation (?) de ceux de la liste SPIP....

PS j'ai eu un message d'erreur en fin d'installation me disant qu'il y avai=
t
un probl=E8me sur une table MySQL avec un champ id_??? =E0 0
J'ai relanc=E9 linstal... plus rien
JM

9

Antoine Pitrou, le 1/11/01 1:01, a =E9crit=A0:

Apparemment ceux qui ont des probl=E8mes
sont chez Altern, o=F9 la version de MySQL est plus ancienne (3.22.x) et
a probablement un comportement diff=E9rent....

Exact en tout cas pour Chatignoux, Zablocki et moi
J'ose m=EAme pas imaginer aussi le bricolage php =E0 la sauce Valentin :wink:
JMi

10

Bonjour,

include_local() teste en même temps si le fichier a déjà été
inclus, c'est Nicolas qui va être content...

En effet, c'est un bon début !!! :slight_smile:

(malheureusement, cette fonction est compatible avec très peu de
fichiers inclus, à cause des variables globales ; là c'est
inc_connect qui posait problème).

On y viendra, on y viendra ... :wink:

-Nicolas