Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2) - commentaires

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

En fait, j'ai fait le plugin, finalement, pour Spip 2.0.

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Version 1.9.2

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)

Version 1.9.2

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 ?

Version 1.9.2

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

Plusieur secteur

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',

Plusieur secteur

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Affichage permanent des champs vides

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 »

Affichage permanent des champs vides

Cela semble intéressant cette version pour 1.9.1 (ou plus...)
Serait-il possible de l'avoir ?
Merci d'avance

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

Résultat identique avec la contrib des champs homonymes. Sur le site public mes nouveaux champs créés s'affichent entièrement avec les !
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.

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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.

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

Je n'ai rien prévu de particulier pour le multilingue...
As-tu bien renseigné tes colonnes dans le fichier base/serial.php ?

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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.

Pb d'utilisation

Bonjour,

Serait-il possible de savoir comment exactement installer cette contrib sur une 1.9.2 ?

Merci d'avance

Affichage permanent des champs vides

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.

Affichage permanent des champs vides

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

Affichage permanent des champs vides

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.

Affichage permanent des champs vides

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+

Affichage permanent des champs vides

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 ?

Affichage permanent des champs vides

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

Affichage permanent des champs vides

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

Affichage permanent des champs vides

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

Affichage permanent des champs vides

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.

Affichage permanent des champs vides

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.

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.9.1)

C'est parti un peu vite...

L'adresse du pack est donc donnée ci-dessous :

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

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 ?

thx

merci beaucoup pour cette contrib qui est forte utile pour mon cas et qui semble marcher correctement.

Pb d'affichage sur v.1.9

peut-être inscrire le(s) champ(s) en question dans phpadmin ...

Pb d'affichage sur v.1.9

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.