SPIP - Contrib

SPIP - Contrib

[ar] [en] [es] [fr] [it]

152 visiteurs en ce moment

fontsizeup fontsizedown
Accueil du site > Contribs > Administration > Suivre les versions de SPIP > Rétrograder de SPIP 1.9.3 SVN vers SPIp 1.9.2c
[30 commentaires]

Rétrograder de SPIP 1.9.3 SVN vers SPIp 1.9.2c

samedi 13 octobre 2007, par Cedric Morin

  • Digg
  • Del.icio.us
  • Facebook
  • Google
  • Technorati
0 vote

Le script magique pour se sortir du pétrin

Nota SPIP-Contrib : bien prendre en compte les avertissements de l’auteur... vous aurez été prévenus.

Si vous aussi vous vous mordez les doigts d’avoir passé votre site en ligne en version de développement 1.9.3 SVN, alors voici le script magique pour revenir en arrière et respirer !

Le script

  1. <?php
  2.         include_spip('base/serial');
  3.         include_spip('base/auxiliaires');
  4.         spip_query("UPDATE spip_documents SET fichier=concat('IMG/',fichier) WHERE fichier NOT REGEXP '(^IMG/|://)' ");
  5.         spip_query("DROP TABLE spip_types_document");
  6.         include_spip('base/create');
  7.         creer_base();
  8.         spip_query("ALTER spip_documents ADD id_type bigint(21) DEFAULT '0' NOT NULL");
  9.         $res = spip_query("SELECT id_type,extension FROM spip_types_documents");
  10.         while ($row = spip_fetch_array($res)){
  11.                 spip_query("UPDATE spip_documents SET id_type="._q($row['id_type'])." WHERE extension="._q($row['extension']));
  12.         }
  13.         spip_query("UPDATE spip_documents SET mode='vignette' WHERE mode='image'");
  14.        
  15.         foreach(array('spip_articles','spip_auteurs','spip_breves','spip_mots','spip_rubriques','spip_documents','spip_syndic','spip_forum','spip_signatures') as $t){
  16.                 spip_query("ALTER TABLE $t ADD idx ENUM('', '1', 'non', 'oui', 'idx') DEFAULT '' NOT NULL");
  17.                 spip_query("ALTER TABLE $t ADD INDEX (idx)");
  18.         }
  19.         include_spip('inc/meta');
  20.         ecrire_meta('version_installee','1.927');
  21.         ecrire_metas();
  22. ?>

Mise en oeuvre

Copiez le dans un squelette « retrograde.html » à la racine de votre site, et appelez le ensuite avec l’url « http://votredomaine.com/spip.php?pa....

Ca mouline un peu et hop. C’est fini.

Pour compléter la manoeuvre, utilisez éventuellement le plugin recherche_etendue qui vous permettra de forcer la reconstruction de l’indexation pour le moteur de recherche. Ou sinon attendez un peu ...

Et vous vous utilisez quelle version pour votre site en ligne ? ;-)

Avertissements

Evidemment, comme vous êtes un pionnier, un aventurier, un défricheur, tout cela est sans garantie ni aucun support d’aucune sorte. Vous êtes prévenus .

Accessoirement, faire une copie de sa base avant l’opération peut-être un signe qu’il vous reste deux sous de conscience.

Retour en haut de la page

30 Messages de forum

Voir toute la discussion

