Je viens de créer un article très récemment. C’est l’article n°28 ! Seul hic, je n’en ai que 6 sur ce nouveau site ! Normalement ça aurait dû être le n°7 soit un trou d’une vingtaine d’articles... Sans justification !

Toujours pas d’idées...

p.s. : 1°) Pour voir ce phénomène, voici la page de sommaire... sur Textothèque - Preavis.net. 2°) je sens que je vais tout refaire et revenir à SPIP 1.9.2d !

Merci par avance. @ +

tu as regardé ce qu’il y a dans la table spip_articles (via phpmyadmin) ?

J’ai fait une petite comparaison (entre deux sites SPIP tournant avec la version 1.9.3 dev [11226]), il y a le fameux site défectueux qui s’appelle Textothèque - Preavis.net et un site qui marche très bien celui du Mouvement Critique du Sport. Tout semble normal et le plus paradoxal c’est que sur le site défectueux à la page d’accueil générale de la base de données il mentionne le bon total (7 articles) et c’est la même chose en ce qui concerne l’index du bas à la page spip_articles ! Toutes les infos sont correctes...

Très mystérieux tout ça.

Alors je continue mon enquête mystérieuse... Lors de ma première intervention (cf tout en haut de ce forum), j’évoquais un autre site Solidal qui avait un problème similaire avec un passage brutal du 38e auteur à 1000e auteur sans raison apparente. Quand je me rends dans l’espace privé de ce site (qui est uniquement défectueux au niveau des chiffres des auteurs), il affiche bel et bien 44 auteurs et 3 administrateurs. Ce qui est le bon chiffre ! On refait une promenade sur la liste des auteurs et on peut tomber sur l’auteur 1001 etc.

Je donne cet indice si ça peut vous aider à mieux identifier le problème.
Merci par avance.

p.s. : J’ai trouvé une technique qui camoufle le problème au niveau de l’espace public du site, ça ne casse pas des briques ! J’utilise désormais l’URL Propres 2 ($type_urls = "propres2" ;) du fameux fichier mes_options.php ! Voir une belle liste avec une bonne quarantaine d’auteurs et se retrouver avec des chiffres qui culminent à 1000 et des poussières, ça fait très absurde ! @ +

Sur le site Solidal évoqué tout en haut on passe bien de l’auteur n°38 à l’auteur 1000 et des poussières ET NON 100 comme je l’ai évoqué dans ma toute première intervention...

Merci. @ +

tout de suite après avoir créé un nouvel article (dont l’id devrait donc disjoncter) regarde dans tmp/spip.log : y a t’il quelque chose qui ressemble à

 ?

Bine joué encore DenisB ! Effectivement, il y a bel et bien un fichier qui s’appelle vieilles_defs.log ! Son contenu confirme bel et bien des choses très intéressantes. Il y a fait énormément de choses, eh beh ! La date est celle du 3 novembre, ça confirme des indices évoqués par un autre utilisateur de spip (du milieu associatif) qui avait testé des plugins en version non stable qui touchait à des choses un peu sensibles.

Pour être précis il y a deux fichiers : vieilles_defs.log + vieilles_defs.log.1 ! Toutes ces fichiers de log sont disponibles à cette adresse : http://www.preavis.net/spip-bugs/ Tu pourras les télécharger et les analyser si Tu le souhaites.

J’ai testé Open-Publishing d’Indymedia Lille sur le site Solidal, mes souvenirs sont précis maintenant. Vu qu’aucun test n’était possible sur EasyPhp (avec Spip local quoi...) de ce fameux plugin non stable et constatant que ça ne marchait pas sur le premier site, j’ai effectué un second test sur le site de la Textothèque - Preavis.net ! Mais sur le site cobaye, au lieu de générer une erreur de type ’rajout d’auteurs’, il a généré un bug au niveau des chiffres d’articles très récemment.

J’essaie de deviner la consigne : “j’efface ces deux fichiers et tout rentre dans l’ordre !”

Cordialement.

L’utilisateur de spip qui évoquait un problème similaire. C’est disponible à l’URL : http://thread.gmane.org/gmane.comp.web.spip.user/125536/focus=125551

@ +

les fichiers .log (et .log.1, .log.2 etc) ne sont que des fichiers de log (des fichiers texte qui conservent certaines informations parfois utiles au debuggage). ils ne sont pas utilisés par les fonctions de spip. tu peux les laisser où ils sont.

je te demandais de regarder dans spip.log : c’est plutôt celui-là qui peut contenir des infos intéressantes...

Je n’ai rien de tel dans le fichier spip.log malheureusement.

