SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 201 visiteurs en ce moment

Accueil > Améliorations de l’espace privé > Champs extra > Champs Extras 3 - API et créations

Champs Extras 3 - API et créations

22 mars 2012 – par Matthieu Marcillaud – 54 commentaires

25 votes

Dans ce document vous trouverez expliquées les API disponibles dans le plugin « Champs Extras 3 » ainsi que les manières de les utiliser pour créer un plugin ajoutant des champs extras (via ces API donc).

Le plugin « Champs Extras Interface » entre autres s’appuie sur ces API et offre un interface graphique pour gérer ces champs.

API d’autorisation / restrictions des champs extras

Comme dans la version précédente, il est possible de restreindre l’usage de champs extras à certains secteurs ou rubriques. La fonction d’API restreindre_extras est identique, cependant, les noms des fonctions d’autorisations sous-jacentes ont, eux, évolué.

La fonction restreindre_extras facilite les restrictions des champs, c’est à dire des restrictions d’affichages définies en fonction de la rubrique à laquelle ces champs appartiennent. Ces fonctions sont à placer dans le fichier squelettes/mes_fonctions.php. Leur rôle est de créer « à la volée » les fonctions d’autorisations adéquates (elles sont décrites plus loin).

Pour leur bon fonctionnement, il est nécessaire de charger la librairie inc/cextras_autoriser.

Les arguments de cette fonction sont :

  1. objet incriminé (article, rubrique, mot, site...)
  2. nom du/des champ(s) extras
  3. identifiants de restriction (par défaut des rubriques)
  4. cible (par défaut ’rubrique’, mais peut aussi être ’secteur’ ou ’groupe’)
  5. recursif (false par défaut) (applique t-on aux éléments enfants ?)

Un exemple de fichier d’autorisation et diverses autorisations :

  1. <?php
  2. include_spip('inc/cextras_autoriser');
  3.  
  4. // restreindre le champ 'gamma' des articles, sur la rubrique 2
  5. restreindre_extras('article', 'gamma', 2);
  6. // restreindre le champ 'alpha' et 'beta' des articles, sur les rubriques 2 et 3
  7. restreindre_extras('article', array('alpha', 'beta'), array(2, 3));
  8. // restreindre le champ 'iota' des rubriques, sur la rubrique 37
  9. restreindre_extras('rubrique', 'iota', 37);
  10. // restreindre le champ 'iota' des rubriques, sur la rubrique 37 et ses sous rubriques
  11. restreindre_extras('rubrique', 'iota', 37, 'rubrique', true);
  12. // restreindre les champs 'alpha' et 'beta' des articles, sur les rubriques 37 et 38 et leurs enfants
  13. restreindre_extras('article', array('alpha', 'beta'), array(37, 38), 'rubrique', true);
  14. // lorsqu'on veut appliquer sur un secteur, préférer 'secteur' plutôt que rubriques récursives. Pour restreindre au secteur 2 :
  15. restreindre_extras('article', 'beta', 2, 'secteur');
  16.  
  17. ?>

Télécharger

Un argument supplémentaire permet donc de définir la fonction qui fera la recherche de validité, et vaut par défaut ’rubrique’, ce qui charge la fonction inc_restreindre_extras_objet_sur_{rubrique}_dist. Le plugin supporte aussi secteur et groupemot :

  1. // restreindre les champs 'motin' et 'moteur' des mots, sur le groupe 2
  2. restreindre_extras('mot', array('motin', 'moteur'), 3, 'groupemot');

Télécharger

Depuis la version 3.3.0, il est aussi possible de restreindre les champs extras en fonction de la composition de l’objet, ex :

  1. // restreindre le champ 'loisirs' sur les articles qui portent la composition 'cv'
  2. restreindre_extras('article', 'loisirs', 'cv', 'composition');

Télécharger

Depuis la version 3.7.0, il est aussi possible de restreindre les champs extras en fonction d’un mot clé lié à l’objet, ex :

  1. // restreindre le champ 'loisirs' sur les articles qui portent un des mots clés n°9 ou 10
  2. restreindre_extras('article', 'loisirs', array(9, 10), 'mot');

Télécharger

Notes :

  • Par souci d’optimisation (moins de requêtes SQL), il est préférable de regrouper en un seul appel au lieu de plusieurs lorsque c’est possible,
  • Il n’est pas possible de définir deux restrictions différentes pour un même champ extra.
    1. // impossible (seul le 1er est pris en compte) :
    2. restreindre_extras('article', 'c1', 1);
    3. restreindre_extras('article', 'c1', 2);
    4. // Utiliser :
    5. restreindre_extras('article', 'c1', array(1, 2));
    6.  
    7. // Mais grouper les champs dés que c'est possible (mêmes identifiants d'application). Si :
    8. restreindre_extras('article', 'c1', array(1, 2));
    9. restreindre_extras('article', 'c2', array(1, 2));
    10. // Préférer :
    11. restreindre_extras('article', array('c1', 'c2'), array(1, 2));

    Télécharger

Fonctions d’autorisations précises

Certains cas sont bien plus complexes et peuvent nécessiter que vous créiez vous-même les fonctions d’autorisations avec leurs actions qui vont bien. Ces fonctions doivent être nommées (le _dist n’est pas obligatoire) :

  • autoriser_{objet}_voirextra_{champ}_dist
  • autoriser_{objet}_modifierextra_{champ}_dist

