Comme il est bien indiqué dans cet article , il est possible d’ajouter des champs dans les tables Spip depuis la version 1.8. Ceci permet de remplacer les champs extras, mais pas vraiment. En effet les champs extras ont l’avantage de pouvoir être entrés directement dans la partie privée lors de l’édition de la table correspondante, ce qui n’était pas le cas des champs ajoutés.
Ayant eu besoin d’ajouter des champs dans la table articles pour un site en préparation, il m’a été nécessaire de me pencher sur ce sujet - uniquement pour la table articles. Ci-dessous sont proposées des fichiers modifiés pour gérer les champs ajoutés directement lors de l’édition des articles. Les modifications proposées essayent de respecter le mode de fonctionnement de SPIP.
Le principe est d’utiliser un fichier descriptif des champs ajoutés pour que l’affichage se fasse en relation avec ce qu’il faut y entrer.
Les modifications sont là :
Pour la V1.8.3 :
et pour la V1.9 beta2 au 03/06/06 :
Voici un exemple de fichier de configuration, que je vais décrire plus loin.
<?php
$GLOBALS['champs_site'] = Array (
'articles' => Array (
'inedit' => Array(
'champ' => 'inedit',
'titre' => 'Inédit ?',
'style' => Array( 'couleur' => '#FF0000' ),
'secteur' => 1,
'type' => 'choix',
'multiple' => 'non',
'modele' => 'texte',
'valeurs' => Array (
'Oui' => 'Inédit',
'Non' => 'Réédition'
)
),
'isbn' => Array(
'champ' => 'isbn',
'titre' => 'Num.ISBN',
'style' => Array(),
'secteur' => 1,
'type' => 'texte',
'taille' => 20,
'modele' => 'texte'
),
'essaicheck' => Array(
'champ' => 'essaicheck',
'titre' => 'Essai check',
'style' => Array(
'aligne' => 'horizontal',
'couleur' => '#0088CC'
),
'secteur' => 1,
'type' => 'choix',
'multiple' => 'oui',
'modele' => 'texte',
'valeurs' => Array (
'Oui' => 'Oui',
'Non' => 'Non',
'Ptèt' => 'Bof'
)
),
'project' => Array(
'champ' => 'project',
'titre' => 'Project',
'style' => Array(),
'secteur' => 1,
'type' => 'table',
'table' => 'site_proj',
'colonne' => 'name',
'valeur' => 'prjid',
'multiple' => 'non',
'modele' => 'entier'
),
)
);
?>
Chaque champ est décrit avec certains éléments communs obligatoires :
- ’champ’ pour indiquer le nom de la colonne dans la table
- ’titre’ pour donner un nom au chmp pour l’utilisateur
- ’style’ pour éventuellement modifier l’aspect typographique
- ’secteur’ pour indiquer dans quel secteur ce champ est utilisable (un seul secteur par champ pour l’instant)
- ’type’ indique le type de représentation souhaitée, qui peut être ’choix’ (un choix dans une liste figée), ’texte’ (entrée simple) ou ’table’ (choix à partir d’une table externe)
Un champ optionnel ’modele’ => ’texte’ pour indiquer que le champ est de type texte dans la base (sinon le champ est considéré comme un nombre).
Ensuite, selon le type de champ, d’autres éléments viennent le préciser.
Pour les champs de type ’texte’, la taille doit être fournie (longueur du champ)
Pour les choix, il faut indiquer s’ils sont ’multiple’ ou simple, ainsi que la liste des valeurs et de ce qui doit être affiché pour chaque valeur.
Pour les tables externes, il faut indiquer le nom de la ’table’, la ’colonne’ à afficher ainsi que la colonne contenant la ’valeur’ à mettre dans le champ. On peut aussi avoir des choix multiples.
Ceci peut donner en édition :
et en visualisation (dans l’espace privé) :
Discussions par date d’activité
9 discussions
J’ai essayé d’installer cette contrib sur une install SPIP 1.9.2 et ça ne fonctionne pas.
« call to undefined function acces_rubrique()... » dans les scripts ecrire/exec/articles.php et ecrire/exec/articles_edit.php
Quelqu’un peut m’aider SVP ???
Merci
Je ne sais pas si tu as trouvé une solution ? Pour ma part, j’ai réussi à résoudre ce problème (la solution est donnée ici : http://forum.spip.org/fr_197801.html), mais je tombe ensuite sur un nouveau message d’erreur :
undefined function bouton_imessage()
Une fois le code coupable mis en commentaire, nouveau message d’erreur :
undefined function formulaire_mots()
Je laisse donc tomber temporairement, le code de cette contribution est sans doute un peu obsolète du fait des nouvelles versions de SPIP (1.9.2c, pour ma part).
Cette contribution me tente bien, mais je me demande s’il n’y a pas plus simple, en passant par un plugin ?
En fait, ce n’est pas comme cela que j’ai porté sur les autres versions mes modifications.
Le mieux est de prendre le code des fichiers à remplacer et de l’éditer pour y intégrer les changements - ainsi on profite des ajouts de la nouvelle version de Spip.
Mais pour faire cela, il faut disposer à la fois des sources de la version d’avant (1.9.1), des sources correspondant modifiés - pour voir où sont les différences - et du nouveau code pour effectuer les changements.
Pour ma part, j’attends la finalisation de la 1.9.3 pour porter mes modifications. La 1.9.2 c’est trop compliqué avec toutes ces sous-versions.
Et oui, ce serait mieux dans un plugin mais je n’ai pas vu comment insérer du code HTML au milieu de celui de Spip, seulement comment en ajouter à certains endroits (et pas où je le veux)
Bonjour,
Il suffit de remplacer la fonction acces_rubrique() par acces_restreint_rubrique() dans le code php, dans le style /var/www/spip/plugins/saisie_user/exec/naviguer.php
J’ai le même problème avec formulaire_mots() mais je ne sais pas par quoi le remplacer ...
En fait, j’ai fait le plugin, finalement, pour Spip 2.0.
Répondre à ce message
Bonjour comment faire pour le modifier pour qu’il fonctionne avec plusieurs rubrique, voici mon code :
function exec_articles_edit_champs_ajoutes($id_rubrique, $pchamp)
//============================================================================
// gestion des champs ajout�s
//Possibilité de choisir par rubrique et non plus par secteur.
//MODIFER PAR LOïC (C-Stan) LE 24/09/07
$txt = « » ;
foreach ($GLOBALS[’champs_site’][’articles’] as $keychamp => $pluschamp)
$tableausecteurs=array() ;
$tableausecteurs=explode(" « ,$pluschamp[’secteur’]) ;
foreach ($tableausecteurs as $valsecteur)
if ($valsecteur == $id_rubrique)
$pretxt = »" ;
$posttxt = « » ;
if ((isset($pluschamp[’style’]))&&(isset($pluschamp[’style’][’couleur’])))
$pretxt .= « » ;
$posttxt = « ».$posttxt ;
$txt .= $pretxt ;
//-------------------------------------------------------
// champ de type texte
if ( !strcmp($pluschamp[’type’],’texte’))
$txt .= « ».$pluschamp[’titre’]."" ;
$txt .= «
» ;
//-------------------------------------------------------
// champ de type choix pr�d�fini
elseif ( !strcmp($pluschamp[’type’],’choix’))
$brtxt = «
» ;
$pbrtxt = «
» ;
if ((isset($pluschamp[’style’]))&&(isset($pluschamp[’style’][’aligne’])) &&
(!strcmp($pluschamp[’style’][’aligne’],« horizontal »))
)
$brtxt = « » ;
$pbrtxt = «
» ;
$txt .= « ».$pluschamp[’titre’]."" ;
$txt .= « $brtxt » ;
if ( strcmp($pluschamp[’multiple’],’non’))
$inptxt = « type=’checkbox’ name=’ ».$keychamp.« []’ » ;
$vals = split(« , »,$pchamp[$keychamp]) ;
else
$inptxt = « type=’radio’ name=’$keychamp’ » ;
$vals = array() ;
$vals[] = $pchamp[$keychamp] ;
foreach ($pluschamp[’valeurs’] as $keyval => $plusval)
if (in_array($plusval,$vals))
$txt .= « $keyval ».« $brtxt » ;
else
$txt .= « $keyval ».« $brtxt » ;
$txt .= $pbrtxt ;
//-------------------------------------------------------
// champ de type choix � partir d’une table externe’
elseif ( !strcmp($pluschamp[’type’],’table’))
$txt .= « ».$pluschamp[’titre’]."
" ;
$query = « SELECT ».$pluschamp[’colonne’] ;
if (isset($pluschamp[’valeur’]))
$query .= « , ».$pluschamp[’valeur’] ;
$query .= « FROM ».$pluschamp[’table’] ;
$result = spip_query($query) ;
if ( !strcmp($pluschamp[’multiple’],’non’))
$txt .= « ;
$vals =Array() ;
$vals[] = $pchamp[$keychamp] ;
else
$txt .= « ;
$vals = split(« , »,$pchamp[$keychamp]) ;
while ($row = spip_fetch_array($result))
$v = « » ;
$edval = $row[$pluschamp[’colonne’]] ;
if (isset($pluschamp[’valeur’]))
$v = « value=’ ».$row[$pluschamp[’valeur’]].« ’ » ;
$edval = $row[$pluschamp[’valeur’]] ;
if (in_array($edval,$vals))
$txt .= « ».$row[$pluschamp[’colonne’]]."" ;
else
$txt .= « ».$row[$pluschamp[’colonne’]]."" ;
$txt .= «
» ;
$txt .= $posttxt ;
else
$txt .= « » ;
$txt .= «
» ;
return $txt ;
Ce code fonctionne mais pas avec toute mes rubrique en locurence j’ecrit « 4 5 », la 5 marche mais pas la 4. c toujours la derniere qui fonctionne. pk ? Merci
Pour obtenir le résultat attendu, j’ai modifié le fichier « articles_edit.php » en remplaçant la ligne :
if ($pluschamp[’secteur’] == $id_secteur)
de la gestion des champs ajoutés (vers la ligne 354 - dépend de la version de l’add-on) par
// recherche des secteurs concernés
$concern = false ;
$vs = split(’ ’,$pluschamp[’secteur’]) ;
foreach ($vs as $v)
{
if ($v == $id_secteur)
$concern = true ;
}
//if ($pluschamp[’secteur’] == $id_secteur)
if ($concern)
Dans mes_champs.php, il faut indiquer les secteurs multiples entre quotes :
’secteur’ => ’1 27’,
Répondre à ce message
J’ai essayé de gérer pour un site multilingue des balises multi dans les champs supplémentaires, mais cela ne marche pas dans le site public comme pour les autres champs. J’obtiens le champ en entier avec les mutli (texte en français) et non pas juste le texte correspondant à la langue courante.
Y’a t’il un moyen de gérer les balises multi avec cette méthode ?
Merci de votre aide.
Je n’ai rien prévu de particulier pour le multilingue...
As-tu bien renseigné tes colonnes dans le fichier base/serial.php ?
Sous spip 1.9 j’ai déclaré le nouveau champ dans le fichier mes_fonctions.php que j’ai mis dans le répertoire des squelettes.
J’ai inscrit le champ dans le fichier base/serial.php mais cela ne fonctionne toujours pas. Le champ affiche des ... et ne semble pas passer par le filtre de la langue comme les autres champs...
Il m’est difficile de t’aider, j’en suis désolé.
Je ne connais pas le fonctionnement du multilingue (le site pour lequel je fais cette contrib est seulement en français).
En plus ma version - qu’il faut que je mette à dispo, d’ailleurs - est très loin de celle qui est disponible ici, donc je n’ai plus vraiment le même code.
Il serait peut-être possible de trouver une explication en regardant et comparant le contenu des champs dans la base elle-même. Mais il nous faudrait quelqu’un connaissant le fonctionnement du multilingue...
Merci pour la réponse. Dans la BD tout est ok, l’écriture avec les balises mutli est correct.
Pour les champs existants (surtitre, titre, etc...) utilisant les balises mutli, le site public me met bien uniquement le texte de la langue courante, par contre pour les nouveaux champs déclarés tout le contenu du champ s’affiche, par exemple pour #TEST j’obtiens tout son contenu cad : « Test en français » alors que le site ne devrait m’afficher uniquement « Test en français ».
Je testerai la contrib des champs homonymes dans laquelle on parle de l’utilisation possible des champs multi, mais le résultat devrait être identique au vu de la contrib... Je vous tiens au courant.
Résultat identique avec la contrib des champs homonymes. Sur le site public mes nouveaux champs créés s’affichent entièrement avec les <multi> !
Pourtant je ne vois pas pourquoi cela ne se passe pas pareil que les autres champs ou spip n’affiche que le texte du multi restreint à la langue courante.
Il suffit d’utiliser le filtre « propre » avec ton champ pour n’afficher que le contenu concernant la langue concernée.
Exemple : pour un champ qui vaut oui, (#MONCHAMPS affichera « yes » si lang=en et « oui » pour lang=fr.
En revanche, si dans ton squelette tu utilises [(#MONCHAMPS)], Spip affichera « [en] yes [fr] oui ».
Répondre à ce message
Bonjour,
Merci pour ette contrib qui m’est très utile. avec Spip 1.8.3
J’ai cependant un petit souci...
Comment faire pour que les champs mêmes vides s’affichent, que ce soit en MODIFICATION ou CONSULTATION d’article dans l’espace privé de Spip ?
C’est gênant de ne pas pouvoir avoir les champs vides.. des fois j,aimerais bien remplir un de ces champs avec de l’info qu’un internaute a mis à la mauvaise place.
Le fait de cacher les champs vides en consultation est fait exprés. Par contre ils devraient apparaître en modification.
Pour la consultation, il y a juste une ligne de source à modifier (justement un test si le champ est vide) mais je ne sais plus trop où dans la version pour la 1.8.3 ...
Merci pour la réponse,
Je confirme l’absence des champs vides en CONSULTATION, ce que je comprends
MAIS aussi en MODIFICATION ce qui est malheureux.
Je vais voir si je peux modifier le code.... aie aie aie
Finalement je ne trouve pas le code à modifier pour faire en sorte que TOUS LES CHAMPS SOIENT DISPONIBLES en MODIFICATION...
J’ai cherché dans :
- mes_champs.php
- articles.php3
- articles_edit.php3
Niet, que dalle...
zauriez pas une indice à me donner pour que je puisse trouver ce fameux code à modifier ?
Merci d’avance
Un autre point à regarder :
La contrib permet de n’afficher/modifier certains champs que pour des secteurs donnés. C’est peut-être de là que vient le problème ?
Que veux-tu dire par SECTEUR, veux-tu dire RUBRIQUE ?
En tout cas, jusqu’ici le comportement de la contrib est le même quelle que soit la RUBRIQUE mais je n’ai pas d’ARTICLES dans les SECTEURS, seulement dans des SOUS_RUBRIQUES.
A part ça, ce sont toutes des colonnes supplémentaires dans la table ARTICLES et lorsque les champs ont déjà de l’information entrée par l’internaute je peux les modifier.
Tous les champs, s’ils contenaient déjà de l’information peuvent être modifiés mais SI ET SEULEMENT SI car sinon je ne les vois pas en modification.
Merci A+
Un SECTEUR est une RUBRIQUE située à la racine du site.
Dans « mes_champs.php », pour chaque champ il est possible d’indiquer :
’secteur’ => 1,
(Ou ’secteur’ => xxx, ), ce qui a pour effet de limiter la possibilité d’édition de ce champ aux sous-rubriques du secteur xxx indiqué. Dans ce cas, le champ ne sera pas éditable dans un autre secteur, mais - ce fut mon choix - je l’ai laissé visible s’il possède une valeur (ça a dû me paraître intelligent à l’époque... ). On ne pourra l’entrer que pour les sous-rubriques de la rubrique xxx située à la racine.
Voilà, c’était ça... le # de secteur... je me demandais justement à quoi servait ce champs !
Cela commence à ressembler à la contrib géniale. Mille mercis, vraiment.
Une dernière question, j’ai ajouté un champ que j’aimerais pouvoir afficher en modification en TEXTAREA avec plusieurs lignes donc. C’est faisable ?
Merci encore
Nicolas
Ce n’est pas prévu - je n’en ai pas eu besoin.
Toutefois j’ai actuellement une version plus élaborée (avec des listes venant de tables externes par cross-reference, en particulier) dans laquelle il doit être possible d’ajouter des TextArea - mais elle n’existe que pour SPIP 1.9.1.
Cela semble intéressant cette version pour 1.9.1 (ou plus...)
Serait-il possible de l’avoir ?
Merci d’avance
Bon, ok, la voila : http://www.alantea.net/downloads/ecrire-spip-1.9.1.zip
Mais je n’ai pas trouvé le temps de la documenter, ce qui peut poser problème.
J’ai ajouté :
- le type « calendrier » pour choisir des dates
- le type « cross2 » permettant de placer des références à des tables par tables de liens à trois colonnes (dans l’exemple il s’agit pour un livre d’avoir l’auteur et sa fonction)
- la possibilité d’ajouter des valeurs dans une table externe liée.
A regarder : l’exemple de fichiers « mes_champs.php »
Répondre à ce message
Merci pour cette contrib qui me serait très utile mais sauf erreur de ma part elle ne semble pas fonctionner avec la version 1.9 actuelle (01/07/06) en mode local avec easyphp 1.8.
Les nouveaux champs apparaissent bien dans l’article mais rien ne s’affiche dans le cadre « champs ajoutés » après l’enregistrement des valeurs et pour cause, les données ne sont pas sauvegardées dans la base ?
Quoi faire pour y remédier ?
Merci pour votre aide.
peut-être inscrire le(s) champ(s) en question dans phpadmin ...
Bonjour,
Serait-il possible de savoir comment exactement installer cette contrib sur une 1.9.2 ?
Merci d’avance
Répondre à ce message
Bonjour,
Merci pour ette contrib qui m’est très utile. avec Spip 1.8.3
J’ai cependant un petit souci...
Comment faire pour que les champs mêmes vides s’affichent, que ce soit en MODIFICATION ou CONSULTATION d’article dans l’espace privé de Spip ?
C’est gênant de ne pas pouvoir avoir les champs vides.. des fois j,aimerais bien remplir un de ces champs avec de l’info qu’un internaute a mis à la mauvaise place.
Répondre à ce message
Bonjour,
J’utilisais cette contribution avec bonheur et j’avais ajouté mes propres champs.
Mais voilà qu’aujourd’hui cela ne fonctionne plus, plus moyen de modifier un article comme avant en utilisant cette contrib. Si je l’enlève, je peux à nouveau modifier les articles.
Après investigation sérieuse , je me demande ce que j’ai pu faire pour causer cela
1- Est-ce parce que j’ai ajouté un champ à la table FORUM et un autre à la table AUTEURS et que cette contrib ne prévoit que des ajouts à la table ARTICLES ??
Sinon je n’ai aucune idée... C’Est ma seule piste.. Etes-vous en mesure de m’aider ??
Merci
La contrib ne reconnait que les champs concernant la table articles. Donc l’ajout de champs ailleurs ne peut pas gêner.
Par contre elle est très sensible à la version de SPIP utilisée... Aucune mise à jour ne semble possible ( j(ai en cours une version pour la version actuelle).
Répondre à ce message
Bonjour,
Je cherche à mettre à jour la contrib pour SPIP 1.9.1
J’y suis presque : Les champs s’affichent correctement dans l’interface privée. Il me reste à enregistrer dans la table articles la valeur entrée pour nouveau champ car pour le moment les modifications dans ces champs ne sont pas prises en compte.
Un petit coup de pouce : où est-ce que ça se passe en SPIP 1.9.1 ?
A première vue, je pense que c’est du côté de :
ecrire/action/editer_article.php
Merci de faire évoluer la contrib !
Je suis intéressé au premier chef à la voir tourner sur la version courante de SPIP...
Bon ça y est. Ca à l’air de marcher. Il y avait effectivement un impact dans ecrire/action/editer_article.php
J’ai mis le nouveau pack pour SPIP 1.9.1 ici
C’est parti un peu vite...
L’adresse du pack est donc donnée ci-dessous :
Répondre à ce message
merci beaucoup pour cette contrib qui est forte utile pour mon cas et qui semble marcher correctement.
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 :
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.
Suivre les commentaires : |