Champs Extras — API et créations

Dans ce document vous trouverez expliquées les API disponibles dans le plugin « Champs Extras » 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 une interface graphique pour gérer ces champs.

La documentation est valable à partir de la version 3.0.0 du plugin.

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 :

<?php
include_spip('inc/cextras_autoriser');

// restreindre le champ 'gamma' des articles, sur la rubrique 2
restreindre_extras('article', 'gamma', 2);
// restreindre le champ 'alpha' et 'beta' des articles, sur les rubriques 2 et 3
restreindre_extras('article', array('alpha', 'beta'), array(2, 3));
// restreindre le champ 'iota' des rubriques, sur la rubrique 37
restreindre_extras('rubrique', 'iota', 37);
// restreindre le champ 'iota' des rubriques, sur la rubrique 37 et ses sous rubriques
restreindre_extras('rubrique', 'iota', 37, 'rubrique', true);
// restreindre les champs 'alpha' et 'beta' des articles, sur les rubriques 37 et 38 et leurs enfants
restreindre_extras('article', array('alpha', 'beta'), array(37, 38), 'rubrique', true);
// lorsqu'on veut appliquer sur un secteur, préférer 'secteur' plutôt que rubriques récursives. Pour restreindre au secteur 2 :
 restreindre_extras('article', 'beta', 2, 'secteur');

?>

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 :

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

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

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

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 :

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

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.
    // impossible (seul le 1er est pris en compte) :
    restreindre_extras('article', 'c1', 1);
    restreindre_extras('article', 'c1', 2);
    // Utiliser :
    restreindre_extras('article', 'c1', array(1, 2));
    
    // Mais grouper les champs dés que c'est possible (mêmes identifiants d'application). Si :
    restreindre_extras('article', 'c1', array(1, 2));
    restreindre_extras('article', 'c2', array(1, 2));
    // Préférer :
    restreindre_extras('article', array('c1', 'c2'), array(1, 2));

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 :

// seuls les rédacteurs et admins peuvent voir
function autoriser_auteur_voirextra_prenom_dist($faire, $type, $id, $qui, $opt) {
    return in_array($qui['statut'], array('0minirezo', '1comite'));
}
// seuls les admins peuvent modifier
function autoriser_auteur_modifierextra_prenom_dist($faire, $type, $id, $qui, $opt) {
    return in_array($qui['statut'], array('0minirezo'));
}

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 :

/* AUTORISATIONS */
function grainepc_objet_est_carto($objet, $id) {
	$compo = compositions_determiner($objet, $id);
	return ($compo == 'carte');
}

// autorisations des champs extras de carte ...
foreach (array(
	'declinaison',
	'structure',
	'affichage',
	'date_creation',
	'coordonnees',
	'presentation',
	'infos') as $nom)
{
	$m = "autoriser_article_modifierextra_" . $nom . "_dist";
	$v = "autoriser_article_voirextra_" . $nom . "_dist";

	$code = "
		if (!function_exists('$m')) {
			function $m(\$faire, \$type, \$id, \$qui, \$opt) {
				return grainepc_objet_est_carto(\$type, \$id);
			}
		}
		if (!function_exists('$v')) {
			function $v(\$faire, \$type, \$id, \$qui, \$opt) {
				return grainepc_objet_est_carto(\$type, \$id);
			}
		}
	";

	# var_dump($code);
	eval($code);
}

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 :

<paquet 
		prefix="titrecourt"
		categorie="outil"
		version="1.1.0"
		etat="stable"
		compatibilite="[3.0.0-beta;["
		logo=""
		schema="0.0.1"
>
	<nom>Titre Court pour Rubriques</nom>

	<auteur>Matthieu Marcillaud [->magraine.net]</auteur>
	<licence>GNU/GPL</licence>

	<necessite nom="cextras" compatibilite="[3.0.5;[" />

	<pipeline nom="declarer_champs_extras" inclure="base/titrecourt.php" />
</paquet>

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 :

<?php
if (!defined("_ECRIRE_INC_VERSION")) return;

