SPIP

Un solution simple:

Le spip_loader pourrait bouger les dossiers du core dans un dossier backup_core avant de lancer la mise à jour.

Je confirme et reproduis le bug

Il vaudrait mieux éliminer le bug dans SPIP ! Comment se fait-il qu'on charge un fichier qui n'est plus censé exister ?

il y a deux problèmes en effet. La question de fil est sans doute la plus importante, mais avoir un SPIP propre apres spip_loader est toujours utile.

En effet, je me suis fait avoir avec un plugin qui, chez moi, chargeait "jquery.ui.datepicker" sans broncher en 3.1 alors que c'est la nomenclature de la 3.0.
Ça ne fonctionnait pas chez un utilisateur avec une version fraiche de SPIP 3.1.
J'ai supprimé tous mes .js en trop pour me remettre dans de bonnes conditions de dev.

Autre idée : déplacer dans backup_core uniquement les vieux fichiers (en se basant sur leurs dates...)

Julien - a écrit :

Autre idée : déplacer dans backup_core uniquement les vieux fichiers (en se basant sur leurs dates...)

Non, la date n'est pas une donnée fiable.
Elle est modifiée/modifiable par le système dès qu'une opération est faite sur le fichier. De plus, il me semble qu'en fonction du système d'exploitation, les règles de changement de date des fichiers ne sont pas les mêmes.

C'est donc le fichier ecrire/req/pg.php qu'il faut supprimer.

Comment se fait-il qu'on charge un fichier qui n'est plus censé exister ?

Le fichier n'est plus censé exister à condition que la mise à jour ait été effectué en suivant la procédure de la doc, cf :

http://www.spip.net/fr_article5693.html

On a déjà eu des bugs du style entre la branche 2 et la 3, à cause de la balise formulaire_recherche par exemple, cf le fichier source:branches/spip-2.1/ecrire/balise/formulaire_recherche.php qui a disparu en 3.0.

DokuWiki a une procédure détaillée pour traiter le problème des fichiers obsolètes :
https://www.dokuwiki.org/install:unused_files

Il gère donc un listing des fichiers obsolètes et proposent différentes façons de l'exploiter.