SPIP - français, ces 365 derniers jours

SPIP est un système de publication pour l’Internet qui s’attache particulièrement au fonctionnement collectif, au multilinguisme et à la facilité (...)



mardi 7 mai 2019

  • #FORMULAIRE_JOINDRE_DOCUMENT

    #FORMULAIRE_JOINDRE_DOCUMENT{new,#ENV{id_objet},#ENV{objet}} sert à téléverser un document et à l'associer à un objet SPIP.

    Par exemple, pour téléverser un document et l'associer à un article :

    #FORMULAIRE_JOINDRE_DOCUMENT{new,#ENV{id_article},'article'}

    On peut aussi téléverser des documents depuis l'espace public sans les rattacher à un objet :

    #FORMULAIRE_JOINDRE_DOCUMENT

    Par défaut, le formulaire sans argument #FORMULAIRE_JOINDRE_DOCUMENT est visible pour tout le monde, y compris les visiteurs non authentifiés, mais la balise avec arguments (pour rattacher le document à un article par exemple), n'est visible que des administrateurs.


vendredi 12 avril 2019

  • Liste des chantiers

    Cette page liste tous les chantiers portant sur le noyau de SPIP, les plugins et squelettes distribués avec la version officielle et les sites de la galaxie.
    Il peut s'agir de chantiers en cours mais aussi de chantiers réalisés, à venir ou en préparation.

    Refonte du site contrib.spip.net

    Lieu de discussion du groupe https://framavox.org/g/HWIQ0bwl/spi...
    Lieu de visualisation des travaux pas encore décidé
    Statut En cours de lancement
    Intervenant⋅e⋅s -
    Début avril 2019
    Fin -

    Refonte de l´interface d´administration

    Ce chantier vise à faire une refonte complète de l'interface d'administration. Pas des pansements ponctuels, mais faire de la (re)conception sur le long terme de tous les gros morceaux : navigation générale, édition de contenus, configuration, profil utilisateur, médiathèque, etc.

    Lieu de discussion du groupe https://framavox.org/g/H9Q1rWwV/spip-ga-refonte-de-l-admin
    Lieu de visualisation des travaux Pas encore décidé.
    Statut En préparation
    Intervenant⋅e⋅s -
    Début Courant 2019
    Fin -

    Refonte du site spip.net et de la documentation

    Suite à la mise à jour graphique de 2017, réorganiser le site officiel pour en faire un véritable portail d'accueil et de redirection.

    Lieu de discussion du groupe https://framavox.org/g/yGz0ABS7/spip-ga-refonte-de-spip-net-et-des-documentations
    Lieu de visualisation des travaux Pas encore décidé.
    Statut En préparation
    Intervenant⋅e⋅s -
    Début -
    Fin -

    Amélioration de l'insertion des documents

    Lieu de discussion du groupe -
    Lieu de visualisation des travaux -
    Statut En préparation
    Intervenant⋅e⋅s -
    Début -
    Fin -

mardi 19 mars 2019

  • Versions Maintenues

    Versions actuellement maintenues

    Branche Compatibilité PHP Première publication Maintenance active jusqu'au Correctifs de sécurité jusqu'au
    3.0 5.1 - 5.6 12 mai 2012 17 octobre 2017 30 juin 2019
    3.1 5.1 - 7.1 6 janvier 2016 30 juin 2019
    3.2 5.4 - 7.2 17 octobre 2017

    Ou sous forme de calendrier :

    2.0 ] 2.1 ] 3.0 ] 3.1 ] 3.2 ] Jan 2016 Jan 2017 Jan 2018 Jan 2019 Jan 2020 Jan 2021 Jan 2022 Jan 2023 aujourd'hui : 27 mai 2019

    Image

    Légende

    Non publiée Une version qui n'a pas encore été publiée.
    Maintenance active Une version qui est activement prise en charge. Les bogues signalés et les problèmes de sécurité sont corrigés et des mises à jour régulières sont effectuées.
    Correctifs de sécurité seulement Une version prise en charge uniquement pour les problèmes de sécurité critiques. Les publications ne sont effectuées qu'au besoin.
    Fin de vie Une version qui n'est plus prise en charge. Les utilisateurs de cette version doivent mettre à jour dès que possible, car ils peuvent être exposés à des vulnérabilités de sécurité non corrigées.