function titrecourt_declarer_champs_extras($champs = array()) {
  $champs['spip_rubriques']['titre_court'] = array(
      'saisie' => 'input',//Type du champ (voir plugin Saisies)
      'options' => array(
            'nom' => 'titre_court', 
            'label' => _T('titrecourt:titre_court'), 
            'sql' => "varchar(30) NOT NULL DEFAULT ''",
            'defaut' => '',// Valeur par défaut
            'restrictions'=>array('voir' => array('auteur' => ''),//Tout le monde peut voir
                        'modifier' => array('auteur' => 'webmestre')),//Seuls les webmestres peuvent modifier
      ),
  );
  return $champs;	
}
?>

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 6 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 !)
    • ’voir’ => false // personne peut voir
    • ’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’.
  • « traitements », traitements typographiques à appliquer, soit une constante prédéfinie, soit un chaîne décrivant les fonctions à appliquer. Lire la documentation sur Programmer avec SPIP.

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 :

<?php
if (!defined("_ECRIRE_INC_VERSION")) return;

include_spip('inc/cextras');
include_spip('base/titrecourt');
	
function titrecourt_upgrade($nom_meta_base_version,$version_cible) {

  $maj = array();
  cextras_api_upgrade(titrecourt_declarer_champs_extras(), $maj['create']);	

  include_spip('base/upgrade');
  maj_plugin($nom_meta_base_version, $version_cible, $maj);

}

function titrecourt_vider_tables($nom_meta_base_version) {
  cextras_api_vider_tables(titrecourt_declarer_champs_extras());
  effacer_meta($nom_meta_base_version);
}
?>

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).

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

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

<?php

if (!defined("_ECRIRE_INC_VERSION")) return;

function grainepc_declarer_champs_extras($champs = array()){
    $champs['spip_auteurs']['telephone'] = array(
        'saisie' => 'input', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'telephone', 
            'label' => _T('grainepc:info_telephone'), 
            'sql' => "varchar(30) NOT NULL DEFAULT ''",
            'defaut' => '',// Valeur par défaut
        ));

    $champs['spip_articles']['declinaison'] = array(
        'saisie' => 'input', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'declinaison', 
            'label' => _T('grainepc:info_declinaison'), 
            'sql' => "text DEFAULT '' NOT NULL",
            'defaut' => '',// Valeur par défaut
            'traitements' => '_TRAITEMENT_TYPO',
        ));

    $champs['spip_articles']['structure'] = array(
        'saisie' => 'radio', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'structure', 
            'label' => _T('grainepc:info_type_structure'), 
            'sql' => "varchar(30) NOT NULL DEFAULT ''",
            'defaut' => '',// Valeur par défaut
            'datas' => array(
                '' =>  _T('grainepc:info_rien'), 
                'structure' =>  _T('grainepc:info_structure'), 
                'structure_adherente' =>  _T('grainepc:info_structure_adherente'), 
            ),
        ));


    $champs['spip_articles']['affichage'] = array(
        'saisie' => 'radio', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'affichage', 
            'label' => _T('grainepc:info_affichage'), 
            'sql' => "varchar(30) NOT NULL DEFAULT 'complet'",
            'defaut' => 'complet',// Valeur par défaut
            'datas' => array(
                'complet' =>  _T('grainepc:info_complet'), 
                'reduit' =>  _T('grainepc:info_reduit'), 
            ),
        ));
        
    $champs['spip_articles']['date_creation'] = array(
        'saisie' => 'date', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'date_creation', 
            'label' => _T('grainepc:info_date_creation'), 
            'sql' => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
            'defaut' => '0000-00-00 00:00:00',// Valeur par défaut
        ),
        'verifier' => array(
            'type' => 'date',
            'options' => array(
                'normaliser' => 'datetime',
            )
        ));

    $champs['spip_articles']['coordonnees'] = array(
        'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'coordonnees', 
            'label' => _T('grainepc:info_coordonnees'), 
            'sql' => "text DEFAULT '' NOT NULL",
            'defaut' => '',// Valeur par défaut
            'rows' => 4,
            'traitements' => '_TRAITEMENT_RACCOURCIS',
        ));

    $champs['spip_articles']['presentation'] = array(
        'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'presentation', 
            'label' => _T('grainepc:info_presentation'), 
            'sql' => "text DEFAULT '' NOT NULL",
            'defaut' => '',// Valeur par défaut
            'rows' => 6,
            'traitements' => '_TRAITEMENT_RACCOURCIS',
        ));

    $champs['spip_articles']['infos'] = array(
        'saisie' => 'textarea', // Type du champs (voir plugin Saisies)
        'options' => array(
            'nom' => 'infos', 
            'label' => _T('grainepc:info_infos'), 
            'sql' => "text DEFAULT '' NOT NULL",
            'defaut' => '',// Valeur par défaut
            'rows' => 5,
            'traitements' => '_TRAITEMENT_RACCOURCIS',
        ));
        
    return $champs;    
}