Cela peut donner une fonction (table auteurs, champ prenom) :

  • autoriser_auteur_voirextra_prenom_dist
  • autoriser_auteur_modifierextra_prenom_dist

Un exemple de code simple pourrait être :

  1. // seuls les rédacteurs et admins peuvent voir
  2. function autoriser_auteur_voirextra_prenom_dist() {
  3. return in_array($qui['statut'], array('0minirezo', '1comite'));
  4. }
  5. // seuls les admins peuvent modifier
  6. function autoriser_auteur_modifierextra_prenom_dist() {
  7. return in_array($qui['statut'], array('0minirezo'));
  8. }

Télécharger

Voici un autre exemple plus complet qui teste si un article a une certaine composition, la composition « carte », pour afficher ou non des champs extras :

  1. /* AUTORISATIONS */
  2. function grainepc_objet_est_carto($objet, $id) {
  3. $compo = compositions_determiner($objet, $id);
  4. return ($compo == 'carte');
  5. }
  6.  
  7. // autorisations des champs extras de carte ...
  8. foreach (array(
  9. 'declinaison',
  10. 'structure',
  11. 'affichage',
  12. 'date_creation',
  13. 'coordonnees',
  14. 'presentation',
  15. 'infos') as $nom)
  16. {
  17. $m = "autoriser_article_modifierextra_" . $nom . "_dist";
  18. $v = "autoriser_article_voirextra_" . $nom . "_dist";
  19.  
  20. $code = "
  21. if (!function_exists('$m')) {
  22. function $m(\$faire, \$type, \$id, \$qui, \$opt) {
  23. return grainepc_objet_est_carto(\$type, \$id);
  24. }
  25. }
  26. if (!function_exists('$v')) {
  27. function $v(\$faire, \$type, \$id, \$qui, \$opt) {
  28. return grainepc_objet_est_carto(\$type, \$id);
  29. }
  30. }
  31. ";
  32.  
  33. # var_dump($code);
  34. eval($code);
  35. }

Télécharger

Créer un plugin en utilisant les API de Champs Extras

Vous le savez, le plugin « Champs Extras Interfaces » s’appuie sur une API de Champs Extras pour proposer une gestion graphique des champs. Cependant, des plugins peuvent aussi s’appuyer sur cette API afin de décharger sur le plugin champs extras la gestion de l’affichage, de la vérification et le traitement de nouveaux champs. Il n’y a rien d’obligatoire à cette utilisation, vous pouvez très bien développer un plugin qui crée des nouveaux champs en base et les gère de lui-même en utilisant les pipelines fournis par SPIP. L’avantage ici, est que toutes les déclarations sont regroupées dans un seul pipeline, et que la procédure d’installation et de désinstallation est simplifiée. Voyons un exemple, l’extension de démonstration nommée « Titre court pour rubriques ».

Tout d’abord, il faut créer un paquet.xml présentant le plugin :

  1. <paquet
  2. prefix="titrecourt"
  3. categorie="outil"
  4. version="1.1.0"
  5. etat="stable"
  6. compatibilite="[3.0.0-beta;["
  7. logo=""
  8. schema="0.0.1"
  9. >
  10. <nom>Titre Court pour Rubriques</nom>
  11.  
  12. <auteur>Matthieu Marcillaud [->magraine.net]</auteur>
  13. <licence>GNU/GPL</licence>
  14.  
  15. <necessite nom="cextras" compatibilite="[3.0.5;[" />
  16.  
  17. <pipeline nom="declarer_champs_extras" inclure="base/titrecourt.php" />
  18. </paquet>

Télécharger

On remarque l’indication de dépendance à « cextras » qui est, donc, le cœur de Champs Extras, son API (« iextras » étant le plugin d’interface graphique), ainsi que l’appel d’un pipeline declarer_champs_extras.

Nous allons remplir le pipeline de notre nouveau champ « titrecourt » sur la table des rubriques. Pour cela, on crée le fichier base/titrecourt.php avec comme contenu :

  1. <?php
  2. if (!defined("_ECRIRE_INC_VERSION")) return;
  3.  
  4. function titrecourt_declarer_champs_extras($champs = array()) {
  5. $champs['spip_rubriques']['titre_court'] = array(
  6. 'saisie' => 'input',//Type du champ (voir plugin Saisies)
  7. 'options' => array(
  8. 'nom' => 'titre_court',
  9. 'label' => _T('titrecourt:titre_court'),
  10. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  11. 'defaut' => '',// Valeur par défaut
  12. 'restrictions'=>array('voir' => array('auteur' => ''),//Tout le monde peut voir
  13. 'modifier' => array('auteur' => 'webmestre')),//Seuls les webmestres peuvent modifier
  14. ),
  15. );
  16. return $champs;
  17. }
  18. ?>

Télécharger

Observons. Le code remplit un tableau de description dans $champs['spip_rubriques']['titre_court']. Le principe est donc de remplir le tableau $champs avec une clé indiquant la table SQL, puis une clé indiquant la colonne SQL $champs[table][champ].