spip_insert_id() ....... vieilles_defs

Non rien de tel...

euh, dis moi, tu ne fonctionnerais pas en multibase par hasard ?
avec une seule base de données pour plusieurs spip installés ?

Non, non pas du tout... Un site SPIP = 1 base de données (avec nom bien explicite pour bien s’y retrouver en général le nom du répertoire) !

Je reste persuadé que ça doit être lié au plugin non stable d’Indymedia Lille (qui s’appelle Open-Publishing). Jette un coup d’oeil à ce passage sur la page du collectif

La table spip-op-config

Elle contient toutes les options de configuration du plugin Open-Publishing.

L’auteur anonymous

pour les sites ayant déjà un auteur anonymous (site sur spipindy par exemple

ATTENTION !!!!! POUR LA TABLE SPIP_AUTEURS, il faut modifier les numéros d’auteurs pour remplacer 2 par 999 !!!!!!!!!!!!!!!!!!!!!!!! UPDATE `spip_auteurs_articles` SET `id_auteur` = 999 WHERE `id_auteur` = 2 ; ne pas oublié id_real_auteur de la table spip_article

La messe est dite je crois. Le plugin rajoute 999 auteurs sur la base de données du site SPIP ce qui coïncide parfaitement avec le problème indiqué. Et je n’ai pas le souvenir d’avoir réalisé le correctif de la manipulation conseillé... en partie parce que je maîtrise mal MySQL donc j’évite d’y toucher tout simplement.

C’est peut-être aussi dû à une mauvaise désinstallation de ma part (version barbare à savoir oubli de désactivation dans l’espace privé du plugin et suppression du plugin en ftp). Une maladresse nocturne arrive très vite...

Cordialement. @ +

p.s. : ça n’a pas l’air si grave je pense ? Si ce plugin a pu être capable de rajouter un trou 999 auteurs, il doit être possible de supprimer ce trou de 999 auteurs... Non ?

de qui de quoi on parle ?

 textotheque : spip 1.9.2d svn 11132
les id des articles s’incrémentent sans queue ni tête
 solidal : spip 1.9.3 svn 11312
les id des auteurs sont brusquement passés à 1000

pour solidal, effectivement l’épisode du plugin open publishing a manifestement mit le bazar.
il faudrait regarder si des tables spip-op-... existent encore, s’il ne traine pas options.php, supprimer les
tmp/charger_pipelines.php
tmp/charger_plugins_fonctions.php
tmp/charger_plugins_options.php
tmp/meta_cache.txt
tmp/plugin_xml.cache
tmp/verifier_plugins.txt

pour textotheque, ce peut être le même problème, mais j’en doute un peu (il n’y a pas de logique dans la numérotation des articles) et, pour le coup, je soupçonne une variable $id_article mal initialisée.
si tu désactives le plugin spip_format (qui est le seul plugin à intervenir dans le flux au moment de la création de l’article), est-ce que ça hennit toujours ?

Pour le site de textothèque, ce problème a disparu car j’ai résinstallé SPIP 1.9.2d. ! Il est apparu initialement quand le site était encore sous SPIP 1.9.3dev. Une chose de résolue donc...

Pour le site de Solidal, j’ai effectué les consignes, effacement de certains fichiers dans /tmp/... etc. + scruter une éventuelle spip_op (elle n’y est pas apparamment).
Rien ne fonctionne.

Merci.
@ +

Rien ne fonctionne.

c’est à dire que les id des nouveaux auteurs s’incrémentent bien de 1 en 1 mais à partir du plus élevé précédemment ?
ça, c’est le comportement normal : à la création, spip prend le plus haut des id et ajoute 1.

si tu veux éliminer les trous, il va te falloir faire un dump en xml non compressé, corriger ce fichier à la main pour modifier les entrées des tables
spip_auteurs
spip_messages
spip_forum
spip_auteurs_articles
spip_auteurs_rubriques
spip_auteurs_messages

puis réinjecter ta sauvegarde modifiée

ou alors t’écrire un petit php qui va bien et qui fait automatiquement le update des champs id_auteur :
si tu as un trou de 29 inclu à 999 inclu (ça passe de 28 à 1000) :

mais à tenter après avoir fait une sauvegarde !

J’ai utilisé la première méthode et ça a super bien fonctionné. J’ai dû modifier les entrées spip_auteurs + spip_auteurs_articles afin de bien faire coïncider l’article et le bon auteur ! Et voilà... ça a très bien marché.

Je n’ai pas utilisé la seconde méthode par crainte de mauvaise manipulation de MySQL.

Merci beaucoup.