Importer / Exporter des descriptions de champs extras

Vous utilisez le plugin Champs Extra 2 et vous devez changer de serveur, ce plugin est fait pour vous. Il est même indispensable, sans lui impossible de restaurer la sauvegarde de votre site d’origine, car les nouveaux champs créés ne le sont pas encore sur votre site destination et spip ne peut donc y insérer les données.

ATTENTION : Avec SPIP 3 les fonctionnalités d’import et d’exports de champs extras sont déjà prises en charge par la nouvelle mouture du plugin Champs Extras 3 et disponibles depuis son interface. Le présent article ne concerne donc que la branche SPIP 2 et la version Champs Extra 2 du plugin

Installation

Comme tous les autres plugins, cf. http://www.spip.net/fr_article3396.html

Le plugin nécessite les plugins Champs extras 2, Saisies. Il utilise le plugin Champs Extras 2 - Interface

A partir de SPIP 3.0, il n’est plus nécessaire d’installer ce plugin qui est intégré dans le plugin champs extra interface

Fonctionnement

Une fois le plugin activé, il faut se rendre sur la page de configuration des Champs Extras
et cliquer sur Importer / Exporter :

Exporter

L’exportation provoque la création d’une description des champs extras actifs sur votre site. Enregistrez ce contenu qui vous servira à recréer les champs extras sur un autre site. Cette description ne concerne que la déclaration des champs, mais en aucun cas leur contenu ; pour déplacer un site, vous devez donc depuis le site d’origine créer une sauvegarde SPIP et exporter les champs extras, puis sur le site de destination, dans l’ordre, activer les mêmes plugins, importer les champs extras, puis la sauvegarde SPIP.

Importer

L’importation utilise une description des champs extras réalisée par le formulaire d’exportation. Collez le contenu qui a été généré dans le cadre ci-dessous. Les champs extras ne seront créés que si les tables SQL auquels ils correspondent existent. Il est donc prudent d’activer les mêmes plugins que sur le site d’origine (au moins ceux qui créent de nouveaux objets éditoriaux tel que Agenda).

Discussion

