Passer un plugin SPIP 3.0 vers SPIP 3.1

SPIP 3.1 est une version de maintenance de SPIP 3.0, se reporter à l’article pour le détail complet.

La mise à jour des bibliothèques Javascript embarquées et certaines évolutions peuvent faire qu’un plugin compatible SPIP 3.0 ne fonctionne plus ou présente des problèmes avec SPIP 3.1.

Aussi il ne suffit pas d’augmenter la borne de compatibilité dans paquet.xml : il faut le tester soigneusement avant de le déclarer compatible SPIP 3.1.

Voici la liste des points à vérifier.

1) Bibliothèques JavaScript jQuery et jQuery UI

Les bibliothèques jQuery et jQuery UI ont été mises à jour, ce changement de version peut entrainer des incompatibilités si le plugin utilise du JavaScript.

jQuery UI 1.11.2
Les scripts ont été renommés : utilisez de préférence le pipeline jqueryui_plugins pour charger les scripts, sinon en cas d’appel direct, il faut tenir compte de la nouvelle nomenclature.
Voir z83728 pour le changement et c21439 pour l’exemple d’appel à modifier.

-  Guide de migration (en)

jQuery 1.11.1
Certaines fonctions sont dépréciées et ne fonctionnent plus, d’autres ont changé de comportement :

-  .attr() → utiliser .val() ou .prop() à la place, voir le ticket correspondant.
-  .toggle()
-  .live()
-  .die()
-  jQuery.browser()

Un cas relativement courant est l’utilisation de .attr().
Sous linux, on peut repérer les fichiers JavaScript employant la fonction au moyen de la commande grep (depuis le répertoire du plugin) :

grep -r --color ".attr()" --include="*.js"

Guides de migration et notes de version :
-  jquery 1.8 (en)
-  jQuery 1.9 (en) + guide de mise à jour (en)
-  jQuery 1.10 (en)
-  jQuery 1.11 (en).

2) Formulaires CVT

Vérifier (php)
L’étape CVT vérifier retourne automatiquement un message d’erreur général en présence d’erreurs : « Il y a N erreurs dans votre saisie, veuillez vérifier les informations. » (accessibilité)
Si on n’en veut pas, il faut definir soit même message_erreur dans le retour avec une chaine vide ou personnalisée.
Cf. r21643

Traiter (php)
L’étape CVT traiter doit obligatoirement retourner un tableau.
L’ancienne syntaxe qui acceptait de retourner une chaine (string) ne passe plus, sinon on obtient un double message.
D’autre part, on peut maintenant renvoyer à la fois un message_erreur un message_ok en sortie ( Ibid.).

Boutons (html)
Les <button> dans les formulaires doivent obligatoirement avoir un attribut type="submit" pour que leur valeur soit prise en compte.
On en trouve par exemple dans les squelettes des listes qui permettent d’associer ou de dissocier des objets : prive/objets/liste/[objet]_associer.html

3) Jointures

Dans les boucles, certaines jointures se comportent différemment, le résultat des boucles utilisant des jointures un peu "complexes" peut changer voir échouer dans certains cas.
Cf. https://core.spip.net/issues/3628 et https://core.spip.net/issues/3654.

4) Manipulation des logos

La façon de manipuler les logos a évolué : action/iconifier.php a été supprimé au profit de action/editer_logo.php (voir en ligne).

Cette nouvelle API permet de modifier ou supprimer le logo d’un objet, elle est utilisée dans le formulaire d’édition des logos prive/formulaires/editer_logo.php (voir en ligne).

Nouvelles fonctions :

logo_supprimer($objet, $id_objet, $etat)
logo_modifier($objet, $id_objet, $etat, $source)

Cf. r21682

5) Balise #FICHIER

La balise #FICHIER retourne le chemin depuis la racine partout en SPIP 3.1 alors qu’elle ne le faisait que sur la boucle DOCUMENTS en 3.0 (https://core.spip.net/issues/3108). Ça permet généralement de simplifier les squelettes.

Pour la compatibilité SPIP 3.0 des plugins on peut ajouter une déclaration pour que #FICHIER fonctionne dans SPIP3.0 comme dans SPIP3.1 dans les boucles, ainsi que le fait le commit 89763 :

if (version_compare($GLOBALS['spip_version_branche'], '3.1-alpha', '<')) {  
    if (!isset($interfaces['table_des_traitements']['FICHIER'])) { 
        $interfaces['table_des_traitements']['FICHIER'] = array(); 
    } 
    $interfaces['table_des_traitements']['FICHIER']['visuels'] = 'get_spip_doc(%s)'; 
} 

Une fois testé et approuvé

On le répète : ne déclarez un plugin compatible SPIP 3.1 qu’après l’avoir testé précautioneusement !
Un plugin déclaré compatible à tort causera bien du souci aux utilisateur.trices.

Une fois sûr.e de vous :

  • changez le numéro de la borne dans paquet.xml
  • changez le numéro le z du x.y.z pour faciliter la mise à jour via SVP
  • Ajoutez le tag SPIP 3.1 dans la documentation de contrib.spip.net

Discussion

2 discussions

  • 4

    Bonjour,

    Est-il possible de passer de Spip 2.1.24 à Spip 3.1 directement ?
    Sinon quelles sont les étapes à suivre pour que tout se passe bien ?

    Merci d’avance,

    Toto

    • Bonjour,
      J’ai forcé la compatibilité en 3.1 dans le fichier paquet.xml, et pour l’instant je n’ai pas vu de problème.
      Pascal

    • Quel plugin ? on pourrait faire les modifs sur la zone si tu es sûr de tes tests…

    • Désolé je me suis embrouillé avec un autre article. Je parlais du plugin Multiflex 3, qui n’a pas de version pour SPIP 3.1. Je ne l’ai pas testé complètement, donc pas sûr qu’il soit 100% compatible 3.1.

    • tu peux completer les tests et me tenir au courant ?

    Répondre à ce message

  • 2

    Euh la doc officielle de val() ne dit pas du tout que c’est déprécié, donc cet article du coup n’est pas très clair pour comprendre dans quel(s) cas on est censé le changer.
    http://api.jquery.com/val/

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom

Dernière modification de cette page le 1er septembre 2016