dimanche 20 janvier 2019

  • _INTRODUCTION_SUITE

    La constante _INTRODUCTION_SUITE permet de personnaliser la chaine de caractère affichée du texte coupé par la balise #INTRODUCTION.

    La valeur par défaut de cette constante est : (...)

    Pour définir une autre valeur, on éditera le fichier config/mes_options.php (voir l'article qui lui est consacré).

    Exemple :

    // Définir une césure personnalisée à la balise #INTRODUCTION
    define('_INTRODUCTION_SUITE', ' [...]');

    Voir aussi : #INTRODUCTION, _COUPER_SUITE


samedi 19 janvier 2019

  • _COUPER_SUITE

    A partir de SPIP 3.2.2, la constante _COUPER_SUITE permet de personnaliser la chaine de caractère affichée lorsqu'on coupe un texte via le filtre |couper.
    C'est aussi la chaine de caractère retenue pour la césure de la balise #INTRODUCTION si la constante _INTRODUCTION_SUITE n'est pas définie.

    La valeur par défaut de cette constante est : (...)

    Pour définir une autre valeur, on éditera le fichier config/mes_options.php (voir l'article qui lui est consacré).

    Exemple :

    // Définir une césure personnalisée
    define('_COUPER_SUITE', ' [...]');

    Voir aussi #INTRODUCTION, _INTRODUCTION_SUITE


vendredi 4 janvier 2019

  • Migration d'un squelette de SPIP 2 vers SPIP 3

    Ainsi que sa numérotation l'indique, la version SPIP 3 est une version majeure de SPIP, qui apporte de nombreuses et importantes fonctionnalités. Dans l'ensemble, l'équipe de SPIP s'est assuré que les sites fonctionnant avec SPIP 2 fonctionnent également avec SPIP 3.

    - Base de données : la mise à jour se fera sans encombre mais aussi, comme toujours, sans possibilité de revenir à SPIP 2. Comme pour toute migration, il est donc recommandé de faire une sauvegarde de la base de donnée dans sa version SPIP 2 avant de faire une migration de vos sites vers SPIP 3, afin de vous ménager la possibilité de revenir à SPIP 2.

    - Plugins : l'API ayant été modifiée, une modification du code des plugins est souvent requise pour SPIP 3, soit pour simplement fonctionner, soit pour bénéficier des nouveaux apports de SPIP 3. De nombreux plugins distribués par la zone sont d'emblée compatibles avec SPIP 3 ou bénéficient d'une version adaptée pour SPIP 3.
    Si jamais vous avez réalisé vous même un plugin et que vous devez le porter en SPIP 3, un bloc note a collecté un ensemble de points destinés à faciliter sa migration. Voyez l'article "Migration de Plugins de SPIP2 à SPIP3" du Carnet SPIP. Au besoin, vous pouvez aussi demander de l'aide sur les listes ou IRC.

    - Squelettes : Les éléments du langage SPIP 2 sont tous valables en SPIP 3. Bien que très rarement rencontrées, il existe toutefois de petites incompatibilités dans certaines configurations de squelettes, qui nécessiteront donc une adaptation, et ce d'autant plus que vous utiliserez des fonctionnalités profondes.

    C'est sur ce dernier point : les rares incompatibilités du langage de squelette, que porte cet article.

    Chaînes de langues déportées dans des plugins

    Un grand nombre de fonctionnalités du noyau de SPIP sont désormais déportées dans des plugins, et avec elles les chaînes de langues qu'elles utilisent. En conséquence, pour y faire appel dans les squelettes, il faut les préfixer par le préfixe du plugin correspondant si vous les utilisez dans vos squelettes.

    Par exemple, <:forum_texte:> doit pour SPIP3 être remplacé par <:forum:forum_texte:>.

    A propos des chaines de langues, voyez la doc sur les nouveautés des chaînes de langues avec SPIP 3.

    Formulaire inscription

    La balise #FORMULAIRE_INSCRIPTION n'est jamais totalement vide en SPIP3 , même quand les inscriptions ne sont pas autorisées sur le site. En conséquence, elle ne pourra pas servir pour conditionner un affichage (par exemple [(#FORMULAIRE_INSCRIPTION) lien vers la page d'inscription] affichera toujours le lien).

    A la place, il faut tester directement la configuration du site SPIP. Il existe deux entrées pour cela :
    - accepter_visiteurs
    - accepter_inscriptions

    Exemple :

    [(#CONFIG{accepter_visiteurs}|=={oui}|oui) ]

    Critère {id_parent}

    Avec SPIP 3, cette boucle ne fonctionne pas de la même manière qu'avec SPIP 2

    span>(RUBRIQUES){id_parent}>
    #ID_RUBRIQUE
    

    En effet :
    - si il y a une boucle RUBRIQUES englobante, {id_parent} prend le #ID_RUBRIQUE de la boucle englobante
    - s'il n'y en pas, id_parent prend le #ENV{id_parent},

    En SPIP 2 {id_parent} prend #ENV{id_rubrique}.

    En conséquence, avec SPIP 3, il est désormais possible d'écrire {id_parent ?}{id_rubrique ?}.

    Pour migrer une telle boucle, il faut :
    - appeler l'url avec un paramètre id_parent supplémentaire ;
    - ou adapter la boucle en mettant un critère supplémentaire {id_parent ?}{id_rubrique ?}.

    Dans certains cas, le critère suivant a son utilité pour remplacer {id_parent} en assurant la compatibilité d'un squelette entre versions SPIP 2 et SPIP 3 : {id_parent=#ENV{id_parent,#ENV{id_rubrique}}}.

    Boucles FORUMS et ARTICLES imbriquées

    Avec SPIP 2, la table forums comporte plusieurs champs id_article, id_breve et id_rubrique qui permettent certaines boucles.

    Ces boucles doivent être adaptées pour fonctionner avec SPIP 3 puisque ces champs ont été remplacés par deux champs objet etid_objet.

    Ces deux champs permettent de mettre des forums sur n'importe quel objet éditorial, que ce soit des mots, des documents ou tout autre objet créé par un plugin.

    Par exemple, les emboitements suivants ne marchent plus :

    span>(FORUMS) {id_thread}> span>(ARTICLES) {id_article}> ...

    ou :

    span>(FORUMS){0,1}> span>(ARTICLES){id_article}> #ID_ARTICLE 
    

    En SPIP 3 on corrige en :

    span>(FORUMS){0,1}{objet=article}> span>(ARTICLES){id_article=#ID_OBJET}> #ID_ARTICLE 
    

    ou bien avec :

    span>(ARTICLES){id_article=#ID_OBJET}{si (#OBJET|=={article})}> etc... 

    Titres et rangs

    #TITRE bénéficie désormais d'un traitement qui enlève automatiquement le n° qui préfixe éventuellement le contenu.

    La plupart du temps, c'est bien ce comportement qu'on recherche, et il est donc inutile d'appeler le filtre supprimer_numero comme il le fallait avant. Si toutefois vous voulez afficher le titre avec son numéro, il faut enlever ce traitement, c'est à dire employer #TITRE*.

    Cette différence de comportement par défaut peut avoir des conséquences sur des squelettes qui feraient des comparaisons dans un critère, car le traitement n'est par contre toujours pas appliqué sur le champ 'titre' lorsqu'il figure en partie gauche d'un critère.

    Par exemple :

    span>(ARTICLES){id_article}> span>(ARTICLES){titre>#TITRE|recuperer_numero} >
    etc...

    Cette boucle pour afficher les articles de rangs supérieurs au rang de l'article courant ne marchera plus puisque #TITRE ne renvoie plus de numéro. À la place, il faut employer la balise avec étoile #TITRE*.

    span>(ARTICLES){id_article}> span>(ARTICLES){titre>#TITRE*|recuperer_numero} >
    etc...

    Modèles

    Les modèles reçoivent maintenant l'environnement. Tous les paramètres de contextes, présents dans l'environnement d'appel ou explicitement passés en paramètre de l'appel, avec une priorité à ces derniers, sont à la fois accessibles par #VARIABLE et en #ENV{variable}. Des adaptations sont donc nécessaires dans certains modèles.

    À titre d'exemple, un modèle inclus dans le corps de l'article 18 et donc noté : transmet 2 informations supplémentaires :

     #ENV{article18} => #ENV{id_article} => 18

    Dans le cas où l'appel du modèle inclue id_article comme paramètre () c'est bien cet id_article là (2) qui sera transmis, quel que soit l'id de l'article dans lequel ce modèle est appelé (comportement : comme avant).

    En revanche, lorsqu'on ne passe pas de paramètre explicite, le comportement sera différent, si le modèle fait appel :
    - au critère conditionnel {id_article?} dans une boucle
    - à un test sur [(#ID_ARTICLE) affichage si id_article]
    puisque dans tous les cas #ID_ARTICLE ou #ENV{id_article} existera.

    Pour corriger lorsque ce sera nécessaire, il est possible :
    - de changer de nom de paramètre pour enlever l'ambiguité
    - d'utiliser le fait que seuls les paramètres passés explicitement lors de l'appel du modèle sont accessibles en plus par #ENV{arg/variable}, à la différence des paramètres non explicites passés automatiquement au contexte.

    Ainsi on pourra remplacer un critère conditionnel {article ?} par la combinaison de deux critères :

     {id_article >= #ENV{args/id_article, 0}} {id_article <= #ENV{args/id_article, 99999999}}

    Balise #FOREACH

    La balise #FOREACH disparaît. A la place il faut utiliser une boucle itérateur DATA.

    span>(DATA){source tableau,#LE_TABLEAU}>
    #CLE / #VALEUR
    

    Si c'est juste pour afficher le contenu des tableaux#ENV ou #CONFIG, il est aussi possible d'utiliser :

    [
    (#ENV**|unserialize|print_r{1})
    ] [
    (#CONFIG**|unserialize|print_r{1})
    ]

    Avec le plugin 'developpement' on pourra plus simplement écrire :
    [(#ENV|bel_env)] ou [(#CONFIG|bel_env)]

    Boucles avec jointures

    Certaines jointures qui devaient être explicitées dans SPIP 2 se font désormais automatiquement.

    Exemple : jointure de spip_rubriques avec spip_mots.

    Le commit 90091 remplace la boucle SPIP 2

    1. span>(RUBRIQUES mots){type_mot=_FondPage}{fusion mots.id_mot}>

    par la boucle SPIP 3

    1. span>(RUBRIQUES){type_mot=_FondPage}{fusion id_mot}>

    Table de liens

    Les tables de liaisons sur les mots ou sur les auteurs, qu'il y avait pour chaque objet spip spip_mots_articles, spip_auteurs_articles, spip_mot_breves, spip_mot_rubriques... ont toutes été fusionnées en spip_mots_liens et spip_auteurs_liens.

    Au lieu d'une seule colonne id_article ou id_breve ou id_rubrique comme l'avaient chacune des tables disparues, les nouvelles tables génériques de lien ont deux colonnes génériques : objet etid_objet. Elles peuvent ainsi décrire les liens avec mots et auteurs de tous les objets : ceux livrés avec SPIP, et ceux créés par les plugins.

    Cela ne change rien pour les boucles simples qui ne mentionnent pas ces tables de liaison même si SPIP les utilise grâce à l'ingéniosité de son compilateur de boucles.

    En revanche, il faut évidemment modifier les boucles plus complexes qui référencent explicitement ces tables, si jamais il y en a dans vos squelettes.

    Exemple : dans c90093, la boucle avec double jointure explicite, dont une sur mots_rubrique

    1. span>(ARTICLES rubriques mots_rubriques){titre_mot=Goodies}{doublons goodies}{age>=(#CONFIG{soyezcreateurs/age_goodies,30})} />

    est remplacée par les deux boucles imbriquées :

     span>(RUBRIQUES){titre_mot=Goodies}> span>(ARTICLES){id_rubrique}{doublons goodies}{age>=(#CONFIG{soyezcreateurs/age_goodies,30})}{lang} />  

    Jointures sans critère identifiant

    Dans une boucle avec jointure implicite, si vous ne spécifiez pas l'identifiant sur laquelle la jointure se fait en critère de boucle, SPIP ne pourra plus deviner sur quel type d'objet vous bouclez, et il n'y aura que #ID_OBJET à disposition.

    Par exemple si vous avez en SPIP 2 une boucle :
    span>(FORUMS){par date}{0,4}>#ID_ARTICLE

    il faudra la remplacer par :

    1. span>(FORUMS)>#ID_OBJET

    Fort heureusement, ce besoin est assez rare, car le problème ne se pose pas dés qu'il y a un critère portant sur {id_article} dans la boucle. En effet, le compilateur de SPIP détecte ce critère et s'en sert pour comprendre d'où vient l'#ID_ARTICLE demandé dans le corps de la boucle.

    Personnalisation des urls publiques

    Si vous définissez des modèles d'urls publiques personnalisées, vous devrez renommer les fonctions qui les définissent.

    Par exemple, pour la balise #URL_ARTICLE , renommez la fonction generer_url_article en urls_generer_url_article_dist. Et pour les adresses des documents insérés par les modèles dans un article, renommez la fonction generer_url_document en urls_generer_url_document_dist


lundi 5 novembre 2018

  • Charte d'accueil de SPIP

    SPIP c'est quoi ?

    SPIP est un logiciel libre qui permet de créer des sites internet. Il est placé sous la licence GNU GPL3.
    SPIP est développé et maintenu par sa communauté, avec tendresse.

    La communauté

    La communauté SPIP est un collectif informel, constitué par les personnes contribuant au projet au sens large, comme par exemple, et de façon non limitative, au logiciel, aux plugins, aux traductions, aux productions graphiques, comme aux échanges dans les différents espaces de la galaxie, ou à l'animation du groupe. Indépendante de toute association, fondation ou entreprise, la communauté SPIP s'organise autour de la mutualisation de toutes ces contributions.

    On appelle "galaxie SPIP" l'ensemble des lieux officiels maintenus par la communauté. Il peut s'agir de sites de documentation, de listes de discussion par email, de forum, d'outils pour le code source… Ces lieux sont listés dans un bandeau commun en haut de page des sites, ainsi que dans le site boussole https://boussole.spip.net/

    On appelle "équipe du noyau" ou "équipe du core", le groupe des personnes qui maintiennent et prennent des décisions sur le noyau du logiciel SPIP, ainsi que sur les plugins et squelettes qui sont fournis par défaut. Les nouvelles personnes sont intégrées par co-optation au fil du temps. Une liste de cette équipe peut être trouvée sur notre outil de tickets. C'est cette équipe qu'on peut joindre pour signaler un problème lié à la sécurité à l'adresse spip-team@rezo.net.

    Toute personne inscrite sur un site de la galaxie ou sur une liste de diffusion SPIP est considérée participante à la communauté. Elle peut y trouver de l'aide, des réponses à ses questions et elle peut apporter de l'aide à d'autres utilisateurs. Elle peut aussi participer à maintenir et faire évoluer SPIP, l'un des sites de sa galaxie, ou l'un de ses plugins.

    Buts et valeurs

    Rappelons que SPIP est un logiciel libre, et chaque personne peut l'utiliser et le modifier à sa convenance. Cependant, toute participation doit se faire dans le respect des buts et valeurs promus par le projet initial du minirézo, et notamment :

    • promouvoir et défendre la liberté d'expression de toutes et tous sur Internet ;
    • une défiance vis-à-vis de l'argent (lire cette page pour des précisions) ;
    • le respect de l'identité de chaque personne.

    Cela implique, entre autres, un effort pour internationaliser ses contributions, veiller à ce que le langage, le comportement et le fonctionnement choisis soient ouverts et accueillants, empathiques, non-sexistes, non-racistes et qu'une priorité soit accordée aux besoins associatifs et collectifs sur les besoins marchands.

    Pour suivre ces idées et faire exister le projet dans un mouvement plus large, la communauté SPIP s'inscrit dans la ligne du code de conduite Contributor Covenant : https://www.contributor-covenant.org/fr/version/1/4/code-of-conduct

    Fonctionnement coopératif et gestion des conflits

    Ce code de conduite (Contributor Covenant) pose des principes pour prévenir et aider à régler les problèmes de communication qui pourraient se présenter entre différents membres de la communauté.

    Malgré tout, en cas de conflit inter-personnel, une commission d'arbitrage peut être saisie au cas par cas, qui statue en toute conscience en se basant sur les critères définis ci-dessus, et dispose de toute latitude.

    Droit d'auteur

    En accord avec le droit français, toute contribution partagée dans la communauté, de quelque nature qu'elle soit, reste en tant que telle la propriété de la personne qui l'a conçue, mais se fond dans l'« œuvre collective » qu'est le projet SPIP.

    Toutes les contributions hébergées par la communauté sont « libres » au sens de GNU (licences ​GPL, ​LGPL, ​FDL sans sections invariantes, Art Libre, Creative Commons), de manière à s'intégrer dans le projet global SPIP. En particulier, si la contribution porte sur l'adaptation d'une œuvre antérieure, il convient de s'assurer des conditions de licence de ladite œuvre.

    ... Bienvenue dans SPIP !


mercredi 24 octobre 2018

  • #CONST

    La balise #CONST{nom_de_constante} retourne la valeur de la constante passée en argument.

    Depuis SPIP 3.2

    Exemples

    // Voir le contenu de la partie Composed-By de l'entête HTTP des pages générées par SPIP
    #CONST{_HEADER_COMPOSED_BY}

    retournera par défaut Composed-By: SPIP

    Autre exemple
    Dans le fichier config/mes_options.php :

    1. define('_ID_MOT_TRUC',xx);

    puis dans un squelette

    1. {id_mot=#CONST{_ID_MOT_TRUC}}…

    Voir aussi

    Les balises


mardi 9 octobre 2018

  • Les balises #LOGO_XXX

    Les balises #LOGO_ affichent les logos des objets éditoriaux.

    • #LOGO_SITE_SPIP : logo du site
    • #LOGO_ARTICLE : logo d'un article
    • #LOGO_RUBRIQUE : logo d'une rubrique
    • #LOGO_AUTEUR logo de l'auteur
    • #LOGO_BREVE : logo d'une brève
    • .... et plus généralement #LOGO_NOM_OBJET_EDITORIAL

    Syntaxe de la balise

    Pour afficher le logo

    1. #LOGO_ARTICLE

    produit le code HTML suivant :

    Pour afficher le logo avec un lien vers l'objet

    1. #LOGO_ARTICLE*

    produit le code HTML suivant :

    Retourner le nom du fichier logo

    1. #LOGO_ARTICLE**

    produit le code HTML suivant :
    arton4.jpg

    Retourner le chemin du fichier logo

    1. [(#LOGO_ARTICLE|extraire_attribut{src})]

    produit le code HTML suivant :
    IMG/arton4.jpg?1538235375

    Un timestamp est automatiquement ajouté à l'adresse. Il correspond à la dernière modification du logo. Pour ne pas l'afficher, on peut écrire :

    1. [(#LOGO_ARTICLE|extraire_attribut{src}|supprimer_timestamp)]

    Manipuler graphiquement les logos
    Pour manipuler les logos, on pourra utiliser les filtres images.

    Exemple : afficher un logo en le réduisant en largeur à 220 pixels

    1. [(#LOGO_ARTICLE|image_reduire{220,*})]

    Logo de survol

    Historiquement, si l'option "logo de survol" est activée dans la configuration du site, SPIP permet d'ajouter un deuxième logo pour avoir un effet de survol sur le logo (effet "rollover").

    Dans ce cas,
    - #LOGO_ARTICLE affiche le logo avec l'effet de survol

    Par ailleurs deux balises permettent de récupérer un seul des deux logos :
    - #LOGO_ARTICLE_NORMAL affiche le logo sans survol ;
    - #LOGO_ARTICLE_SURVOL affiche le logo de survol.

    Filtre |adresse (déprécié)

    Le filtre |adresse permet d'ajouter un lien sur le logo.

    1. [(#LOGO_ARTICLE|adresse)]

    Exemple :

    1. [(#LOGO_ARTICLE|#URL_ARTICLE})]

    produit le HTML suivant :

    Nouvelle écriture : ce filtre est à présent à écrire comme argument de la balise, ainsi [(#LOGO_xxx|#URL_yyy)] est remplacé par #LOGO_xxx{#URL_yyy}.

    Filtre |alignement (déprécié)

    Le filtre |alignement permet d'ajouter un alignement sur le logo.

    1. [(#LOGO_ARTICLE|alignement)]

    Permet d'indiquer une valeur d'alignement : left ou right

    Exemple :

    1. [(#LOGO_ARTICLE|right)]

    produit le HTML suivant :

    Nouvelle écriture : ce filtre est à présent à écrire comme argument de la balise, ainsi [(#LOGO_xxx|left)] est remplacée par #LOGO_xxx{left}.

    Il est fortement recommandé d'utiliser #INSERT_HEAD_CSS pour fournir la feuille de style gérant les alignements.

    Le critère {logo}

    Au niveau des boucles, le critère {logo} permet de ne sélectionner que les articles (ou rubriques, etc) qui disposent d'un logo. Il fonctionne aussi dans la boucle (HIERARCHIE). Le critère inverse {!logo} liste les objets qui n'ont pas de logo.

    span>(RUBRIQUES){racine}{logo}{par num_titre}>
    #LOGO_RUBRIQUE
    

    Retourne les logos des rubriques à la racine qui possèdent un logo.

    Héritage des logos rubriques

    - #LOGO_ARTICLE_RUBRIQUE affiche le logo de l'article, éventuellement remplacé par le logo de la rubrique s'il n'existe pas de logo spécifique à l'article.

    Par défaut, la balise #LOGO_RUBRIQUE affiche le logo de la rubrique en cours et s'il n'est pas défini, va automatiquement chercher s'il existe un logo pour la rubrique parente de manière récursive.

    Pour désactiver cette fonction d'héritage, on peut définir la constante _LOGO_RUBRIQUE_DESACTIVER_HERITAGE.

    Pour définir le logo des rubrique par défaut, on pourra se rendre dans le menu "Édition > Rubriques" (http://monsite.org/ecrire?exec=rubriques).

    Convention de nommage

    Les logos sont renommés par SPIP au moment de l'upload avec la convention suivante :
    IMG/type-etatX.ext
    où :

    • type est le type d'objet éditorial rattaché au logo : art (article), rub (rubrique) ...
    • etat on, off est l'état du logo normal ou survol
    • X est l'id de l'objet éditorial
    • ext est l'extension du fichier(jpg, png ou gif)

    Par exemple : IMG/arton4.jpg est le logo de l'article n°4

    Historique

    La syntaxe de balise #LOGO_ a beaucoup évolué depuis les premières versions de SPIP. Pour connaitre l'évolution de la syntaxe, on pourra consulter la page de présentation de SPIP 2.1.


vendredi 7 septembre 2018

  • |in_any

    Usage : [(#BALISE|in_any{tab,def})]

    Le filtre |in_any sert à tester la présence de la valeur dans un tableau de valeur. Il fonctionne donc exactement comme la fonction php in_array avec 2 différences :

    • Si le 1er argument tab passé au filtre |in_any n'est pas un tableau, in_array provoque une erreur, alors que in_any n'en provoque pas : dans ce cas, in_any tente de désérialiser cet argument afin, en cas de succés, de le traiter comme un tableau.
    • S'il y a un 2e argument def au filtre, c'est cette valeur qui est retournée dans le cas où tab n'est pas un tableau.

    Exemple :

    [in_array provoque une erreur (#VAL{10}|in_array{patablo}) ] [in_any ne provoque pas d'erreur et renvoie : '(#VAL{10}|in_any{patablo,pas un tableau})'] 
    [(#GET{age}|in_any{#ENV{ages_possibles}}|oui) Bienvenue]

    Voir aussi : le filtre |find a la même fonction, mais avec des arguments inversés.


samedi 1er septembre 2018

  • _MOTS_CREATION_RETOUR_MOT_CREE

    La constante _MOTS_CREATION_RETOUR_MOT_CREE permet de changer le comportement de SPIP à la création d'un mot clé : avec cette constante, on arrive sur la page des propriétés du mot nouvellement créé [1].

    Il est possible de personnaliser cette valeur dans votre fichier config/mes_options.php (voir l'article qui lui est consacré).

    Exemple :

    // Revenir à la page de propriétés du mot après sa création
    if (!defined('_MOTS_CREATION_RETOUR_MOT_CREE')) define('_MOTS_CREATION_RETOUR_MOT_CREE', true);

    [1] Par défaut, SPIP a un comportement dérogatoire pour la création des mots clé : alors que les autres objets de SPIP font arriver sur la page des propriétés de l'objet nouvellement créé, dans le cas des mots clés, SPIP ramène à la page qui contenait le bouton de création (soit la page listant tous les groupes de mots, soit la page du groupe)

    Cette constante est disponible à partir de SPIP 3.1.9 et SPIP 3.2.2


lundi 9 juillet 2018

  • #FORMULAIRE_OUBLI

    Le formulaire #FORMULAIRE_OUBLI permet à un auteur de réinitialiser son mot de passe.

    Pour cela, il indique son mail et le site lui envoie un mail qui contient un lien de validation donnant accès au formulaire de modification de mot de passe (#FORMULAIRE_MOT_DE_PASSE).


  • #FORMULAIRE_MOT_DE_PASSE

    Le formulaire #FORMULAIRE_MOT_DE_PASSE permet à l'auteur connecté de changer son mot de passe lorsqu'il a authentifié son adresse email grâce au #FORMULAIRE_OUBLI.


lundi 4 juin 2018

  • Méthodes alternatives pour installer SPIP

    Les besoins et les technologies évoluant, des initiatives ont vu le jour au sein de la communauté SPIP pour réaliser installations et mises à jour d'un ou plusieurs sites.

    Le plus souvent, il s'agit d'une surcouche aux méthodes recommandées.

    Outils en ligne de commande « maison »

    Pour celles et ceux ayant accès via un terminal à leurs serveurs de production, les outils ci-dessous simplifient l'utilisation de l'outil subversion :

    • Installer et mettre à jour SPIP avec SVN est un guide interactif qui simplifie le choix des commandes svn spécifiques à utiliser selon les circonstances.
    • Bien plus qu'un assistant à l'installation, SPIP-Cli est un outil d'exploitation de vos sites SPIP.

    Distributions Linux

    Debian

    Fedora

    • À ce jour, il ne semble pas exister de paquet RPM pour SPIP, et c'est bien dommage.

    Docker

    Docker_(logiciel) automatise le déploiement d'applications dans des conteneurs logiciels.

    Plusieurs personnes ont imaginé leurs propres recettes pour utiliser cet outil :

    Composer

    Composer est un outil de gestion de dépendances en PHP. Il vous permet de déclarer les bibliothèques dont votre projet dépend et il va les gérer (installer / mettre à jour) pour vous.

    • SPIPRemix est une maquette expérimentale visant à faire la démonstration de l'intégration de composer dans le développement de SPIP.

Traduction

Sites favoris


114 sites référencés au total

Brèves

30 mai 2014 - Sur Facebook : Lac de Créteil - 94000 - Val de Marne -...

Lac de Créteil - 94000 - Val de Marne - France

24 février 2014 - Nous contacter

Pour nous contacter, cliquez sur l’enveloppe.http://laccreteil.fr/spip.php?page=...