Pages 1 | 2 | 3

  • Répondre à ce message

    7 septembre 19:17

    Même problème ce script n’a rien changé pour moi non plus

  • Répondre à ce message

    23 mai 21:05 , par patrickb

    En plein dans le mille.... La réponse la plus sensée de ce fil !!! J’applaudit des deux mains !

  • Répondre à ce message

    19 février 18:06 , par achille

    Bonjour,

    Je suis siderer par ce que je lit dans ce forum J’ai besoin de ce script car j’ai fait une boulette j’ai monter la version dev sur le mauvais site.

    Je crois que la seule chose à marquer ici c’est merci, merci cedric d’avoir pris de ton temps pour nous donner gracieusement une possibilité de ratrapper NOS erreurs.

    Et hop

  • Répondre à ce message

    25 décembre 2007 20:06 , par JamesNicolas

    Je tenais à remercier l’auteur de ce script qui m’a sauvé la vie (mais pourquoi aussi vouloir toujours être à jour ! Quelle idée^^) Bref Merci Merci Merci ! (tout fonctionne à merveille pour moi en tout cas)

  • Répondre à ce message

    10 décembre 2007 16:55 , par Daniel81

    j’ai utilisé en simulation sous phpadmin ce script. je suis en utf-8. La base de donnée devient compatible avec la (version 1.9.2.c) mais elle perd tous les accents ?. Une piste ?

  • Répondre à ce message

    26 novembre 2007 13:19 , par fred

    Pour commencer, j’ai déjà lu ce genre de "règlement de compte a ok corral". Perso, ça fait 5 ans que j’utilise spip pour des site persos pros et même en bénévolat et, pour avoir testé d’autre cms, je tiens à dire que spip toute versions confondues est le plus souple de tous et le plus compréhensible aussi. Tout est personnisable à 200% (squelettes/css) et on est pas obliger de s’inspirer de la dist pour que le site fonctionne. Il suffit de cocher une case dans l’admin pour l’optimiser... et que la majorité des plugins sont compatible avec la version stable en cours.

    C’est vrai que moi aussi je m’arrache les cheveux lorsque ça ne fonctionne pas et que je me retrouve avec un magnifique Site en travaux/erreur msql et que mes modifications (eg les plus longues et les plus chiantes) n’ont pas été saugardée ou lorsque je suis passé en 193 et que plus rien ne s’affichait ni en public ni en admin. Mais bon ce danger est écrit noir sur blanc, et rien ne vaut mamp (osx) ou easy php(win) pour faire ce genre d’experience.

    Pour finir, même si là ça n’est pas flagrant ici, les devs sont prêt à remettre sur la table leurs plugin et à les modifier si on expose calmement le bug rencontré.

    Vivement la 193 stable que je puisse utiliser le plug autorité à 100%

  • Répondre à ce message

    2 novembre 2007 14:22 , par Suske

    Heu, oui mais heu... La 099C elle valide xhtml1.1 strict et elle accepte les formats de documents que MS tente de faire standardiser ?

    Passke sinon, je vous le dis, tout cela est lamentable :-)

  • Répondre à ce message

    30 octobre 2007 22:52 , par Cedric Morin

    Oui, je viens aussi du monde de l’industrie ou les bugs logiciels peuvent mettre en danger la sécurité des personnes. Où l’on rédige des spécifications fonctionelles, corroborées par une analyse préliminaire de la surêté de fonctionnement. Où l’on pratique le cycle de développement en V. Où l’on réalise des tests unitaires, puis des tests d’intégration ...

    J’en passe, et des meilleures, sur les tonnes de papiers que l’on produit dans ces modes de fonctionnement pour justifier, appuyer, confirmer la cahier des charges et les choix techniques qui prévalent à sa bonne tenue.

    Je tairais les magnifique plantade dans lesquelles cela mène tout aussi sûrement, les plannings de développement logiciel jamais tenus, les reprises de code pour spécification erronée, ou mal comprise, ou mal interpretée. Et tout cela en connaissant dès le début parfaitement l’environnement matériel et logiciel, les contraintes de performances etc ...

  • Répondre à ce message

    27 octobre 2007 15:12 , par Fil

    Ruby on Rails propose de créer un script de downgrade avec chaque script d’upgrade, c’est en effet pas idiot.

  • Répondre à ce message

    26 octobre 2007 01:39 , par NicolasR

    Pour abonder dans le sens du post d’esj je reprends des passages du troll d’origine

    il suffit que le cahier des charges soit CORRECTEMENT élaboré, MUREMENT réfléchis afin que la version 1.9.2c soit tout à fait compatible avec la version 1.9.3

    C’est une pure calomnie (et/ou une grande incompréhension) que d’envisager cela ... il n’y a jamais eu de "cahier des charges MUREMENT réfléchis, etc .." pour SPIP. Dans le cas contraire je suppose qu’il n’aurait jamais démarré ou progressé d’ailleurs, par exemple cf. http://archives.rezo.net/spip-dev.m.... Par contre il y a beaucoup de réflexions, d’intuitions, de besoins, d’envies, de remontés de bugs, d’échanges, d’impulsions individuelles ou collectives. Et cela peut emprunter des tours et des détours comme il est normal dans toute oeuvre de création. Comme beaucoup de projets du libre, SPIP relève du processus « Bazar organisé » et non pas « Cathédrale » (cf. La cathédrale et le bazar. C’est peut être déroutant ou insécurisant parfois pour l’utilisateur mais c’est ce mode de fonctionnement qui lui à permis d’exister et de progresser, et qui assure sa pérennité.

    Je vais te faire un petit dessin : tu passes des heures BENEVOLEMENT à réaliser un site scolaire (ne soit pas surprise, il n’y a pas que les dev de SPIP qui font du bénévolat) ... Je risque donc d’attendre longtemps, pour ne pas dire très longtemps avant de pouvoir faire évoluer le site.

    Soyons clair, le fait d’avoir pu utiliser gratuitement (en argent) SPIP et des plugins (ce qui n’est pas rien si l’on y songe) pour faire un site, quelque soit le sujet, les contraintes, ou le cadre économique associé à ce site (bénévolat ou pas peu importe), ne donne aucun droit à *exiger* que dans le cadre de la communauté soit assuré le SAV (puisqu’il n’y a pas de V), c’est défini sans ambiguité ici : Mon site sous SPIP est planté, est-ce que je vous fais un procès ?. D’autant plus quand il s’agit ici des fonctions particulières avancées non standards.

    Le constat est que le développeurs font généralement le (très gros) effort de suivre leurs contributions, autant qu’il leur est possible. Pour cela ils doivent y trouver, d’une manière ou d’une autre, une motivation (par exemples des retours de bugs circonstanciés). Ce genre de message agressif et consumériste, n’y contribue certainement pas. Profiter des compétences que l’on argue pour contribuer fait au contraire avancer les choses.

    @+ NicolasR

Pages 1 | 2 | 3

Répondre à cet article

Retour en haut de la page

Ça discute par ici

SPIP | Squelette | | Plan du site | Suivre la vie du site RSS 2.0