Le tableau de description est ensuite au format du plugin « Saisies » (puisque Champs Extras s’appuie dessus). On trouve cependant 5 options supplémentaires :

  • « nom » indique le nom le la colonne SQL désirée,
  • « sql » indique la ligne SQL correspondante,
  • « rechercher » (optionnel) permet d’indiquer si le champ doit être pris en compte dans les recherches. Vous pouvez renseigner la valeur true (la pondération appliquée par défaut est 2), ou toute valeur entière de pondération de recherche désirée, par exemple 5 ;
  • « versionner » (optionnel) permet d’indiquer si le champ peut être versionné lorsque les révisions sont activées (plugin révisions) sur l’objet éditorial sur lequel est ajouté le champs extras. true pour activer le versionnage ;
  • « restrictions » (optionnel) permet d’indiquer les restrictions appliquées automatiquement dans l’espace privé. On peut trouver dedans les options :
    • ’voir’ => array(’auteur’=>’’) // tout le monde peut voir (c’est l’action par défaut !)
    • ’modifier => array(’auteur’ => ’admin’) // seuls les admins.
    • ’modifier => array(’auteur’ => ’admin_complet’) // seuls les admins non restreints
    • ’modifier => array(’auteur’ => ’webmestre’) // seuls les webmestres.
    • ’secteur’ => ’3’ (restreint au secteur 3).
    • ’secteur’ => ’3:5:8’ (restreint au secteurs 3, 5 et 8).
    • ’branche’ => ’2’ (restreint à la branche 2...).
    • ’rubrique’ => ’1’.
    • ’groupe’ => ’4’.

Notez que si ces restrictions ne sont pas suffisantes, vous pouvez créer comme on l’a vu plus haut les fonctions d’autorisations spécifiques à vos champs extras.

Le dernier fichier à créer gère l’installation et la désinstallation des champs. C’est dans notre exemple le fichier titrecourt_administrations.php et il contient le minimum syndical :

  1. <?php
  2. if (!defined("_ECRIRE_INC_VERSION")) return;
  3.  
  4. include_spip('inc/cextras');
  5. include_spip('base/titrecourt');
  6.  
  7. function titrecourt_upgrade($nom_meta_base_version,$version_cible) {
  8.  
  9. $maj = array();
  10. cextras_api_upgrade(titrecourt_declarer_champs_extras(), $maj['create']);
  11.  
  12. include_spip('base/upgrade');
  13. maj_plugin($nom_meta_base_version, $version_cible, $maj);
  14.  
  15. }
  16.  
  17. function titrecourt_vider_tables($nom_meta_base_version) {
  18. cextras_api_vider_tables(titrecourt_declarer_champs_extras());
  19. effacer_meta($nom_meta_base_version);
  20. }
  21. ?>

Télécharger

On trouve les fonctions upgrade() et vider_tables() des plugins, qui appellent des fonctions cextras_api_upgrade() et cextras_api_vider_tables() avec le contenu de la fonction qui liste les champs que l’on crée, ici titrecourt_declarer_champs_extras().

Pour la fonction d’upgrade, on indique aussi où l’on souhaite créer les mises à jour, ici dans $maj['create'] qui est « à la création du plugin », mais cela aurait pu être appelé aussi lors d’une mise à jour (par exemple si vous avez ajouté un champ de plus).

  1. $maj = array();
  2. cextras_api_upgrade(titrecourt_declarer_champs_extras(), $maj['create']);
  3. // mise à jour de la version 1.2 (nouveaux champs a créer)
  4. cextras_api_upgrade(titrecourt_declarer_champs_extras(), $maj['1.2']);

Télécharger

Un autre exemple...

Voici un autre exemple plus complexe. C’était pour cet exemple que les autorisations par compositions avaient aussi été créées. Ici, plusieurs champs sont présents sur des tables différentes et plusieurs mises à jour sont faites.

Déclaration des champs

  1. <?php
  2.  
  3. if (!defined("_ECRIRE_INC_VERSION")) return;
  4.  
  5. function grainepc_declarer_champs_extras($champs = array()){
  6. $champs['spip_auteurs']['telephone'] = array(
  7. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  8. 'options' => array(
  9. 'nom' => 'telephone',
  10. 'label' => _T('grainepc:info_telephone'),
  11. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  12. 'defaut' => '',// Valeur par défaut
  13. ));
  14.  
  15. $champs['spip_articles']['declinaison'] = array(
  16. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  17. 'options' => array(
  18. 'nom' => 'declinaison',
  19. 'label' => _T('grainepc:info_declinaison'),
  20. 'sql' => "text DEFAULT '' NOT NULL",
  21. 'defaut' => '',// Valeur par défaut
  22. 'traitements' => '_TRAITEMENT_TYPO',
  23. ));
  24.  
  25. $champs['spip_articles']['structure'] = array(
  26. 'saisie' => 'radio', // Type du champs (voir plugin Saisies)
  27. 'options' => array(
  28. 'nom' => 'structure',
  29. 'label' => _T('grainepc:info_type_structure'),
  30. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  31. 'defaut' => '',// Valeur par défaut
  32. 'datas' => array(
  33. '' => _T('grainepc:info_rien'),
  34. 'structure' => _T('grainepc:info_structure'),
  35. 'structure_adherente' => _T('grainepc:info_structure_adherente'),
  36. ),
  37. ));
  38.  
  39.  
  40. $champs['spip_articles']['affichage'] = array(
  41. 'saisie' => 'radio', // Type du champs (voir plugin Saisies)
  42. 'options' => array(
  43. 'nom' => 'affichage',
  44. 'label' => _T('grainepc:info_affichage'),
  45. 'sql' => "varchar(30) NOT NULL DEFAULT 'complet'",
  46. 'defaut' => 'complet',// Valeur par défaut
  47. 'datas' => array(
  48. 'complet' => _T('grainepc:info_complet'),
  49. 'reduit' => _T('grainepc:info_reduit'),
  50. ),
  51. ));
  52.  
  53. $champs['spip_articles']['date_creation'] = array(
  54. 'saisie' => 'date', // Type du champs (voir plugin Saisies)
  55. 'options' => array(
  56. 'nom' => 'date_creation',
  57. 'label' => _T('grainepc:info_date_creation'),
  58. 'sql' => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
  59. 'defaut' => '',// Valeur par défaut
  60. ),
  61. 'verifier' => array(
  62. 'type' => 'date',
  63. 'options' => array(
  64. 'normaliser' => 'datetime',
  65. )
  66. ));
  67.  
  68. $champs['spip_articles']['coordonnees'] = array(
  69. 'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
  70. 'options' => array(
  71. 'nom' => 'coordonnees',
  72. 'label' => _T('grainepc:info_coordonnees'),
  73. 'sql' => "text DEFAULT '' NOT NULL",
  74. 'defaut' => '',// Valeur par défaut
  75. 'rows' => 4,
  76. 'traitements' => '_TRAITEMENT_RACCOURCIS',
  77. ));
  78.  
  79. $champs['spip_articles']['presentation'] = array(
  80. 'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
  81. 'options' => array(
  82. 'nom' => 'presentation',
  83. 'label' => _T('grainepc:info_presentation'),
  84. 'sql' => "text DEFAULT '' NOT NULL",
  85. 'defaut' => '',// Valeur par défaut
  86. 'rows' => 6,
  87. 'traitements' => '_TRAITEMENT_RACCOURCIS',
  88. ));
  89.  
  90. $champs['spip_articles']['infos'] = array(
  91. 'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
  92. 'options' => array(
  93. 'nom' => 'infos',
  94. 'label' => _T('grainepc:info_infos'),
  95. 'sql' => "text DEFAULT '' NOT NULL",
  96. 'defaut' => '',// Valeur par défaut
  97. 'rows' => 5,
  98. 'traitements' => '_TRAITEMENT_RACCOURCIS',
  99. ));
  100.  
  101. return $champs;
  102. }
  103.  
  104. ?>