?>

Installation

<?php

include_spip('inc/cextras');
include_spip('base/grainepc');

function grainepc_upgrade($nom_meta_base_version,$version_cible){
	$maj = array();

	cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['create']);
	cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.1.0']);
	cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.2.0']);
	$maj['1.2.0'][] = array('sql_alter',"TABLE spip_auteurs DROP type");
	cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.3.0']);
	
	include_spip('base/upgrade');
	maj_plugin($nom_meta_base_version, $version_cible, $maj);
}

function grainepc_vider_tables($nom_meta_base_version) {
	cextras_api_vider_tables(grainepc_declarer_champs_extras());
	effacer_meta($nom_meta_base_version);
}

?>

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

<?php

if (!defined("_ECRIRE_INC_VERSION")) return;

function numadresse_declarer_champs_extras($champs = array()){

    $champs['spip_auteurs']['numeros'] = array(
        'saisie' => 'fieldset',//Type du champ (voir plugin Saisies)
        'options' => array(
            'nom' => "numeros",
            'label' => _T('numadresse:legend_numeros')
        ),
        'saisies' => array(
            'telephone' => array(
                'saisie' => 'input', // Type du champs (voir plugin Saisies)
                'options' => array(
                    'nom' => 'telephone', 
                    'label' => _T('numadresse:info_telephone'), 
                    'sql' => "varchar(30) NOT NULL DEFAULT ''",
                    'defaut' => '',// Valeur par défaut
                )),
            'fax' => array(
                'saisie' => 'input', // Type du champs (voir plugin Saisies)
                'options' => array(
                    'nom' => 'fax', 
                    'label' => _T('numadresse:info_fax'), 
                    'sql' => "varchar(30) NOT NULL DEFAULT ''",
                    'defaut' => '',// Valeur par défaut
                ))
        )
    );
    $champs['spip_auteurs']['adresse'] = array(
        'saisie' => 'fieldset',//Type du champ (voir plugin Saisies)
        'options' => array(
            'nom' => "adresse",
            'label' => _T('numadresse:legend_adresse')        
        ),
        'saisies' => array(
            'adresse' => array(
                'saisie' => 'input', // Type du champs (voir plugin Saisies)
                'options' => array(
                    'nom' => 'adresse', 
                    'label' => _T('numadresse:info_adresse'), 
                    'sql' => "text NOT NULL DEFAULT ''",
                    'defaut' => '',// Valeur par défaut
                )),
            'code_postal' => array(
                'saisie' => 'input', // Type du champs (voir plugin Saisies)
                'options' => array(
                    'nom' => 'code_postal', 
                    'label' => _T('numadresse:info_code_postal'), 
                    'sql' => "varchar(30) NOT NULL DEFAULT ''",
                    'defaut' => '',// Valeur par défaut
                ))
        )
    );

    return $champs;
}

?>

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.

Discussion

