[spip-dev] Champs extra...euh je comprends pas

Dev
1

Bonjour,

j'ai quelques problèmes avec les champs extra et le flou qui les entoure.
Ok, c'est une fonctionnalité en alpha.
J'ai lu /ecrire/inc_extra.php3
J'ai créé /ecrire/mes_options.php3 avec la syntaxe indiquée.
J'ai créé les champs en question dans la table spip_article et...j'y vois aussi un champ "extra" indiqué...créé par spip!
Lorsque je charge ma page d'édition d'article je n'ai pas les lignes de formulaire correspondante alors que je les édite très bien directement dans ma base.

Bref, qu'est ce que j'ai pas fait ou mal fait?

merci :slight_smile:

2

Hello,

J'ai lu /ecrire/inc_extra.php3
J'ai créé /ecrire/mes_options.php3 avec la syntaxe indiquée.
J'ai créé les champs en question dans la table spip_article [...]

Où as-tu bien donc lu qu'il faut créer le moindre champ ???

-Nicolas

3

Bon, merci à tous pour les messages et les liens :slight_smile:

ça marche.

Donc, les champs extra "howto" (n'hésitez pas à corriger si je dis une connerie :wink: ).

1/ Déterminer les champs supplémentaires à créer et leur type (sur une ligne ou sur plusieurs).
2/ créer un fichier mes_options.php3 dans /ecrire

Syntaxe :
<?php

$GLOBALS['champs_extra'] = Array (
  'articles' => Array (
    "inci" => "ligne|typo|INCI",
    "element"=>"bloc|propre|ELEMENT"
    ),

  'breves'=>Array(
  "auteur" =>"ligne|typo|AUTEUR"
    )
  );

?>

le premier item dit que dans l'objet spip : articles, breves, auteur on crée des champs (une table...):
entre "" le nom du nouveau champ avec lequel on pourra appeler celui-ci dans le squelette avec la syntaxe
  [(#EXTRA|extra{"nom_du_champ"})]
ensuite c'est : le type de champ (bloc de texte ou ligne de texte) les filtres typographiques (propre, typo et ? y en a d'autres?) et enfin le nom qui sera devant le champ dans le formulaire d'édition d'article.

Rien à créer dans la base, spip se débrouille tout seul : dont acte :slight_smile:

N'hésitez pas à compléter le message si il y a des erreurs ou des choses à compléter (y en a c'est clair!)
et merci à tous ceux qui ont répondu.
Et...euh...Joyeux Noël? :wink:

4

Sur les champs extras ça serait pas mal que ceux qui ont fait des bouts de
doc à droite et à gauche fassent un bon tutorial pour spip_contrib, car ça
ne sera pas documenté dans la doc officielle. Et comme en plus ça a pas mal
bougé entre le début et maintenant, je ne sais plus où on en est de la
syntaxe etc. D'autant qu'il y a un patch sympa qui est passé récemment sur
la liste, permettant de faire des menus-sélect (il faudra m'expliquer en
quoi c'est utile, car les mots-clés sont là pour ça, non ?).

@ Philippe Auriol <Philippe.Auriol@wanadoo.fr> :

Bon, merci à tous pour les messages et les liens :slight_smile:
ça marche.

-- Fil

5

Sur les champs extras ça serait pas mal que ceux qui ont fait des bouts de
doc à droite et à gauche fassent un bon tutorial pour spip_contrib, car ça
ne sera pas documenté dans la doc officielle. Et comme en plus ça a pas mal
bougé entre le début et maintenant, je ne sais plus où on en est de la
syntaxe etc.

Moi non plus, honnêtement. J'ai installé un 1.7b4 récemment, et j'ai
eu des problèmes avec les champs extras. Quelques choses qui ont
changé que je vois:

- nouveau fichier inc-calcul-champs.php3 qui ne semble pas toujours
utilisé, mais c'est peut-être ma mise-à-jour qui a déconné;
- syntaxe de définition des champs utilise les types au plurieur au
lieu d'au singulier (ie. rubriques au lieu de rubrique)
- il me semble aussi avoir lu quelquepart que la syntaxe dans les
squelettes seraient plutôt #EXTRA|nom_du_champ au lieu de
#EXTRA|extra{nom_du_champ}, mais je n'ai pas vu ca dans 1.7b4...

Pour le reste, j'ai écrit un peu de doc sur spipquebec.org, mais c'est
évidemment pas suffisant...

Désolé, c'est les vacances qui arrivent et j'ai vraiment pas le temps
de m'occuper de ça. :slight_smile:

D'autant qu'il y a un patch sympa qui est passé récemment sur
la liste, permettant de faire des menus-sélect (il faudra m'expliquer en
quoi c'est utile, car les mots-clés sont là pour ça, non ?).

Ah! C'est moi ça. :slight_smile:

L'idée est que les mots-clés s'applique à tous les articles (par
exemple) tandis que les champs extras sont plus flexibles. C'est
simplement ça. D'ailleurs, "under the hood", c'est le même système: la
valeur du champ extra est sérialisée, c'est seulement que l'on offre à
l'usager un ensemble de valeurs prédéfinines.

On ne contrôle même pas s'il elles sont valides, d'ailleurs.

En d'autres termes, c'est un gros hack, mais ça marche.

A.

6

Bonjour,

Sur les champs extras ça serait pas mal que ceux qui ont fait des bouts de
doc à droite et à gauche fassent un bon tutorial pour spip_contrib,

Franchement : hier , avec l'aide du groupe, j'ai réussi à avoir un fichier qui fonctionne MAIS :
=> Je ne comprends pas ce que fait réellement ce in_extra : il n'ajoute pas de champs dans la table spip (il y a déjà le champ extra dans la table article), alors il les stocke où les données? Dans ce champ? avec un "signal" pour chaque?
=> J'ai trouvé sur toutes ces pages des tas de syntaxes et rarement une explication, celle qui "marche" avec la PR1 c'est :
<?php

$GLOBALS['champs_extra'] = Array (
  'articles' => Array (
    "inci" => "ligne|typo|INCI",
    "element"=>"bloc|propre|ELEMENT"
    ),

  'breves'=>Array(
  "auteur" =>"ligne|typo|AUTEUR"
    )
  );
?>

Mais avec des questions sans réponse pour moi :

dans la syntaxe : "inci" => "ligne|typo|INCI",
inci sera le nom avec lequel on appellera ce "champ_extra" dans le squelette. Question: y a des noms réservés?
ligne est le type d'affichage, j'ai vu qu'il y aussi bloc. Question: c'est quoi la liste des types?
typo est le filtre que l'on applique. Question: si on veut pas de filtre on mets quoi? Et quels filtres on peut mettre?
INCI ok, c'est le nom qui va s'afficher devant le champ dans le formulaire d'article.
Ah oui, pour éviter les parses "," à la fin de la ligne quand il y a plusieurs champs : ça le fait :wink:

Et alors, si on veut réserver à des secteurs comme le dit spip_quebec? On fait comment maintenant?

Pour l'affichage actuellement c'est :

[(#EXTRA|inci)] dans le squelette qui le fait

car ça
ne sera pas documenté dans la doc officielle. Et comme en plus ça a pas mal
bougé entre le début et maintenant, je ne sais plus où on en est de la
syntaxe etc.

Ben justement si ceux qui l'on fait peuvent déjà compléter en répondant aux questions ça aiderait à faire quelque chose pour spip_contrib

D'autant qu'il y a un patch sympa qui est passé récemment sur
la liste, permettant de faire des menus-sélect (il faudra m'expliquer en
quoi c'est utile, car les mots-clés sont là pour ça, non ?).

zut pas (re) trouvé le patch.

7

Sur les champs extras ça serait pas mal que ceux qui ont fait des bouts de
doc à droite et à gauche fassent un bon tutorial pour spip_contrib, car ça
ne sera pas documenté dans la doc officielle.

  Il faudrait plutôt commencer par décider de ce qu'on en fait.
  Est-ce qu'on dégage tout ? est-ce qu'on refait tout avec la solution
proposée par je-sais-plus-qui via une table extra avec des colonnes
type/id/champ/valeur ?

  C'est pas la peine de documenter ça si c'est pour tout refaire dans
un mois, nan ?

Et comme en plus ça a pas mal
bougé entre le début et maintenant, je ne sais plus où on en est de la
syntaxe etc.

  Moi non plus. Ce tableau qui défini qui peut faire quoi, j'ai
vraiment pas l'impression que ça soit ce qu'il y a de plus simple.

  Au départ, on a codé ça pour gérer des cas particuliers mais simples
(par secteur, sans tri ni select). Depuis, tout le monde réclame de
pouvoir faire des champs par sous-rubrique, auteur ou groupes de
mots clé et de pouvoir faire des tri et des select.

  Soit on dit définitivement non à tout ça, et le code peut rester comme
il est (à part la balise #EXTRA|champ qui est une bonne idée), soit
on dit oui à tout ça, mais il faut alors revoir complètement ce code.

  J'aimerais bien faire partie de ce "on", mais c'est un peu chaud pour
trouver du temps en ce moment.

  En tous cas, je pense qu'il faut vraiment fixer des priorités pour
les semaines à venir :
1 sortir la 1.7 et arréter tous ces débats tant que ce n'est pas fait.
2 "planifier" les chantiers de l'après 1.7 :
  - parseur de squelette (placid ?)
  - générateur de squelette (travail de je-sais-plus-qui-bis ?)
  - que faire des champs extra
  - revoir certains bouts de code (organisation en répertoire,
    aspect un peu plus objet de certains points, refonte de
    formulaire_forum qu'est toujours dans mon placard ...).

  J'avais proposé à un moment de faire une 1.8 qui soit iso-1.7 mais
après recodage de certains morceaux. Qu'en pensez vous ?

À+, Pif.

8

Hello,

Je ne comprends pas ce que fait réellement ce in_extra : il n'ajoute
pas de champs dans la table spip (il y a déjà le champ extra dans la
table article), alors il les stocke où les données? Dans ce champ?
avec un "signal" pour chaque?

En quelque sorte, oui, il sérialise toutes les valeurs d'extra dans
une seule chaine de caractères.

cf PHP: serialize - Manual

<?php
$GLOBALS['champs_extra'] = Array (
        'articles' => Array (
                "inci" => "ligne|typo|INCI",
                "element"=>"bloc|propre|ELEMENT"
                ),
        'breves'=>Array(
        "auteur" =>"ligne|typo|AUTEUR"
                )
        );
?>

Ne pas oublier la "personnalisation" légère de l'usage de ces champs
avec $GLOBALS['champs_extra_proposes'].

dans la syntaxe : "inci" => "ligne|typo|INCI",
inci sera le nom avec lequel on appellera ce "champ_extra" dans le
squelette. Question: y a des noms réservés?

A priori, non.

ligne est le type d'affichage, j'ai vu qu'il y aussi bloc. Question:
c'est quoi la liste des types?

Tu viens de la faire. :slight_smile:

Il y a eu une proposition pour des selects, et j'ai un peu bossé sur
des dates, mais rien dans SPIP pour l'instant.

typo est le filtre que l'on applique. Question: si on veut pas de
filtre on mets quoi?

"brut"

Et quels filtres on peut mettre?

Tous les filtres standards, il me semble, mais je n'ai pas vérifié.

Et alors, si on veut réserver à des secteurs comme le dit
spip_quebec? On fait comment maintenant?

Voilà le contenu de mon script "mes_options.php3" :

<?php
$GLOBALS['champs_extra'] = array(
        'articles' => array(
                'asin' => 'ligne|brut|Code ASIN Amazon.fr'
                )
        );

$GLOBALS['champs_extra_proposes'] = array(
        'articles' => array(
                'tous' => '',
                43 => 'asin'
                )
        );
?>

Je limite l'usage de l'extra "asin" au secteur 43.

-Nicolas

9

En tant que "je-sais-plus-qui-bis" je souscris tout à fait
à ce point de vue. Je signale que la dernière version du
générateur de squelette contient une refonte de formulaire_forum
(pas tout-à-fait aboutie, mais sachant déjà plus profiter du cache
que l'actuelle) et aussi un chgt dans l'analyseur syntaxique pour
les includes (là aussi y a encore des améliorations à faire).
Enfin, en ce qui concerne les champs extras, je rappelle que ce générateur
transforme tout champ SQL déclaré dans les bases en balise SPIP: bon,
c'est pas phpmyadmin, ce qui poserait d'ailleurs beaucoup de problèmes,
mais ça peut être une piste.