Télécharger

Installation

  1. <?php
  2.  
  3. include_spip('inc/cextras');
  4. include_spip('base/grainepc');
  5.  
  6. function grainepc_upgrade($nom_meta_base_version,$version_cible){
  7. $maj = array();
  8.  
  9. cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['create']);
  10. cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.1.0']);
  11. cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.2.0']);
  12. $maj['1.2.0'][] = array('sql_alter',"TABLE spip_auteurs DROP type");
  13. cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.3.0']);
  14.  
  15. include_spip('base/upgrade');
  16. maj_plugin($nom_meta_base_version, $version_cible, $maj);
  17. }
  18.  
  19. function grainepc_vider_tables($nom_meta_base_version) {
  20. cextras_api_vider_tables(grainepc_declarer_champs_extras());
  21. effacer_meta($nom_meta_base_version);
  22. }
  23.  
  24. ?>

Télécharger

Un autre exemple... en utilisant un ou plusieurs fieldset pour séparer les nouveau champs ajoutés

Voici un autre exemple où les champs sont regroupés par fieldsets (suite à une question posée dans les forums de cet article).

Ici, l’ensemble des champs sont sur la même table, et sont regroupés en deux fieldsets différents numeros et adresse.

Déclaration des champs

  1. <?php
  2.  
  3. if (!defined("_ECRIRE_INC_VERSION")) return;
  4.  
  5. function numadresse_declarer_champs_extras($champs = array()){
  6.  
  7. $champs['spip_auteurs']['numeros'] = array(
  8. 'saisie' => 'fieldset',//Type du champ (voir plugin Saisies)
  9. 'options' => array(
  10. 'nom' => "numeros",
  11. 'label' => _T('numadresse:legend_numeros')
  12. ),
  13. 'saisies' => array(
  14. 'telephone' = array(
  15. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  16. 'options' => array(
  17. 'nom' => 'telephone',
  18. 'label' => _T('numadresse:info_telephone'),
  19. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  20. 'defaut' => '',// Valeur par défaut
  21. )),
  22. 'fax' = array(
  23. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  24. 'options' => array(
  25. 'nom' => 'fax',
  26. 'label' => _T('numadresse:info_fax'),
  27. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  28. 'defaut' => '',// Valeur par défaut
  29. ))
  30. );
  31. $champs['spip_auteurs']['adresse'] = array(
  32. 'saisie' => 'fieldset',//Type du champ (voir plugin Saisies)
  33. 'options' => array(
  34. 'nom' => "adresse",
  35. 'label' => _T('numadresse:legend_adresse')
  36. ),
  37. 'saisies' => array(
  38. 'adresse' = array(
  39. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  40. 'options' => array(
  41. 'nom' => 'adresse',
  42. 'label' => _T('numadresse:info_adresse'),
  43. 'sql' => "text NOT NULL DEFAULT ''",
  44. 'defaut' => '',// Valeur par défaut
  45. )),
  46. 'code_postal' = array(
  47. 'saisie' => 'input', // Type du champs (voir plugin Saisies)
  48. 'options' => array(
  49. 'nom' => 'code_postal',
  50. 'label' => _T('numadresse:info_code_postal'),
  51. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
  52. 'defaut' => '',// Valeur par défaut
  53. ))
  54. );
  55.  
  56. return $champs;
  57. }
  58.  
  59. ?>

Télécharger

Pour l’installation de ces champs, faire comme l’exemple situé plus haut.

Les quatres nouveaux champs sont ainsi répartis dans deux fieldsets différents en bas du profil de l’auteur.

Voir en ligne : http://plugins.spip.net/cextras

Dernière modification de cette page le 26 août 2015

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 24 octobre à 18:11, par Ruminez En réponse à : Champs Extras 3 - API et créations

    Bonjour,
    J’utilise cextra, l’interface graphique et inscriptions3.
    Lorsqu’un utilisateur s’inscrit, les champs sont bien récupérés sauf les « extras ». Cependant, en modification de fiche (utilisateur ou admin), tout se passe bien.
    Bien entendu, rien dans les logs d’erreur
    Y a-t-il quelque chose que j’ai loupé ?
    Merci pour votre aide

    Répondre à ce message

  • Le 22 août à 08:18, par PRX En réponse à : Champs Extras 3 - API et créations

    bonjour,
    une remarque / erreur à l’upgrade de 3.0.19 à 3.1.1 : j’ai un message :

    « Fatal error : Call to undefined function cextras_declarer_tables_objets_sql() in /home/yanfoom/www/plugins/auto/cextras/v3.8.0/cextras_options.php on line 39 »

    j’ai fait recharger la page et ai une page de spip normale en 3.1.1.
    Je n’ai pas testé les fonctionnalités pour valider son fonctionnement.
    Peut-être une correction ?

    • Le 22 août à 13:06, par Pierre KUHN En réponse à : Champs Extras 3 - API et créations

      Bonjour,

      les plugins était à jour avant l’upgrade de spip ?

    • Le 22 août à 13:26, par PRX En réponse à : Champs Extras 3 - API et créations

      Bonjour, merci de votre réponse.
      ce plugin oui, MAIS un autre ne l’était PAS (un thème non disponible en 3.1) et a disparu du coup : est-ce cela ?

    • Le 23 août à 08:10, par Pierre KUHN En réponse à : Champs Extras 3 - API et créations

      Bonjour,

      Logiquement non.
      Cache vider de spip pour corriger le problème ?

    • Le 24 août à 08:36, par PRX En réponse à : Champs Extras 3 - API et créations

      bonjour - merci : votre plugin était mis à jour depuis fort longtemps avant la bascule - je n’avais pas vidé le cache avant la bascule en 3.1.1.
      J’ai rechargé la page (bouton du navigateur) et ai obtenu une page de spip normale en 3.1.1. Il n’y a à priori pas de conséquence ni de blocage bien que je n’aie pas utilisé les champs extra depuis.

    Répondre à ce message

  • Le 2 décembre 2015 à 09:18, par peetdu En réponse à : Champs Extras 3 - API et créations

    J’ai un petit soucis avec la restriction par rubrique. En elle même elle marche bien. Mais il y a un effet indésirable avec les boutons du menu de raccourcis (Créer un nouvel article, etc.).

    Lorsque le rédacteur est en page d’accueil du Back office et qu’il clique sur le raccourci rapide « Écrire un nouvel article », ne sachant pas alors dans quelle rubrique il va le créer, aucun des champs extras n’apparait dans formulaire d’édition article.

    Une solution serait de faire apparaître ces champs extra ad-hoc au moment ou le rédacteur à choisi sa rubrique. Est-ce possible ?

    P
    ps : cette solution m’a été suggérée par deux rédacteurs

    • Le 2 décembre 2015 à 17:40, par Matthieu Marcillaud En réponse à : Champs Extras 3 - API et créations

      En l’état : non.
      Il faudrait recharger le formulaire à chaque changement de rubrique dans le sélecteur, et on risquerait de perdre des données déjà saisies.

      C’est un « problème » connu cependant.

      Pour info, les boutons d’actions rapide ont la rubrique indiquée si on se trouve, justement dans une rubrique. Le problème est donc plus visible lorsqu’on clique dessus depuis le sommaire par exemple.

    • Le 3 décembre 2015 à 08:22, par peetdu En réponse à : Champs Extras 3 - API et créations

      Ok. Merci pour ces éclaircissements.

    Répondre à ce message

  • Le 19 juin 2015 à 17:13, par cdg_spy En réponse à : Champs Extras 3 - API et créations

    Bonjour,

    J’ai suivi la partie « Créer un plugin en utilisant les API de champs extras ». Effectivement les champs sont bien créer en base sur les bonnes tables, mais ils ne sont pas d’offices gérés depuis le plugin Champs Extras (interface), et quand on clique sur le bouton « gérer ce champ » ils sont transformés en champs de type textarea => bloc de texte, même si on a par exemple spécifié 'saisie' => 'input' et également les options concernant la saisie/restriction ... passées dans le tableau $champs de ma fonction xx_declarer_champs_extras ne sont pas prise en comptes.

    Pour essayer de comprendre le fonctionnement de la création des champs : je suis allé voir le code de la fonction champs_extras_creer appelée par cextras_api_upgrade et d’après ce que j’ai compris du code, seule les données $saisie['options']['nom'] et $saisie['options']['sql'] sont utilisées.

    D’ou mes questions :

    1. Les informations passées dans le tableau $champs (options : saisie, restriction, verifier) sont-elles réellement prises en compte ? À quel moment ? Et sont-elles stockées quelques parts dans SPIP, puisqu’on ne peut pas le vérifier leurs configuration via le plugin Champs Extras (interface) ?
    2. La création de groupe de champs fieldset fonctionne-t-elle vraiment ? De mon côté et sauf erreur/incompréhension de ma part, j’ai l’impression que cela ne fonctionne pas.
    3. Y a-t-il un moyen de programmer la prise en compte des champs extras créé sur un plugin tiers par le plugin Champs Extras (interface).

    Merci pour votre aide

    • Le 19 juin 2015 à 18:08, par Matthieu Marcillaud En réponse à : Champs Extras 3 - API et créations

      Je crois qu’il y a en manque de clarté.

      L’API crée et gère les champs extras. C’est à dire que si l’on passe par l’API PHP, on ne passe pas par l’interface (ça n’a pas de sens).

      L’interface en fait gère une liste de champs qu’elle présente justement à l’API. Les 2 ne sont pas compatibles.

      Dit autrement : si un champ est déclaré à l’API par un plugin (actif) : les champs sont créés s’ils n’existaient pas, et gérés (on les voit dans les formulaires). L’interface n’a rien à faire (le plugin d’interface peut ne pas être actif même.

      Si l’on active le plugin d’interface, les champs gérés par l’API (des plugins actifs) ne sont pas présentés comme champs qui peuvent être « gérés »… vu qu’ils le sont déjà.

      Il y a cependant le cas où un plugin qui gérait des champs (via champs extras ou pas) n’est plus actif (et n’a pas supprimé les champs par une désinstallation). À ce moment là l’interface voit que ces champs sont présents mais qu’aucun plugin ne semble s’en servir (aucune déclaration) : l’interface propose de les gérer. Mais l’interface ne connait pas grand chose du champ à ce moment là ; à peine sa déclaration SQL. C’est pour cela que dans la plupart des cas, gérer ce type de champ crée par défaut une saisie ’textarea’ (sauf quelques exceptions).

      Donc, sur les points présentés :

      • 1. Normalement oui. Et à quel moment ; eh bien ça dépend de l’option en question. Et non elles ne sont pas stockées ailleurs que dans la déclaration d’API. Le plugin interfaces lui par contre stocke ses données dans la table spip_meta, par exemple dans "iextras_spip_articles" ou quelque chose comme ça.
      • 2. Je pense que oui. Et oui, seules des champs ayant une déclaration SQL sont créés. Normalement tous ces champs (même ceux déclarés dans des saisies/fieldsets) doivent se créer.
      • 3. Hum. Il faudrait préciser. En fait tu pourrais faire écrire des données qui conviennent dans une meta du plugin d’interface. Mais cela veut dire que du coup, ces champs pourraient être modifiés / supprimés depuis l’interface. Ce n’est souvent pas ce qui est souhaité pour un plugin, où l’on veut une liste de champs nouveaux, mais non supprimables.

      Note : la déclaration d’un fieldset doit s’apparenter un peu à ce code http://zone.spip.org/trac/spip-zone/browser/_plugins_/champs_extras/interface/trunk/inc/iextras.php#L184 dans la déclaration d’API, avec bien sûr la définition sql en plus et pas la même affectation au début !

      -  $flux[’data’][$nom] = saisies_inserer($flux[’data’][$nom], array(
      + $champs[’spip_articles’][’un_fieldset’] = array(

    • Le 19 juin 2015 à 18:09, par Matthieu Marcillaud En réponse à : Champs Extras 3 - API et créations

      Ah mais camille & kent1 avaient mis déjà un exemple de fieldset dans l’article. Je n’avais même pas vu.

    Répondre à ce message

  • Le 23 septembre 2013 à 12:04, par Teddy Payet En réponse à : Champs Extras 3 - API et créations

    Bonjour,

    Comment fait-on pour créer un fieldset et les saisies associées ?
    Malgré mes tests, je n’arrive pas à créer en base mes champs extras pour articles...

    Je tourne en rond actuellement.

    • Le 12 août 2014 à 11:46, par cam.lafit En réponse à : Champs Extras 3 - API et créations

      Ciao

      J’ai un début de solution :

      1. $champs['spip_articles']["fieldset_01"] = array(
      2. 'saisie' => 'fieldset',//Type du champ (voir plugin Saisies)
      3. 'options' => array(
      4. 'nom' => 'fieldset_01',
      5. 'label' => 'fieldset 01',
      6. ),
      7. 'saisies' => array(
      8. $champs['spip_articles']['test'] = array(
      9. 'saisie' => 'input',//Type du champ (voir plugin Saisies)
      10. 'options' => array(
      11. 'nom' => 'test',
      12. 'label' => 'test',
      13. 'sql' => "varchar(30) NOT NULL DEFAULT ''",
      14. 'defaut' => '',// Valeur par défaut
      15. 'restrictions' => array(
      16. 'rubrique' => '3'
      17. ),
      18. )
      19. ),
      20. );

      Télécharger

      Dans ce cas de figure nous avons bien un fieldset contenant un champ test.
      Le truc c’est qu’il doublonne le champ test en raison de l’affectation à $champ

    • Le 23 avril 2015 à 15:09, par kent1 En réponse à : Champs Extras 3 - API et créations

      Je viens de poster un exemple fonctionnel (© chez moi ça marche) avec des fieldset en bas de l’article si besoin

    Répondre à ce message

  • Le 4 février 2015 à 22:16, par triton En réponse à : Champs Extras 3 - API et créations

    Bonsoir,
    je teste...
    Après avoir déclaré un certain nombre de champs extra a travers la fonction : function xx_declarer_champs_extras
    je constate que mes champs sont bien créés en base, qu’en plus le formulaire natif de l objet (ici auteur) permet d administrer ces nouveaux champs sans problème et sans une ligne de code. Du coup je suis content, très même...
    Par contre, je m’attendais, benoîtement sans doute, a ce que mes nouveaux champs extras soient également considérés comme tel par l’interface (champs_extras_edit&objet=auteur)
    et que je pourrais continuer à les modifier, déplacer, changer de type... comme les champs extras créés via l interface ? Mais je me trompe, une fois créés par la fonction declarer_champs_extras ces champs deviennent comme les champs natifs de l’objet, immodifiables par l interface, c’est bien ca ?
    Un grand merci pour ce magnifique plugin de plus...
    amicalement

    • Le 4 février 2015 à 22:31, par Matthieu Marcillaud En réponse à : Champs Extras 3 - API et créations

      C’est bien cela.

      Pour changer du coup le type de champ, ou le nom de la colonne sql, il faut à la fois modifier le code de la fonction de déclaration, et éventuellement faire dans la fonction _upgrade du fichier d’administration du plugin une mise à jour du champ (sql_alter), dans le tableau souvent appelé $maj. Par exemple, là il y a $maj['create'] : http://zone.spip.org/trac/spip-zone/browser/_plugins_/champs_extras/extensions/titre_court_rubriques/trunk/titrecourt_administrations.php qui est rempli par la fonction cextras_api_upgrade. Il pourrait y avoir en plus quelque chose comme http://zone.spip.org/trac/spip-zone/browser/_plugins_/contacts_et_organisations/trunk/contacts_administrations.php#L34 , en pensant aussi à modifier le schema du paquet.xml, qui correspond au numéro de dernière mise à jour de la base par le plugin.

    • Le 4 février 2015 à 23:06, par triton En réponse à : Champs Extras 3 - API et créations

      hum... du coup, je me demande si dans mon cas il ne vaut pas mieux étendre la table auteur via l api standard et ensuite demander au plugin champs extras de gerer les nouveaux champs de la table, parce que c’est quand même bien pratique de pouvoir modifier l’ordre des champs du formulaire, ajouter des class css, et surtout des fieldsets (via la fonction declarer_champs_extras, j ai l impression que ca doit être coton d insérer des fieldsets, pas fait pour de toute manière...)
      M’en vais réfléchir à tout ça en dormant...
      Merci bien pour la prompte réponse

    • Le 6 février 2015 à 18:05, par triton En réponse à : Champs Extras 3 - API et créations

      Et si une fois créer les nouveaux champs avec sql_alter dans la partie installation d un plugin, on fait appel a la fonction : champs_extras_creer pour les transformer automatiquement en champs extra... c est une bonne pratique ou c est tout pourri ?
      Parce que le problème des champs extras a cliquer soi meme depuis l interface, c est que c est pas super portable...
      amicalement

    • Le 23 avril 2015 à 15:08, par kent1 En réponse à : Champs Extras 3 - API et créations

      Je viens de mettre un exemple en bas de l’article avec des fieldsets si toujours besoin

    Répondre à ce message

  • Le 7 avril 2015 à 15:23, par jsene En réponse à : Champs Extras 3 - API et créations

    Le plugin propose d’ajouter une barre d’édition gras/italique etc. mais la mise en forme à l’affichage n’est pas prise en compte.

    Ai-je raté quelque chose ? Comment ajouter les champs extras de type textarea au pipeline de mise en forme ?

    merci…

    Répondre à ce message

  • Le 28 juillet 2014 à 15:17, par Pierrot En réponse à : Champs Extras 3 - API et créations

    Bonjour,

    J’ai créé des saisies que j’utilise en champs extras sur des organisations qui appartiennent à des annuaires ... Je souhaiterai restreindre l’apparition de ces champs extras à certains annuaires, je suis en train de m’emmêler les pinceaux :-)

    Je dois donc créer dans un mes_fonctions.php quelque chose du genre :

    include_spip('inc/cextras_autoriser');
    restreindre_extras('organisation', array('champextra1', 'champextra2'), 1, 'annuaire');

    Si j’ai bien lu la doc, ça ne marche pas car restreindre_extras() s’il peut s’appliquer à l’objet « organisation », il va chercher à restreindre l’affichage dans des rubriques/secteur/groupemot, mais pas dans des annuaires ... je dois donc écrire une fonction spéciale genre pour autoriser champextra1 dans l’annuaire avec l’id 1 :

    function autoriser_annuaire_voirextra_champextra1_dist() {
       return in_array($qui['id_annuaire'], 1);
    }

    et idem pour champextra2 et ensuite à doubler avec « modifierextra » ...

    Est-ce que j’ai bon jusque là ? (j’en doute, si je pose la question c’est que ça ne marche pas ... :-)
    Merci pour vos lumières !

    Pierre

    • Le 16 septembre 2014 à 11:34, par PIerrot En réponse à : Champs Extras 3 - API et créations

      Bonjour,

      Je me permets un petit up sur ce sujet, je patine toujours dans la choucroute. L’idée générale est bien d’autoriser un champ extra pour une organisation en fonction de son appartenance à un annuaire.
      Donc un truc qui ressemblerait plutot à :

      function autoriser_organisation_voirextra_champextra1_dist($objetutilisantchamp, $nomchampextra, $idobjetcontenantobjetutilisantchamp, $objetcontenantobjetutilisantchamp) {
        //c'est ici que ça se corse ...
      }

      Ai-je bon déjà à ce niveau ? dans l’ordre de ma fonction on aurait (’organisation’, ’nomduchamparestreindre’, 5, ’annuaire’) pour restreindre le champ ’nomduchamparestreindre’ sur les organisations appartenant à l’annuaire n°5 ...
      Ensuite je ne suis pas sûr de ce que doit retourner la fonction ... un true/false simple ?

      Merci d’avance ?
      Pierre

    Répondre à ce message

  • Le 25 mai 2014 à 19:58, par Stephane Vasseur En réponse à : Champs Extras 3 - API et créations

    J’utilise SPIP SPIP 3.0.16 et Champs Extras 3.2.7 .

    J’ai créé un plugin en suivant les exemples ici pour définir un set de champs extra pour les articles. À l’installation du plugin les champs sont bien déclarés dans la base de donnée avec les types souhaités mais ils ne s’affichent pas dans l’espace privé.
    Si j’installe le plugin champs_extra_interface les champs déclarés via l’API apparaissent comme non gérés. Je ne souhaite pas utiliser le plugin interface si possible.

    Dois-je modifier des squelettes de l’espace privé pour que les champs extra déclarés via l’API soient éditables ?

    Merci

    Répondre à ce message

  • Le 25 avril 2013 à 22:22, par loic En réponse à : Champs Extras 3 - API et créations

    Bonjour à tous, d’abord merci pour ce plugin qui est d’une grande utilité.

    Je rencontre un bug lorsque je souhaite utilisé un champ extra de type date, mon article ne s’enregistre pas et j’ai l’erreur suivante :
    « Une erreur technique a empêché l’enregistrement correct du champ ’date_debut’,’date_fin’. »

    Je suis sur spip 3.08 avec la dernière version du plugin champ extra à jour.

    Avez vous une idée ? Je suis bloqué ?

    Merci d’avance.

    • Le 28 avril 2013 à 10:54, par Matthieu Marcillaud En réponse à : Champs Extras 3 - API et créations

      Oui, plein d’idées.

      Déjà, tu es ici sur l’article qui présente les API, je suppose que c’est parce que tu les utilises (et donc que ce n’est pas via l’interface graphique que tu crées tes champs).

      Si c’est par l’interface graphique : la simple présence du plugin « verifier » devrait normalement être suffisant pour gérer correctement la date.

      Si c’est par les API, il faut non seulement le plugin « verifier » actif, mais déclarer aussi une « normalisation » telle que présente dans l’exemple de la partie « Un autre exemple... » de cette page pour le champ de type date :

      1. $champs['spip_articles']['date_creation'] = array(
      2. 'saisie' => 'date', // Type du champs (voir plugin Saisies)
      3. 'options' => array(
      4. 'nom' => 'date_creation',
      5. 'label' => _T('grainepc:info_date_creation'),
      6. 'sql' => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
      7. 'defaut' => '',// Valeur par défaut
      8. ),
      9. 'verifier' => array(
      10. 'type' => 'date',
      11. 'options' => array(
      12. 'normaliser' => 'datetime',
      13. )
      14. ));

      Télécharger

    • Le 28 avril 2013 à 16:42, par loic En réponse à : Champs Extras 3 - API et créations

      Bonjour et merci de votre réponse, alors non je me suis trompé de page, je n’utilise pas l’api mais bien l’interface graphique du plugin champ extra, par défaut dans spip 3.08 il y a déjà le plugin « verifier » j’ai vu que sur spip contrib il y a une version plus récente du plugin « vérifier » donc je l’ai installé. j’ai tester à nouveau et toujours le même message d’erreur.

      Je vous joins une capture d’écran, j’ai simplement ajouter un champ de type date avec heure et j’ai laisser les autres paramètres par défaut. Impossible d’enregistrer l’article.

      Quels précisions de plus avez vous besoin pour identifier ce qui pose problème ?

      Merci d’avance et bon dimanche !

      PNG - 23.2 ko
    • Le 25 février 2014 à 13:15, par glims En réponse à : Champs Extras 3 - API et créations

      Effectivement, j’ai exactement la même chose. Avec en prime en cas de vérification de la date le message suivant ==> Le format de la date n’est pas accepté.

    Répondre à ce message

Répondre à cet article

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 Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Champs Extras 3

    16 janvier 2012 – 534 commentaires

    Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP. Screencast Vous n’aimez pas (...)

  • Réservation d’événements

    16 mars 2015 – 190 commentaires

    Ce plugin permet d’offrir aux visiteurs de s’inscrire pour un évènement du plugin Agenda et de gérer les réservations enregistrées. Installation Le plugin s’installe comme n’importe quel plugin. il nécessite : Agenda API de vérification (...)

  • Les crayons

    23 avril 2008 – 815 commentaires

    Ce plugin permet d’éditer les contenus sur les pages publiques du site, sans passer par l’espace privé de SPIP.

  • LESS pour SPIP : Less-CSS (anciennement LESSpip)

    5 novembre 2010 – 43 commentaires

    Less-CSS (Anciennement LESSpip) est un plugin intégrant facilement le logiciel LESS dans SPIP. LESS est une extension de CSS ajoutant les variables, les classes, les opérations, les imbrications au langage. Facilitant ainsi l’écriture de (...)

  • Recommander

    3 avril 2011 – 16 commentaires

    Ce plugin propose une manière simple de suggérer de recommander par email un article à un ami. Fonction « recommander un article à un ami ». On l’ajoute dans n’importe quel squelette sous la forme : #RECOMMANDERtitre de la page,url de la page,intro (...)

Ça spipe par là