Attention ! Ceci n’est pas une documentation pour installer ou utiliser le plugin, mais un « memento » à l’usage des webmestres et intégrateurs qui souhaitent écrire des squelettes/noisettes exploitant Associaspip2.
Au menu :
- les boucles et leurs balises, les balises hors boucles,
- les formulaires, les modèles,
- divers trucs et astuces tout au long.
À table !
Associaspip2 utilisant l’API [SQL] de SPIP2, outre ce qui est prévu en privé, on peut en faire des choses imprévues en public. Le plugin étant conséquent, on peut dire qu’il y à boire et à manger. Sans plus attendre, mettons le couvert.
Les _(BOUCLE)s et #BALISEs/{criteres} disponibles
Le passage en 2.2 fut l’occasion d’harmoniser le nommage des champs. C’est pourquoi les balises sont présentées en tableau mettant en regard les anciennes avec les nouvelles.
Voici la liste des tables/boucles rajoutées/disponibles : asso_activites, asso_categories, asso_comptes, asso_destination, asso_destination_op, asso_dons, asso_exercices, asso_fonctions, asso_groupes, asso_membres, asso_plan, asso_prets, asso_ressources, asso_ventes.
Elles sont réparties en deux catégories/tableaux. Les tableaux sont ordonnés par boucles, puis par balises nouvelles (première colonne) suivi des anciennes (seconde colonne) supprimée.
La première catégorie a un #ID_
TRUC qui lui est propre (table "spip_asso_
truc(s)" excepté pour les destinations et codes comptables) et sert de « clé primaire ».
v2.2 | v2.1 | remarques |
---|---|---|
(ASSO_CATEGORIES) | ||
#COMMENTAIRE |
#COMMENTAIRES |
|
#DUREE |
||
#ID_CATEGORIE |
||
#LIBELLE |
||
#MAJ |
||
#PRIX_COTISATION |
#COTISATION |
|
#VALEUR |
||
(ASSO_COMPTES) | ||
#DATE_OPERATION |
#DATE |
|
#DEPENSE |
||
#ID_COMPTE |
||
#ID_JOURNAL |
C’est l’ID correspondant à l’objet/entité de la boucle qui utilise exclusivement ce code d’imputation | |
#IMPUTATION |
(ASSO_PLAN){code} | |
#JOURNAL |
Est un (ASSO_PLAN){code} | |
#JUSTIFICATION |
||
#MAJ |
||
#RECETTE |
||
#VU |
Vaut : 0 (éditable) ou 1 (véroullé) | |
(ASSO_DESTINATION) |
||
#ID_DESTINATION |
||
#INTITULE |
||
#COMMENTAIRE |
||
#MAJ |
||
(ASSO_DONS) | ||
#ARGENT |
||
#COLIS |
||
#COMMENTAIRE |
||
#CONTREPARTIE |
||
#DATE_DON |
||
#ID_AUTEUR |
#ID_ADHERENT |
(ASSO_MEMBRES){id_auteur} ou... |
#ID_DON |
||
#MAJ |
||
#NOM |
#BIENFAITEUR |
|
#VALEUR |
||
(ASSO_EXERCICES) | ||
#COMMENTAIRE |
||
#DATE_DEBUT |
||
#DATE_FIN |
||
#ID_EXERCICE |
||
#INTITULE |
||
(ASSO_GROUPES) | ||
#AFFICHAGE |
||
#COMMENTAIRE |
||
#ID_GROUPE |
||
#MAJ |
||
#NOM |
||
(ASSO_MEMBRES) | ||
#COMMENTAIRE |
||
#DATE_VALIDITE |
#VALIDITE |
|
#ID_CATEGORIE |
#CATEGORIE |
(ASSO_CATEGORIES){id_categorie} |
#ID_ASSO |
||
#ID_AUTEUR |
...(AUTEURS){id_auteur} | |
#MAJ |
||
#NOM_FAMILLE |
||
#PRENOM |
||
#SEXE |
||
#STATUT_INTERNE |
Vaut : prospect (futur membre potentiel) ou ok (membre actif en règle) ou echu (membre actif dont l’adhésion est arrivé à échéance mais n’a pas été relancé) ou relance (membre actif dont l’adhésion est arrivé à échéance et qui a été relancé) ou sorti (membre exclu ou désactivé) | |
#FONCTION |
À partir de la 2.2 les fonctions sont gérés par la liaison aux groupes, permettant de spécifier plus finement des multiples rôles d’un membre. | |
#ADRESSE |
À partir de la 2.2 l’interface avec le plugin Coordonnés permet de gérer ces autres informations de façon plus fine. | |
#CODE_POSTAL | ||
#EMAIL | ||
#MOBILE | ||
#TELEPHONE | ||
#VILLE | ||
(ASSO_PLAN) |
||
#ACTIVE |
Vaut : 0 (compte inactif) ou 1 (compte actif) | |
#CLASSE |
||
#CODE |
Référence du plan comptable utilisé dans le livre des comptes. | |
#COMMENTAIRE |
||
#DATE_ANTERIEURE |
||
#ID_PLAN |
||
#INTITULE |
||
#MAJ |
||
#SOLDE_ANTERIEUR |
||
#TYPE_OP |
Vaut : credit ou debit ou multi . S’appelait #DIRECTION | |
(ASSO_RESSOURCES) |
||
#CODE |
||
#COMMENTAIRE |
||
#DATE_ACQUISITION |
||
#ID_RESSOURCE |
||
#INTITULE |
||
#MAJ |
||
#PRIX_ACQUISITION |
||
#PRIX_CAUTION |
||
#PU |
||
#UD |
Vaut : Y (un an) ou M (un mois) ou W (une semaine) ou D (un jour) ou H (une heure) | |
#STATUT |
À partir de la version 2.2 c’est le nombre (entier) d’exemplaires présents : 0 quand il n’y a plus d’exemplaire disponible (tous réservés), positif s’il y a des exemplaires disponibles, mais négatif s’il y a des exemplaires mais que la réservation est suspendue. Avant (un seul exemplaire) cela valait : ok (disponible) ou reserve ou suspendu ou sorti (supprimé) | |
(ASSO_VENTES) |
||
#ARTICLE |
||
#CODE |
||
#COMMENTAIRE |
||
#DATE_ENVOI |
||
#DATE_VENTE |
||
#FRAIS_ENVOI |
||
#ID_AUTEUR |
#ID_ACHETEUR |
(ASSO_MEMBRES){id_auteur} ou... |
#ID_VENTE |
||
#MAJ |
||
#NOM |
#ACHTEUR |
|
#PRIX_UNITAIRE |
#PRIX_VENTE |
|
#QUANTITE |
La seconde catégorie relie toujours deux tables/objets et pour plusieurs occurences de part et d’autre (ainsi, la table des membres qui lie un auteur a une seule catégorie est essentiellement une extension de la table des auteurs.) Sa « clé primaire » est formée par la concaténation des deux « clés étrangères » nécessaires à la liaison.
v2.2 | v2.1 | liaison et notes |
---|---|---|
(ASSO_ACTIVITES) | ||
#COMMENTAIRE |
||
#DATE_INSCRIPTION |
#DATE |
|
#DATE_PAIEMENT |
||
#ID_AUTEUR |
#ID_ADHERENT |
(ASSO_MEMBRES){id_auteur} ou... |
#ID_EVENEMENT |
(EVENEMENTS){id_evenement} | |
#MAJ |
||
#NOM |
||
#PRIX_UNITAIRE |
#MONTANT |
|
#QUANTITE |
#INSCRITS |
À partir de la 2.2 il s’agit du « nombre total de places/tarifs réservées/achetés ». Avant c’était le « nombre d’invités » |
#ADRESSE |
À partir de la 2.2 ces champs sont retiré car ces informations sont attachées au membre (via Champs Extras 2 ou Coordonnées qui sont gérés). | |
#EMAIL | ||
#TELEPHONE | ||
#ID_ACTIVITE |
À partir de la 2.2 ces champs sont retirés car non essentiels (mais si on en a besoin on peut les restituer avec Champs Extras 2 qui est géré). | |
#MEMBRES | ||
#NON_MEMBRES | ||
#STATUT | ||
(ASSO_DESTINATION_OP) | ||
#DEPENSE |
||
#ID_COMPTE |
(ASSO_COMPTES){id_compte} | |
#ID_DEST_OP |
||
#ID_DESTINATION |
(ASSO_DESTINATION){id_destination} | |
#RECETTE |
||
(ASSO_FONCIONS) | ||
#ID_GROUPE |
(ASSO_GROUPES){id_groupe} | |
#ID_AUTEUR |
(ASSO_MEMBRES){id_auteur} | |
#FONCTION |
||
#MAJ |
||
(ASSO_PRETS) |
||
#COMMENTAIRE_RETOUR |
||
#COMMENTAIRE_SORTIE |
||
#DATE_CAUTION1 |
Dépôt de la caution | |
#DATE_CAUTION0 |
Restitution de la caution | |
#DATE_RESERVATION |
non encore utilisé | |
#DATE_RETOUR |
||
#DATE_SORTIE |
||
#ID_AUTEUR |
#ID_EMPRUNTEUR |
(ASSO_MEMBRES){id_auteur} ou... |
#ID_PRET |
Bien que dans cette seconde catégorie (liaison entre auteurs et ressources mais non discriminante), ce champ est conservé pour faciliter le code interne. | |
#ID_RESSOURCE |
(ASSO_RESSOURCES){id_ressource} | |
#DUREE |
Nombre de #UD facturé. | |
#MAJ |
||
#NOM |
||
#PRIX_CAUTION |
#PRIX_CAUTION applicable au moment de la location. | |
#PRIX_UNITAIRE |
#PU appliquable au moment de la location. | |
#STATUT |
Probablement utilisé pour savoir l’état de la réservation ? La version 2.2 vérifie simplement qu’une date de retour est renseignée pour savoir que le bien est restitué ; la date de restitution prévue s’obtenant elle en ajoutant la durée de réservation à la date de sortie du bien. |
Attention cependant lors de la réalisation de vos squelettes : dans l’espace privé, des contrôles d’accès assez pointus sont realisés par Associaspip ; mais c’est au webmestre de s’en préoccuper pour ne pas exposer les données à n’importe quel public...
À ce propos, on peut avoir recours à #AUTORISER
, dont (si on veut utiliser les autorisations d’accès du privé) :
- le second argument (« ou » au sens ici de « quel plugin » et non « dans/pour quel objet ») est toujours
association
(car c’est le préfixe du plugin) ; - le premier argument (« action » au sens de « faire_quoi ») se décompose toujours comme suit :
- "faire" (graduellement si les outorisations ne sont pas surchargées) :
voir
(lire seulement les champs affichés dans la fiche ou la liste),exporter
(lire tous les champs disponibles et générer le PDF ou autre fichier d’exportation),editer
(modifier tous les champs ou supprimer des enregistrements),gerer
(aussi bien éditer que configurer) - « quoi » (alphabétiquement) :
activites
(inscriptions/participations aux activités),compta
(livres de compte),dons
(donations manuels),groupes
(groupes d’utilisateurs),membres
,prets
(de ressources),profil
(de l’association),ressources
,ventes
(associatives), pour l’instant.
- "faire" (graduellement si les outorisations ne sont pas surchargées) :
Les autres balises...
Depuis la version 2.0 les nombreux paramètres de configuration/fonctionnement sont stockés dans une table particulière (sur laquelle on ne peut pas boucler...) : spip_association_metas
. Pour accéder à la valeur du paramètre truc, il faut utiliser #META{/association/truc}
. Les différents paramètres qui ont été conservés d’une version à une autre sont :
- Pour le profil de l’association (valeur texte)
-
nom
: son nom, -
rue
: la voie de l’adresse postale, -
cp
: le code postal, -
ville
: la localité postale, -
email
: l’adresse de courriel de contact, -
telephone
: le numéro de téléphone de contact, -
declaration
: la date ou le numéro d’officialisation, -
prefet
: autorité ayant officialisé,
-
- Pour les onglets actifs (valeur booléenne : contien "
on
" si actif, et vide sinon)-
comptes
: La comptabilité, -
ventes
: les ventes de l’association, -
dons
: les dons manuels, -
activites
: les activités associatives, -
prets
: les ressources et leurs prêts,
-
- Les principaux paramètres de la configuration comptable associée (valeur numérique normalement)
-
classe_banques
: la classe des comptes financiers, -
pc_activites
: le compte d’imputation des recettes des participations aux activités, -
pc_cotisations
: le compte d’imputation des cotisations, -
pc_dons
: le compte d’imputation des dons en argent, -
pc_prets
: le compte d’imputation des rectettes de locations, -
pc_ventes
: le compte d’imputation des recettes de ventes associatives,
-
- Autres paramètres comptables (numériques sauf premier) à partir de la 2.1
-
destinations
: activation ("on
") ou non (vide) de l’utilisation des destinations comptables -
dc_cotisation
: la destination comptable par défaut pour les cotisations, -
dc_dons
: la destination comptable par défaut pour les dons, -
dc_ventes
: la destination comptable par défaut pour les ventes, -
pc_frais_envoi
: le compte d’imputation des frais d’envoi,
-
- Concernant les membres (booléens sauf dernier) à partir de la 2.1
-
civilite
: utiliser la civilité, -
prenom
: utiliser le prénom, -
id_asso
: utiliser la référence interne, -
import_nom_auteur
: indique comment traiter la signature des auteurs SPIP lors de l’importation ; il vaut « » (nom de famille et prénom), "prenom_nom
« (prénom et nom de famille), »nom
" (nom de famille seul)
-
La balise #META
va de pair avec #CONFIGURER_METAS
, dont vous n’aurez pas usage et qui est appelée a disparaitre dans le futur (déja la version 2.2 ne l’utilise presque pas et tout le mécanisme nécessaire est intégré dans SPIP 3.0.)
Avec SPIP 3.0 justement, il est possible d’utiliser la balise #CONFIG
de la meme facon que la #META
!
Avec l’arrivée des destinations comptables est apparue la balise #EDITEUR_DESTINATIONS
qui prend respectivement : le tableau des destinations affectées, le tableau des montants respectifs, et la destination par defaut... En fait cette balise dynamique s’appelle sans arguments et les prend dans le contexte créé par le chargement du formulaire.
Des noisettes à #INCLURE au festin
La version 2.2 a été ré-écrite dans l’optique de permettre une personnalisation facile par simple surcharge.
Attention : il ne faut pas oublier en appliquant cela que l’on modifie aussi l’affichage (et/ou le comportement) dans l’espace privé !
Outre la surcharge, des briques de construction du privé peuvent s’utiliser dans vos squelettes avec le mecanisme d’inclusion général ou des balises magiques pour ceux de certains répertoires précis.
Les #FORMULAIREs
Comme pour les versions précédentes, il y a toujours des formulaires calculées dynamiquement et qui ne sont pas surchargeables. Ce sont surtout les formulaires sur le côté pour générer un PDF ou autre format d’exportation, ainsi que ceux des filtres pour affiner l’affichage des listes principales.
Les principaux formulaires d’édition (modification ou ajout) d’un objet du plugin, qui apparaissent dans la zone/colonne principale/centrale d’une page d’édition de l’espace privé utilisent dorénavant le mécanisme HTML/CVT ! Un découpage en quatre pour quatre avantages :
- Pour changer la présentation d’un formulaire, il suffit de déposer dans votre
squelettes/formulaires
un fichier homonyme.html
qui redispose les champs a votre convenance. - Pour seulement le « styler », il faut plutôt se tourner vers
squelettes/perso.css
: le plugin respecte la structure classique des formulaires SPIP, organisés de façon visiblement logique, et avec explications et autres... - Pour modifier le comportement, il suffit de surcharger dans votre
squelettes/formulaires
le fichier homonyme.php
avec les fonctions PHPformulaires_
homonyme_charger()
,formulaires_
homonyme_verifier()
etformulaires_
homonyme_traiter()
- Pour insérer un de ces formulaires dans un squelette, il suffit de faire appel à la balise
#FORMULAIRE_
action_truc(s){
ValParam1,
ValParam2,
...,
ValParamN}
(exactement comme les formulaires natifs !) ; et on peut aussi les appeler dans un article en utilisant le raccourci<formulaire|
action_truc(s)|
NomParam1=
ValParam1|
NomParam2=
ValParam2|
...|
NomParamN=
valParamN>
(il s’agit en fait d’un modele natif de SPIP 2.1 !) Que du bonheur...
On distingue tout d’abord les formulaires pour ajouter ou modifier un enregistrement (editer_asso_
truc) ou plusieurs (editer_asso_
trucs) dans une table (spip_asso_
trucs). Pour les tables de liaisons, c’est la liaison dans un seul sens qui est retenu...
formulaire | table | paramètres (champs-clés) dans l’ordre | précisions |
---|---|---|---|
#FORMULAIRE_EDITER_ASSO_ACTIVITE |
asso_activites |
id_activite temporairement... |
ici il s’agit d’enregistrer et/ou valider la participation (paiement des frais) d’un membre à un événement... |
#FORMULAIRE_INSCRIPTION_EVENEMENT |
id_evenement , id_auteur (pris dans la session) |
ici il s’agira juste pour un membre (auteur de la session) de s’enregistrer pour un événement... (ce formulaire surcharge celui de Agenda 2) | |
#FORMULAIRE_EDITER_ASSO_CATEGORIE |
asso_categories |
id_categorie |
|
#FORMULAIRE_EDITER_ASSO_COMPTE |
asso_comptes |
id_compte |
|
asso_destination_op |
Les destinations sont en fait éditées dans divers formulaires nécessitant un paiement par l’utilisation de #EDITEUR_DESTINATIONS ... | ||
#FORMULAIRE_EDITER_ASSO_DESTINATION |
asso_destination | id_destination |
|
#FORMULAIRE_EDITER_ASSO_DON |
asso_dons |
id_don |
|
#FORMULAIRE_EDITER_ASSO_EXERCICE |
asso_exercices |
id_exercice |
|
#FORMULAIRE_EDITER_MEMBRES_GROUPE |
asso_fonctions | id_groupe |
ici (nom temporaire) on édite les fonctions des membres d’un groupe |
#FORMULAIRE_EDITER_MEMBRE_GROUPES |
id_auteur |
ici (nom temporaire) on éditera les fonctions d’un membre dans différents groupes | |
#FORMULAIRE_EDITER_ASSO_GROUPE |
asso_groupes |
id_groupe |
|
#FORMULAIRE_EDITER_ASSO_MEMBRE |
asso_membres |
id_auteur |
|
#FORMULAIRE_EDITER_ASSO_PLAN |
asso_plan |
id_plan |
|
#FORMULAIRE_EDITER_ASSO_PRET |
asso_prets |
id_pret |
|
#FORMULAIRE_RESERVER_RESSOURCE |
id_ressource , id_auteur (pris dans la session) |
ici il s’agira de se mettre en liste d’attente... | |
#FORMULAIRE_EDITER_ASSO_RESSOURCE |
asso_ressources |
id_ressource |
|
#FORMULAIRE_EDITER_ASSO_VENTE |
asso_ventes |
id_vente |
|
#FORMULAIRE_COMMANDER_ARTICLE |
article , id_auteur (pris dans la session) |
sert à passer commande... | |
#FORMULAIRE_EDITER_ASSO_META_UTILISATEUR |
association_metas |
nom_meta_ut |
Pour gérer des constantes propres au profil de l’association |
#FORMULAIRE_CONFIGURER_ASSOCIATION |
Pour gérer les informations de base de l’association et les options de fonctionnement du plugin |
On a aussi des formulaires pour seulement ajouter un enregistrement (editer_asso_
truc) ou plusieurs (editer_asso_
trucs) dans une table (spip_asso_
trucs). Pour les tables de liaisons, c’est aussi la liaison dans un seul sens (toujours le même) qui est retenu...
formulaire | tables | paramètres (champs-clés) dans l’ordre | édition |
---|---|---|---|
#FORMULAIRE_AJOUTER_COTISATION |
asso_membres (date de validite), asso_comptes (montant, date, justificatif, etc.) et asso_destination_op (s’il faut gérer les destinations comptables) |
id_auteur (le cotisant), nom_prenom (inséré dans le justificatif), id_categorie (montant de base et allongement de la durée de validité), validite (date de validité antérieure), editable . En fait on pourrait n’utiliser que id_auteur et id_categorie ...mais on garde tous ces arguments par rétro-compatibilité ! |
#FORMULAiRE_EDITER_ASSO_COMPTE |
#FORMULAIRE_AJOUTER_MEMBRES_GROUPE |
asso_fonctions |
id_groupe |
#FORMULAIRE_EDITER_MEMBRES_GROUPE |
On a aussi des formulaires de « synchronisation » (entre une table Associaspip et une table n’appartenant pas au plugin) et qui pour l’instant ne fonctionne que dans le sens de l’importation...
formulaire | table interne (Associaspip) | table externe (plugin) |
FORMULAIRE_SYNCHRONISER_ASSO_MEMBRES |
asso_membres |
auteurs (natif) |
#FORMULAIRE_SYNCHRONISER_ASSO_ACTIVITES |
asso_activites |
evenements_inscriptions (Agenda 2) |
On a enfin des inclassables qui, pour l’instant, n’ont pas besoin de paramètres.
formulaire | table | paramètres et remarques |
---|---|---|
#FORMULAIRE_PARAMETRER_ETIQUETTES |
assotiation_metas |
|
#FORMULAIRE_MAILING_MEMBRES |
Comme déjà dit (pour les données des tables), en exposant les formulaires en public il faut penser a gérer la sécurité soi-même : en plus d’être visibles, elles sont de plus modifiables...
Le même souci se pose avec les données en lecture (balises hors formulaires) mais crayonnables par les utilisateurs authentifiés... Bien que Crayons s’en sorte bien en gênêral, on perd quand même le benefice des acces finement configures car Associaspip ne lui prevoit pas de controleurs.
Les #MODELEs
Certains blocs de l’espace privé utilisent dorénavant le mécanisme des modèles pour offrir les trois avantages suivants :
- On peut les insérer directement dans un squelette en appelant la balise
[(#MODELE{
truc(s)}{
NomParam1=
ValeurParam1}{
NomParam2=
ValParam2}{
...}{
NomParamN=
ValParamN})]
Mais surtout on peut les utiliser comme raccourcis :<
truc(s)|
NomParam1=
ValParam1|
NomParam2=
ValParam2|
...|
NomParamN=
ValParamN>
! Le pied pour les rédacteurs qui savent... - Pour adapter le code HTML d’un modele (réordonner les informations par exemple), il suffit de déposer dans votre
squelettes/modeles
le fichier homonyme.html
modifié qui surchargera celui du plugin. - Pour seulement le « styler », il faut plutôt se tourner vers
squelettes/perso.css
; ce sont les classes microformat et ceux de SPIP (notamment pour les liens et les tableaux) qui sont utilisées.
Pour ses tables (spip_asso_
trucs) à boucles, la convention de nommage adoptée est similaire a celle des formulaires, et la mise en page convenue :
- Pour un enregistrement (
asso_
truc) le(s) paramètre(s) requis sera toujours la « clé primaire»i;. La fiche y présentera les autres données (la clé primaire est donc exclue) sous forme de liste de définitions avec les noms de champs traduits (intitulés) et les clés etrangeres remplacées par le titre/libellé correspondant. - Pour plusieurs enregistrements (
asso_
trucs —exemple : asso_ressources) on utilisera tous les critères demandés (test d’egalité !). Le résultat (listing) sera presenté sous forme tabulaire simple. Deux paramètres supplémentaires sont utilisés lorsque disponibles :tri
pour le(s) champ(s) par le(s)quel(s) les enregistrements sont classés chronologiquement ;pagination
pour le pas de pagination (i.e. nombre de résultats affichés à la fois). - Pour plusieurs enregistrements d’une table de liaison, on convient de suffixer par la partie de la liaison sur laquelle on se base (
asso_
trucs_
sens2liaison —exemple : asso_fonctions_groupe) et on utilisera cette seule clé primaire ! Le résultat (listing) sera presenté sous forme tabulaire.
En dehors de ces modèles (présents ou à venir —donc nomenclature réservée) liés aux boucles, on trouvera :
- Pour Associaspip
-
asso_profil
qui s’utilise sans argument et qui affiche la présentation de l’association telle que renseignée dans la configuration, ainsi que les métas utilisateurs définis.
-
- Pour Coordonnées
-
coordonnees_adresse
pour la présentation des adresses postales issues du plugin. Les paramètres sont les principaux champs de la tablesadresses
(voie
,complement
,boite_postale
,code_postal
,ville
,region
) ainsi que :nom_pays
pour le nom complet du pays ;_nl
pour les caractères de saut de ligne ;_ht
pour les caractères d’espacement horizontal. -
coordonnees_telephone
pour la présentation des numeros de telephone issus du plugin. Les paramètres sont les principaux champs de la tabletelephones
(numero
).
-
Aucune discussion
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 : |