35 discussions

  • 1

    Je voudrais restreindre l’affichage de certains champs extra auteur sur le site public.

    Dans l’interface champ extras je les ai mis comme

     Voir la saisie
    Par auteur
    Tout le monde peut
    Seulement les administrateurs (même restreints)

    mais cela ne change rien à l’affichage (tout le monde voit tout)

    Donc en farfouillant je tombe sur cette page pour l’API.

    J’ai mis dans mes_options.html comme dans l’exemple ici https://contrib.spip.net/local/cache-code/a8d12f430d8b77f0ee35717f5ca1dc6c.txt :

    <?php
    // seuls les redacteurs et admins peuvent voir
    function autoriser_auteur_voirextra_inscrit_tel() {
        return in_array($qui['statut'], array('0minirezo', '1comite'));
    }
    ?>

    idem : aucune restriction n’est appliquée.

    Est-ce que cela devrait suffire ou bien il faut aussi créer d’autres fichiers d’autorisations ?

    Merci

    • Un point qu’il faudrait souligner dans la doc pour les distrait⋅e⋅s je pense : au sein d’une même mise à jour, quand on veut à la fois ajouter des champs extras mais aussi faire d’autres trucs, il faut faire attention à pas écraser $maj.

      Exemple, ça c’est ok :

      // Maj 1.0.2
      cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.2.0']);
      $maj['1.2.0'][] = array('sql_alter',"TABLE spip_auteurs DROP type");

      Mais par contre là c’est le drame :

      // Maj 1.0.2
      cextras_api_upgrade(grainepc_declarer_champs_extras(), $maj['1.2.0']);
      $maj['1.2.0'] = array(array('sql_alter',"TABLE spip_auteurs DROP type"));

      On a bien un exemple dans un des extrait de code, mais c’est un peu noyé parmi le reste, il faudrait mieux expliciter amha.

    Répondre à ce message

  • 2

    bonjour,
    j’ai rajouté des champs extra a la table selections de selections_editoriales. Mais je rencontre un problème.
    Dans le plugin, le champ CSS est en input, ce qui est bien sur générique, mais j’ai besoin de changer cette saisie en checkbox ou liste ... est-ce possible pour un champ EXISTANT ?
    merci

    • si ce n’est pas possible ce n’est pas grave ... je rajouterai un champ

    • si tu l’a fait en PHP : oui tu modifie juste ta declaration. Si tu l’a fait via l’interface graphique : oui il y a dans un onglet une option pour modifier le champ.

    Répondre à ce message

  • 4

    Bonjour,

    En passant de la version 3.12.4 à 3.13.2 du plugin Champ extra core, je découvre que l’option Traitements de l’un de mes champs extra n’est plus appliquée quand on est dans une boucle HIERARCHIE (champ TITRE_COURT sur une rubrique avec ’traitements’ => ’_TRAITEMENT_TYPO_SANS_NUMERO’,) !

    Le problème est réglé si je retire la fonction table_objet() à la ligne 152 $interfaces[’table_des_traitements’][$balise][table_objet($table)] = $traitement ; dans le fichier base/cextras.php du plugin (ajoutée par ce commit https://git.spip.net/spip-contrib-extensions/champs_extras_core/commit/22907b66645db1af1c9f2ec8fd0ef90dde7e9df4).

    Cette fonction table_objet() ne devrait-elle pas être retirée comme indiqué dans une note à la ligne 24 du fichier ?

    • Hum, oui. Alors c’est moi qui avais mis ce code. Mais il y avait une bonne raison tout de même. Donc il faut qu’on voit si depuis, les commits fait par marcimat on résolu autrement le problème que résolvait le commit problématique.

    • je viens de confirmer que mon code avait bien une bonne raison d’existe : #INFO_XXX. Mais du coup oui ca plante hierarchie si on appel directement la balise. Arg. On essaioe de comprendre avec Marcimat.

    • Après discussion avec Marcimat, le bug se situait plutôt dans SPIP. C’est corrigé via ce commit https://git.spip.net/spip/spip/commit/bdc53dcc.

      Tu peux je pense sans autre l’appliquer à ta propre installe de spip 3.2, puisqu’il se inclus dans la prochaine release.

    • Problème résolu ! Merci pour la rapidité et l’efficacité !

    Répondre à ce message

  • 1

    « traitements », traitements typographiques à appliquer, soit une constante prédéfinie, soit un chaîne décrivant les fonctions à appliquer. Lire la documentation sur Programmer avec SPIP.

    Je ne sais pas quelle serait la meilleure formulation, mais on me dit dans l’oreillette que c’est pas vraiment ça : dans cette clé on ne doit donc pas mettre une constante mais le nom d’une constante dans une chaine, ce qui n’est pas du tout la même chose. :)

    Mais du coup si dans les deux cas on met une chaine, comment ça sait que dans tel cas faut chercher la valeur du nom de constante demandé ou si c’est une suite de fonctions avec %s ?

    Répondre à ce message

  • 3

    Tentative de mise-à-jour ce matin sur plusieurs sites à chaque fois les même messages


    La mise à jour du plugin « Champs Extras » (de la version : 3.12.4 à 3.12.6) ne s’est pas correctement déroulée

    Chargement impossible de la source https://files.spip.org/spip-zone/spip-contrib-extensions/champs_extras_core-08395-3.12.6.{zip

    L’url est en objet non trouvé

    • visiblement un bug dans le debardeur. Malheureusement la plateforme de dev est en panne en ce moment.

      Je te tiens au courant dès qu’on y voit plus clair.

    • Peux tu reessayer après avoir executé la tache « svp_actualiser_depots » dans « Maintenance->liste des travaux » ?

    • C’est bon, ça marche !

      Merci

    Répondre à ce message

  • 6
    thierry

    Bonjour,
    suite à un upgrade 3.1.6 => 3.2.4, j’ai remis à jour les plugins. Et je viens de constater que la saisie de l’heure dans un champ datetime n’était plus effectuée correctement dans l’espace privé.
    La date est bien enregistrée mais l’heure reste toujours 00:00:00 après l’enregistrement de la modification.
    Plugins : 3.5.8 + champ extras 3.12.1, saisies 3.23.3, verifier 1.9.4, yaml 1.5.3 ou 2.0.10, bonux 3.4.6, palette 4.0.7
    _

    • thierry

      Après désactivation des nouveaux plugins et réactivation des anciens, l’erreur se trouve dans verifier 1.9.4 (en comparaison avec verifier 1.6.5 qui fonctionne correctement).

    • Hello, c’est bien enregistré ou c’est pas bien enregistré ? Est-ce que dans la base de données, dans le champ SQL, ya bien l’heure ? Car vérifier ne touche pas à l’affichage, tant qu’on n’a pas validé, du coup si c’est correct dans la base, au premier affichage ça devrait le mettre.

    • thierry

      Ce n’est pas une question d’enregistrement. Avec 1.9.4, 18:00:00 à l’affichage devient 00:00:00 quand j’enregistre, mais avec 1.6.5 mon 18:00:00 est bien enregistré dans la base en 18:00:00 dans ma zone datetime.
      Dans la partie édition, avant de cliquer sur « enregistrer », j’ai bien une heure visible.
      J’ai l’impression que vérifier force 00 dans heure, est-ce que ça ne pourrait pas venir de valeur_normalisee ? Dans vérifier on a un forçage $options[’heure’] = ’00:00’ ;. Je ne vois pas pourquoi cette ligne serait appelée mais il est possible de changer un 18 en 00 dans vérifier.

    • thierry

      Je viens de relire mon premier message et ce n’est pas vraiment clair.
      Je voulais dire que si je met 11/09/2019 18:00:00, le système enregistre dans la DB 2019-09-11 00:00:00, donc la date est bien enregistrée mais pas l’heure. De même, je peux changer la date et ça s’enregistre correctement dans la DB, mais l’heure reste 00.

    • Merci, c’est corrigé dans la 1.9.5 !

    • thierry

      Impec, merci.
      Note que le no de version du lien est toujours 1.9.4 dans contrib.spip.net.

    Répondre à ce message

  • Bonjour,
    Depuis la dernière mise à jour du plugin (v3.12.0), les champs masqués par l’affichage conditionnel (en fonction de la valeur d’autres champs extras) posent problème (voir capture en pièce jointe). Dans mon cas, certains champs ne doivent être remplis uniquement en fonction de la valeur d’un autre champ. Par exemple : @affichage@ IN « Focus,Flash,Trajectoire,Slider,WebTV »
    J’ai pourtant bien une valeur par défaut et jusqu’alors ça fonctionnait très bien. Après recherches, il s’avère que ce sont les lignes 279 et 280 du fichier cextras_pipelines.php qui posent problème.

    Répondre à ce message

  • Bonjour,
    J’ai mis en place des champs extras dans un plugin. Ces champs sont bien prise en compte dans l’objet associé, mais par contre ils n’apparaissent pas dans l’interface des champs extras, hors je voudrais que le webmaster puisse ajouter/modifier ces champs extras.
    qu’est ce que j’ai loupé dans la création ?

    Répondre à ce message

  • 2

    Je voudrais empêcher l’affichage de certains champs extras auteur sur le site public.

    J’ai donc coché dans l’interface champ extra :

        Restriction
        Technique
    Voir la saisie
    Par auteur
    Tout le monde peut
    Seulement les administrateurs (même restreints) 

    mais cela ne restreint rien.

    donc dans mes_options.html j’ai ajouté comme dit dans cet article

    <?php
    // seuls les redacteurs et admins peuvent voir
    function autoriser_auteur_voirextra_inscrit_tel() {
        return in_array($qui['statut'], array('0minirezo', '1comite'));
    }
    ?>

    idem : tout s’affiche

    est-ce que cela devrait fonctionner ou bien il faut ajouter d’autres fichiers d’autorisation quelque part ?

    Merci

    • Ah oui, mais il maque les paramètres de la fonction !
      Je vais aussi les ajouter dans l’exemple !

      // seuls les redacteurs et admins peuvent voir
      function autoriser_auteur_voirextra_inscrit_tel($faire, $type, $id, $qui, $opt) {
          return in_array($qui['statut'], array('0minirezo', '1comite'));
      }

      Cela étant dit… lorsque tu dis « sur le site public »… ces autorisations ne sont pas concernées.
      Elles ne sont testées que sur l’espace privé par le plugin champs extras.

      Pour ajouter des autorisations dans l’espace public (dans tes squelettes donc), tu peux soit appeler l’autorisation toi-même, soit définir ce que tu souhaites :

      [(#AUTORISER{voirextra, auteur, '', '', #ARRAY{champ,inscrit_tel}}|oui)
          #INSCRIT_TEL
      ]
      
      ou
      [(#AUTORISER{ecrire}|oui) 
          ... je peux accéder à l’espace privé ... 
      ]
      
      ou faire ta propre autorisation
      [(#AUTORISER{voir, _champs_admins}|oui) 
          ... avec la fonction autoriser_champsadmins_voir_dist($faire, $type, $id, $qui, $opt)...
      ]
    • J’y reviens..

      Les modèles du plugin réservation événements ont changé et tous les champs extras sont maintenant récupérés par :

      <BOUCLE_champs_extras2(DATA){source tableau,#GET{valeurs_extras}}>
      #SET{valeurs_extras,#ARRAY}
       [(#VALEUR)]
      </BOUCLE_champs_extras2>

      donc je crois que si je veux appliquer une restriction sur un seul champ il faut « exploser » la boucle DATA

    Répondre à ce message

  • Bonjour

    Très utile et bon plug-in ! Avec l’aide de ce plugin, j’ai créé des champs externes supplémentaires dans l’en-tête des produits.
    Dans les champs supplémentaires, les données saisies sont visibles dans la partie administrative, mais le site s’affiche sous forme de texte non formaté. En outre, le plug-in Albums 3 dans la partie administrative est visible, mais le site n’est pas visible. Dis-moi, s’il te plaît, quoi et où le réparer. Merci
    Je m’excuse pour ma mauvaise langue.

    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