7 discussions

  • 5

    Test en cours SPIP 3.2

    C’est OK pour ce qui est de l’import/export YAML

    Pour l’export php en l’occurence, j’ai pas pu vérifier si il était exploitable mais en attendant il me sort quand même bien un fichier qui correspond plutôt bien à la réalité des champs présents.

    EDIT : vérif faite via la doc de cextras 3, et si elle est toujours à jour, à priori c’est ok. je commit.

    <?php
    if (!defined("_ECRIRE_INC_VERSION")) return;
    
    function monplugin_declarer_champs_extras($champs = array()) {
    
    	// Table : spip_auteurs
    	if (!is_array($champs['spip_auteurs'])) {
    		$champs['spip_auteurs'] = array();
    	}
    
    	$champs['spip_auteurs']['auteur_baseline'] = array(
    			'saisie' => 'input',
    			'options' => array(
    				'nom' => 'auteur_baseline',
    				'label' => 'Fonction ?',
    				'sql' => 'text NOT NULL DEFAULT \'\'',
    				'traitements' => '_TRAITEMENT_RACCOURCIS',
    				'rechercher' => 'on',
    				'explication' => 'Une phrase pour nous dire qui vous êtes',
    			),
    		);
    
    
    
    	// Table : spip_forum
    	if (!is_array($champs['spip_forum'])) {
    		$champs['spip_forum'] = array();
    	}
    
    	$champs['spip_forum']['notification'] = array(
    			'saisie' => 'textarea',
    			'options' => array(
    				'label' => 'Notification',
    				'cols' => 40,
    				'rows' => 5,
    				'sql' => 'text DEFAULT \'\' NOT NULL',
    				'nom' => 'notification',
    			),
    		);
    
    	$champs['spip_forum']['notification_email'] = array(
    			'saisie' => 'textarea',
    			'options' => array(
    				'label' => 'Notification_email',
    				'cols' => 40,
    				'rows' => 5,
    				'sql' => 'text DEFAULT \'\' NOT NULL',
    				'nom' => 'notification_email',
    			),
    		);
    
    
    	// Table : spip_syndic
    	if (!is_array($champs['spip_syndic'])) {
    		$champs['spip_syndic'] = array();
    	}
    
    	$champs['spip_syndic']['input_1'] = array(
    			'saisie' => 'input',
    			'options' => array(
    				'nom' => 'input_1',
    				'label' => 'Ligne de texte',
    				'size' => 40,
    				'sql' => 'text DEFAULT \'\' NOT NULL',
    			),
    		);
    
    
    	// Table : spip_documents
    	if (!is_array($champs['spip_documents'])) {
    		$champs['spip_documents'] = array();
    	}
    
    	$champs['spip_documents']['oembed'] = array(
    			'saisie' => 'textarea',
    			'options' => array(
    				'label' => 'Oembed',
    				'cols' => '40',
    				'rows' => '5',
    				'sql' => 'text DEFAULT \'\' NOT NULL',
    				'nom' => 'oembed',
    			),
    		);
    
    	$champs['spip_documents']['doc_img_alt'] = array(
    			'saisie' => 'input',
    			'options' => array(
    				'nom' => 'doc_img_alt',
    				'label' => 'Attribut ALT de l\'image',
    				'explication' => 'Si votre document est une image, permet de renseigner l\'attribut ALT',
    				'type' => 'text',
    				'size' => '40',
    				'autocomplete' => 'defaut',
    				'sql' => 'text DEFAULT \'\' NOT NULL',
    				'rechercher_ponderation' => '2',
    			),
    		);
    
    	return $champs;
    }

    Maintenant si un dev pur jus me confirme que c’est toujours comme ça qu’on alimente la base en PHP, je commit le paquet.xml

    (Bon ya quand même un truc qui me choque, c’est le ?> manquant en fin de fichier mais je sais pas si c’est grave dans ce cas précis ?)

    • Non !
      L’export est intégré à champs extras (interfaces) de SPIP 3.
      Plus besoin de ce plugin.

      Par ailleurs, les fermetures ?> ne sont pas conseillés si le fichier contient uniquement du PHP.

    • Si tu peux revert ta compat sur ce plugin d’export ça serait chouette :)
      En plus j’ai l’impression que tu as testé l’export PHP natif de CE3 et pas celui de ce plugin, car il n’avait pas d’export PHP :p …

    • Fait (r108110)

      Désolé, j’avoue que quand le plugin a cessé de fonctionner en SPIP 3.2 je n’ai absoluement pas tilté que les options étaient pourtant bien là quand même (m’apprendra à commiter en pleine nuit blanche... >< )

      Pour le ?> final oui j’ai vu passer pas mal de commit depuis, visant à les supprimer mais j’avoue que le « pourquoi » m’échappe complètement. C’est documenté quelque part ?

      EDIT : j’en ai profité pour rajouter une petite mention en début de doc. Je te laisse la « crayonner » si tu veux la modifier/préciser/supprimer ... ;)

    • http://php.net/manual/fr/language.basic-syntax.phptags.php

      Si un fichier est purement du code PHP, il est préférable de ne pas placer la balise de fermeture à la fin du fichier. Ceci permet d’éviter d’oublier un espace ou une nouvelle ligne après la balise de fermeture de PHP, ce qui causerait des effets non voulus car PHP commencera à afficher la sortie, ce qui n’est souvent pas ce qui est désiré.

    • Mettre une balise ? > fermante peut causer des problèmes (de headers notamment si jamais des caractères, espaces par exemple, se glissent après cette fermeture)

      Cf http://php.net/manual/fr/language.basic-syntax.phptags.php

    Répondre à ce message

  • 1

    Merci pour ce plugin :-)

    Cependant, quelle est la procédure pour importer des champs extras d’un Spip 2 vers une nouvelle installation en Spip 3 ?

    • En fait, il semble simplement que tout cela soit très bien géré !

      Je viens de faire le test :
      -  MAJ d’un site SPIP2 en SPIP3
      -  les données des champs extras sont conservés en base : affichage des valeurs en site public mais pas encore d’édition dans l’espace privé.
      -  installation du plugin Champs extras 3 (+ interface, saisie, Yaml)
      -  les champs extras (définition et données) sont restaurés et à nouveau éditable dans l’espace privé.
      -  Youpi :-)

      Bravo et merci aux développeurs !

    Répondre à ce message

  • Bonjour Matthieu

    Je veux bien me lancer pour la migration de ce plugin vers SPIP 3.

    D’après toi, est-ce que la migration est facile ?

    Champs extra en SPIP3 fonctionne t’il de la même manière qu’en SPIP2 ?

    Les définitions des champs extra en SPIP3 sont-elles stockées dans spip_meta comme dans SPIP2 ?

    Répondre à ce message

  • 2

    Pas besoin. Les sauvegardes de SPIP 3 sont différentes de celles de SPIP 2 : elles sauvent vraiment toute la base (une sorte de clone - données ET structure) ce qui n’était pas le cas avant. Et la restauration restaure... tout !

    Par ailleurs, si c’est migrer de sqlite -> sqlite, il suffit de copier/coller l’ancienne base (config/bases/nom.sqlite) dans le nouveau site, puis de lancer l’installation du nouveau site.

    MM.

    • Avant même ta réponse, ci-dessous, j’ai fait des test et je suis arrivé à une conclusion y ressemblant beaucoup ! :
      ce plugin n’est plus nécessaire, car je viens de faire, en local, un essai réussi de transfert d’un site SPIP 3 beta 2, utilisant les champs extras :
      -  J’ai dupliqué les fichiers et dossiers du site à la racine d’un nouveau dossier en supprimant les fichiers créés par l’installation dans « /config » et en vidant à l’exception du dossier « /dump » le dossier « /tmp », comme lors d’une mise ne ligne par FTP.
      -  J’ai, ensuite, fait une installation de SPIP, puis une restauration de la base et j’ai la bonne surprise de voir que les champs extras avaient suivi.

      Merci

      Hervé Le Dantec

    • Bonjour

      Ce plugin est toujours nécessaire en SPIP 3 dans un cas de figure très courant : la création d’un tout nouveau site dans lequel on veut récupérer la définition des champs extra d’un site plus ancien.

    Répondre à ce message

  • Bonjour. J’ai testé deux fois ce plugin et à chaque fois le message d’erreur suivant est obtenu :

    Problème d’analyse des données... Mauvais copier coller ?

    sur Spip 2.1.17 SVN

    Répondre à ce message

  • Dans tous les cas, bien pratique quand on n’a pas accès à phpmyadmin ou autres et que l’on est sur du SPIP2. Donc un grand merci pour ce travail.

    Répondre à ce message

  • une version spip 3 est-elle prévue ?

    Je développe un site spip 3 beta 2 en local, mais je veux être sûr de pouvoir exporter mes champs extras au moment de la mise en ligne du site chez l’hébergeur.

    Éviter de passer par un gestionnaire SQLite comme « sqlite manager » (gestionnaire qui m’a, d’ailleurs, été conseillé par Matthieu Marcillaud) pour exporter la table spip_article (sans doute faisable) serait beaucoup plus simple.

    merci d’avance

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

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