Système de
publication pour l’Internet |
1. SPIP, un système de publication
9. Les rédacteurs/administrateurs
11. Interface graphique du site public
15. Sauvegarde et exportation de la base de
données
1. La liste des utilisateurs de SPIP:
spip@rezo.net
1. Les hébergeurs où SPIP NE FONCTIONNE PAS ou
très mal
3. Les hébergeurs F.A.I. (Fournisseurs d’Accès à
Internet) GRATUITS
4. Hébergeurs associatifs et/ou alternatifs
5. Hébergeurs payants traditionnels
2. Installation automatique (« spip_loader »)
1. Sauvegardez votre base de données
2. Installez la nouvelle version de SPIP
3. Déclenchez la mise-à-jour de
votre site
D. L'HISTOIRE MINUSCULE ET ANECDOTIQUE DE SPIP
4. Documents joints et documents multimédia
10. Accessibilité de l’espace privé
11. Petits ajouts et corrections
2. Création automatique de vignettes
4. Astuces venant compléter l'arsenal du
multilinguisme
10. Fonctionnalités expérimentales
14. Suite de l’internationalisation
15. Autres modifications importantes
16. Corrections et ajouts mineurs
2. Outils d’aide à la publication
1. Les raccourcis typographiques
8. Date de publication en ligne
9. La date de publication antérieure
14. Articles en cours d’édition
1. La structure hiérarchique des rubriques
3. Le lien hypertexte des brèves
1. Insérer des images dans le texte
3. Installer des fichiers par FTP
1. Les messages entre utilisateurs
4. Configuration personnelle de la messagerie
interne
1. Nom et adresse de votre site
3. Publication des articles post-datés
4. Fonctionnement des forums publics
5. Activer/désactiver le système de brèves
7. Les statistiques des visites
8. Envois automatique de mails
9. Activer/désactiver le moteur de recherche
K. Configuration de l’interface personnelle
1. Interface simplifiée / interface complète
1. Pour chaque type de document, un couple de
fichiers
2. Le principe de fonctionnement du cache
5. Une interface différente dans le même site
6. Que peut-on mettre dans un fichier .HTML
3. Les balises à l’intérieur des boucles
3. Des critères d’environnement en cascade
4. Boucles incluses et boucles successives
6. Court-circuiter le traitement par SPIP
3. Les balises de cette boucle
3. Les balises de cette boucle
3. Les balises de cette boucle
3. Les balises de cette boucle
3. Les balises de cette boucle
3. Les balises de cette boucle
K. La boucle SITES (ou SYNDICATION)
3. Les balises de cette boucle
3. Les balises de cette boucle
3. Les balises de cette boucle
O. Les CRITERES COMMUNS à toutes les boucles
3. Affichage en fonction de la date
4. Affichage d’une partie des résultats
5. Affichage entre les résultats
P. Les balises propres au site
1. Balises définies à la configuration
2. Inscription, authentification...
1. Les filtres de mise en page
7. Ajouter ses propres fonctions
8. Filtres avec des paramètres
1. Comment décompter des visites
4. Critère de date, d’âge, et d’âge relatif
5. La date de rédaction antérieure
6. Un exemple de sommaire de site trié par date
W. EXPOSER un article dans une liste
B. Un squelette plusieurs articles
1. La langue principale du site
B. Un mémento des raccourcis SPIP
C. FAQ de l’administrateur SPIP
3. Les différents types de navigation
D. Quels sont les éléments gérés par SPIP ?
1. La hiérarchie des rubriques
VIII. Suivre la vie du site (fichiers backend et
calendrier ICAL)
B. Indiquer l’adresse d’une mailing-list
2. Indiquer les informations de la mailing-list
dans SPIP
1. S’« abonner » à un site Web
IX. Guide du webmestre et du bidouilleur
1. Sécurité par défaut de SPIP
2. Protéger ses données sous IIS : une
étape de plus
B. Qu’est-ce que les fichiers « dist » ?
E. Contribuer au développement de SPIP
1. Règles de présentation et d’écriture
X. Guide des fonctions avancées
A. SPIP et les feuilles de style
1. Où se trouve la définition de ces feuilles de
style ?
7. Ligne de séparation horizontale
B. <INCLURE> d’autres squelettes
1. Dans un contexte multilingue
C. Réaliser un site multilingue
1. Préalable : qu’est-ce qu’un site
multilingue ?
5. Boucles et balises : comment faire
6. Des squelettes internationaux pour un site
massivement multilingue
D. Internationaliser les squelettes
1. Pourquoi créer des squelettes
multilingues ?
2. Méthode des fichiers de langue
3. Des squelettes séparés pour chaque langue
E. Utiliser les URLs personnalisés
1. Choisir le type d’URLs apparentes
2. Programmer la traduction des adresses
apparentes en adresses réelles.
3. Générer les URLs apparentes dans les pages
SPIP
4. Transition d’un type d’URLs à l’autre
G. Les variables de personnalisation
1. Où indiquer ces variables ?
3. Les variables pour les forums publics
H. Tidy : validation XHTML 1.0
K. Insérer des formules en LaTeX
L. SPIP 1.8 : l’interface graphique
1. « The “Un-seul-click”™ interface for the
SPIP-user »
2. Changements de statut dans les listes
3. Des vignettes et des rotations
5. Interface purement textuelle
6. Espaces plus grands (ou pas...)
10. Vous n’aimez pas le vert ?
M. La structure de la base de données
5. Indexation (moteur de recherche)
XI. Initiation : utiliser les feuilles de style
avec SPIP
1. Pourquoi les feuilles de style ?
B. Des styles qui ont de la « class »
1. Les styles définis par SPIP
C. Une typographie personnalisée
3. Appliquer un traitement différencié
D. Ils sont beaux mes formulaires
A. Afficher automatiquement selon la date ou selon un
ordre imposé
B. Trier des articles par ordre alphabétique, sauf un
qu’il faut afficher en premier
C. Plusieurs logos pour un article
2. Mise en place des documents et choix des noms
3. Afficher « spip_logo » en Une du
site
4. Exclure ces documents spécifiques de
l’affichage normal des documents joints
5. Afficher toujours un gros logo en haut de
page
6. Afficher un titre graphique
D. Afficher les derniers articles de vos rédacteurs par
rubrique
1. Création du fichier myauteur.php3
E. Afficher des éléments par lignes dans un tableau
F. Ne pas afficher les articles publiés depuis plus
d’un an
G. Présenter les résultats d’une recherche par secteurs
H. Afficher le nombre de messages du forum lié à un
article
I. Un menu déroulant pour présenter une liste
d’articles
J. Remplir les meta-tags HTML des pages d’article
XIII. Le développement de SPIP et ses outils
XIV. Tutoriel : Utilisation avancée des boucles et des
mots-clés
1. À qui s’adresse ce document ?
3. Quelles autres connaissances techniques sont
nécessaires ?
5. Comment utiliser ce tutorial ?
6. La progression de ce tutorial
B. Le but du jeu : un site consacré aux jeux vidéo
2. Quelles sont les difficultés que présente un
tel site ?
4. Que deviennent les machines et les genres
d’articles ?
D. Mise en place de la structure
3. Pour quelle(s) machine(s) ? Quel type
d’article ?
F. Première version du squelette des articles
2. Récupérer les infos sur le jeu
1. Les articles contenus dans cette rubrique
3. Les rubriques sans articles
4. Les rubriques de jeu (avec des articles)
H. Les mots-clés dans les articles
2. Dans la même rubrique, au sujet du même jeu
3. Les jeux dans la même catégorie
I. Les mots-clés dans les rubriques
K. Et encore d’autres moyens de se compliquer la vie !
1. L’attribution d’une note à un jeu
2. Intégrer la note dans les squelettes
3. La date de sortie officielle des jeux
4. Afficher la date dans les articles
L. Quelques sommaires alternatifs
1. Le tableau des meilleures notes
M. Une première version du sommaire
N. Un sommaire pour chaque machine
1. Le fichier
« sommaire_machine.php3 »
2. Le squelette du sommaire par machine
O. Référencer des articles sur le Web
2. Le squelette forum_jeu.html
4. Afficher chaque message :
message.php/message.html
5. Les liens depuis les autres pages
SPIP est un logiciel libre distribué sous licence GPL, aussi appelée en français Licence Publique Générale GNU. Cette licence vous garantit les libertés suivantes :
q la liberté d’installer et d’utiliser SPIP pour quelque usage que ce soit ;
q la liberté d’étudier le fonctionnement de SPIP et de l’adapter à vos propres besoins en modifiant le code source, auquel vous avez un accès immédiat puisque SPIP est intégralement programmé en PHP ;
q la liberté de distribuer des copies à qui que ce soit, tant que vous n’altérez ni ne supprimez la licence ;
q la liberté d’améliorer SPIP et de diffuser vos améliorations au public, de façon à ce que l’ensemble de la communauté puisse en tirer avantage, tant que vous n’altérez ni ne supprimez la licence.
Ce programme est un logiciel libre ; vous pouvez le redistribuer
et/ou le modifier conformément aux dispositions de la Licence Publique Générale
GNU, telle que publiée par la Free Software Foundation ; version 2 de la
licence, ou encore (à votre choix) toute version ultérieure.
Ce programme est distribué dans l’espoir qu’il sera utile, mais
SANS AUCUNE GARANTIE ; sans même la garantie implicite de COMMERCIALISATION ou
D’ADAPTATION A UN OBJET PARTICULIER. Pour plus de détails, voir la Licence
Publique Générale GNU .
Un exemplaire de la Licence
Publique Générale GNU doit être fourni avec ce programme ; si ce n’est pas
le cas, écrivez à la Free Software Foundation Inc., 675 Mass Ave, Cambridge, MA
02139, Etats-Unis.
Copie de la licence à l’adresse
http://www.gnu.org/licenses/gpl.html
SPIP, Système de Publication pour l’Internet
Copyright © 2001-2004, Arnaud Martin, Antoine Pitrou et Philippe
Rivière pour le Minirézo.
Version SPIP 1.8 – avril/mai
2005
Compilation du document
par Michaël Fréva
SPIP est un Système de Publication pour l’Internet. Kesako ? Il s’agit d’un ensemble de fichiers, installés sur votre compte Web, qui vous permettent de bénéficier d’un certain nombre d’automatismes : gérer un site à plusieurs, mettre en page vos articles sans avoir à taper de HTML, modifier très facilement la structure de votre site... Avec le même logiciel qui sert à visiter un site (Netscape, Microsoft Explorer, Mozilla, Opera...), SPIP permet de fabriquer et de tenir un site à jour, grâce à une interface très simple d’utilisation.
D’autres systèmes de publication existent ; chacun présente ses spécificités. Un des plus connus actuellement est phpNuke ; il impose une structure assez rigide pour le site, sous forme de portail muni de courts articles. SPIP est plus souple, et orienté vers la création d’un site structuré comme un magazine : c’est-à-dire avec des rubriques, sous-rubriques (et ainsi de suite), dans lesquelles sont insérés des articles et des brèves qui peuvent être complétés de forums de discussions.
SPIP est un logiciel libre distribué sous Licence Publique Générale GNU (GNU General Public License ou GPL). Les besoins logiciels et matériels de SPIP sont raisonnables et se trouvent même chez certains hébergeurs gratuits (voir la Foire Aux Questions et le manuel d’installation pour plus de détails - ou, pour résumer à l’extrême : PHP+MySQL).
SPIP est distribué gratuitement sur ce site.
L’intérêt de SPIP est de...
q gérer un site Web de type magazine, c’est-à-dire composé principalement d’articles et de brèves insérés dans une arborescence de rubriques imbriquées les unes dans les autres. Voir la liste complète des caractéristiques de SPIP pour plus de détails.
q séparer entièrement, et distribuer entre différentes personnes, trois types de tâches : la composition graphique, la contribution rédactionnelle via proposition d’articles et de brèves, et la gestion éditoriale du site (tâche qui comprend l’organisation des rubriques, la validation des articles proposés...).
q dispenser le webmestre et tous les participants à la vie du site d’un certain nombre d’aspects fastidieux de la publication sur le Web, ainsi que de connaissances techniques trop longues à acquérir. L’installation de SPIP se réalise au moyen d’une interface simple et pas à pas, au terme de laquelle vous pouvez commencer à créer vos rubriques et articles.
SPIP a les caractéristiques
suivantes...
Pour le(s) rédacteur(s) et
administrateur(s)
q Une interface Web intuitive rend extrêmement simples la proposition d’articles et de brèves ainsi que la gestion éditoriale du site. De plus, des raccourcis typographiques permettent de mettre en forme un texte sans avoir à utiliser le langage HTML, rendant ainsi la contribution rédactionnelle accessible à tous, et aussi simple que l’écriture d’un e-mail.
Pour le webmestre
q L’aspect graphique et la navigation sont définis par des squelettes HTML (ou « formats types ») définissant chacun une « vue » (par exemple : une vue pour la page d’index, une autre montrant une rubrique et un résumé de son contenu, une troisième pour le détail d’un article, une quatrième pour le détail d’une brève). La façon dont est inséré le contenu rédactionnel du site dans ces pages est défini par un certain nombre de pseudo-tags HTML relativement faciles à maîtriser.
q SPIP ne restreint pas les possibilités graphiques et navigationnelles du site. Les squelettes HTML étant entièrement définis par le webmestre du site, il est possible de gérer certains éléments du site avec SPIP et le reste à la main ou même avec d’autres systèmes de publication (à condition que ces derniers soient aussi tolérants que SPIP, bien sûr).
Pour les visiteurs
q Un système de cache sur la partie publique du site accélère le site en évitant un grand nombre de requêtes à la base de données, et joue en outre un rôle de garde-fou contre les plantages de la dite base (fréquents sur des serveurs « chargés ») : dans ce cas, le site reste disponible de façon transparente, même si toute modification des contenus est impossible (y compris la contribution aux forums).
q Un moteur de recherche et d’indexation intégré à SPIP, s’il est activé par le webmestre, permet d’effectuer des recherches sur l’ensemble du contenu public du site.
Des inconvénients
Pour l’instant, la souplesse de SPIP implique qu’un peu d’efforts d’apprentissage sont nécessaires au webmestre pour modifier la présentation par défaut. Contrairement à des systèmes très contraints comme phpNuke où vous pouvez changer les couleurs et le logo en pressant simplement un bouton (mais c’est tout ce que vous avez le droit de faire), le webmestre sous SPIP doit apprendre les quelques rudiments d’un pseudo-HTML lui permettant ensuite de faire à peu près ce qu’il veut.
SPIP est livré avec un format d’interface de navigation complet; dès que vous aurez commencé à créer le contenu de votre site, il pourra être immédiatement visité, et adoptera l’interface graphique fournie par défaut. Le webmestre du site peut bien entendu fabriquer sa propre interface graphique s’il le désire.
A l’avenir, il est prévu que plusieurs présentations soient fournies avec SPIP, permettant à la majorité des webmestres d’en réutiliser une qui leur convienne pour minimiser l’effort de personnalisation.
Exemples
L’exemple historique de l’utilisation de SPIP est le webzine uZine2 (c’est le code, au départ spécifique, de ce site, qui a été repris pour réaliser le SPIP générique). Parmi d’autres sites fonctionnant sous SPIP, citons Le Monde diplomatique et Vacarme.
Poursuivre...
Pour aller plus loin, et vous lancer sous SPIP, il vous sera utile de lire la documentation, les exemples et les « premiers pas » proposés dans cette rubrique. Des listes de diffusion sont également à votre disposition pour échanger questions, trucs et astuces. A bientôt !
L’installation de SPIP est particulièrement simplifiée par rapport à d’autres systèmes :
q Aucune connaissance technique particulière n’est nécessaire (ni PHP, ni MySQL) pour procéder à son installation.
q La configuration se fait directement en ligne, au travers d’une interface graphique très simple (il n’est pas nécessaire, en particulier, d’aller modifier un fichier de configuration avec des codes abscons).
q Nous distribuons une version unique de SPIP ; celle-ci peut évoluer au cours du temps en fonction des améliorations, mais nous faisons très attention à ne pas compliquer en développant des « patches » qu’il faudrait aller chercher à droite ou à gauche (pour adapter SPIP à tel hébergeur par exemple).
Le site public fabriqué à partir de SPIP offre les caractéristiques suivantes :
q Interface entièrement adaptable par le webmestre sans connaissances de PHP ni de MySQL ; l’interface de SPIP se programme en HTML, auquel nous avons ajouté un langage relativement simple ; SPIP n’impose donc pas une mise en page rigide (à la manière des « trois colonnes » si caractéristiques de phpNuke).
’interface en HTML classique n’est pas la seule forme de navigation que l’on peut présenter aux visiteurs du site. Les mêmes informations (le même contenu) peuvent être présentées dans des formats très différents. On peut par exemple fournir, en plus de la navigation Web classique : q des fils de syndication au format XML/RSS, q un calendrier au format iCalendar, q une navigation Wap (au format WML), q une navigation Macromedia Flash (pas d’exemple en format libre, malheureusement)... q et tout autre format que l’on se donnera le mal de maîtriser (cHTML pour iMode, XPressTags, XML pour Indesign...). |
q SPIP intègre un système de cache pour chaque page individuelle : les pages sont calculées (à partir des informations de la base de données) individuellement, et stockées dans un fichier de cache ; ainsi le serveur n’est pas ralenti par un trop grand nombre d’appels MySQL, et le site est toujours accessible même en cas de panne du serveur de bases de données.
q SPIP intègre un petit moteur de recherche basé sur un système d’indexation par mots.
La structure d’un site sous SPIP est construite sur une hiérarchie de rubriques. Il n’y a virtuellement pas de limite au nombre de rubriques : une rubrique peut contenir autant de sous-rubriques que nécessaires, qui elles-mêmes contiennent des sous-rubriques, etc. On construit ainsi la structure de son site en imbriquant des rubriques et des sous-rubriques.
L’objet principal permettant de publier des informations sous SPIP est l’article. On peut placer autant d’articles que nécessaire, dans n’importe quelle rubrique.
q La rédaction des articles est très simple, elle se déroule via une interface graphique sur le Web.
q Un article est constitué de plusieurs éléments qui permettent de le structurer : titre, surtitre, soustitre, descriptif, chapeau, texte principal, post-scriptum.
q Les règles de base de la typographie française sont appliquées automatiquement (espaces insécables avant les points d’interrogation, d’exclamation, etc.).
q Des raccourcis mnémotechniques facilitent l’enrichissement typographique, la création de liens hypertexte, de notes de bas de page... mettre en page un article sous SPIP est aussi facile que d’écrire un email.
q L’interface graphique permet d’inclure simplement des images dans les articles, et chaque article peut être signalé par son propre logo.
q On peut indiquer, pour chaque article, un ou plusieurs mots-clés.
q La date de mise en ligne se gère automatiquement (on peut cependant la modifier si nécessaire) ; une seconde date peut être associée à un article, par exemple pour indiquer une date de publication originale (par exemple, un article publié antérieurement dans un magazine papier).
q Redirections (articles « fantômes ») : SPIP permet de fabriquer des articles-fantômes, intégrés dans la structure du site et affichés dans le contenu des rubriques, mais qui en réalité renvoient vers une page dont l’adresse est spécifiée par le rédacteur (sur le même site, ou même sur un autre site). Cette fonction facilite le passage d’un site déjà existant vers SPIP, par l’intégration de contenus statiques préexistants.
En complément des articles, SPIP intègre un système de brèves, qui facilite la publication de courtes notes d’information, telles des revues de presse (ou des revues de Web).
q Afin de faciliter la structuration et le positionnement des brèves, on ne peut installer des brèves que dans les principales rubriques du site (les rubriques placées à la racine du site).
q La structure des brèves est simplifiée : un titre et le texte de la brève ; chaque brève peut être complétée très simplement d’un lien hypertexte.
q La gestion de la publication d’une brève est simplifiée (deux boutons : publier ou refuser).
q Chaque brève peut être signalée par son propre logo.
q L’administrateur du site peut décider de désactiver l’usage des brèves sur l’ensemble du site.
SPIP intègre un système de forums.
q Les forums peuvent être associés aux articles (un forum par article), aux rubriques ou aux brèves. Le webmestre pourra programmer son interface pour que chaque article dispose de son propre forum, ou pour que plusieurs articles d’une même rubrique partagent le même forum, etc.
q SPIP permet de choisir entre plusieurs types de forums : les forums « libres » (modérés à postériori, les contributions apparaissent immédiatement, les administrateurs peuvent éventuellement supprimer ensuite un message indésirable) ; les forums modérés à priori (les contributions n’apparaissent qu’après avoir été validées par un administrateur du site) ; les forums sur abonnement (chaque intervenant doit, pour pouvoir poster, d’abord indiquer son adresse email pour recevoir un mot de passe lui permettant de poster ses contributions).
SPIP intègre également un système de forums privés, consacré à la discussion entre les différents rédacteurs du site, et cela dans l’espace privé.
Un article peut être transformé en pétition en ligne en quelques clics.
q Les pétitions de SPIP sont validées par email automatiquement : un signataire reçoit un message de confirmation qui permet de vérifier la validité des signatures.
q On peut configurer très simplement le type de pétition : ainsi imposer une seule signature par adresse email, imposer qu’un site Web soit indiqué dans la pétition (dans ce cas, la validité de l’URL est vérifiée automatiquement), accepter ou non des messages accompagnant les signatures.
SPIP intègre un système très simplifié de statistiques, permettant d’évaluer la popularité des articles et des rubriques.
Un site sous SPIP peut être géré par une seule personne, ou être réalisé par un groupe de rédacteurs.
q SPIP propose deux niveaux d’accès : les administrateurs, qui gèrent notamment la structure du site et la validation des articles, et les rédacteurs, qui proposent des articles.
q Le nombre de rédacteurs et d’administrateurs est illimité.
q On peut décider d’offrir aux utilisateurs du site public de s’inscrire pour devenir rédacteur (la procédure d’inscription est alors gérée automatiquement par SPIP).
q Chaque auteur peut se voir associer un logo personnel téléchargeable depuis l’interface (par exemple une photo d’identité).
Les sites réalisés sous SPIP, phpNuke, ou d’autres systèmes, fournissent un fichier dynamique indiquant leurs dernières publications. SPIP peut analyser de tels fichiers et ainsi indiquer les nouveautés d’autres sites :
q on peut ajouter autant de sites syndiqués que l’on veut ;
q les sites syndiqués sont associés aux rubriques de son propre site ; ainsi, on peut associer à une rubrique thématique les liens vers des sites traitant du thème précis de la rubrique.
L’interface graphique du site public est très souple. Grâce à un langage très simple (mais propre à SPIP), on peut réaliser à peu près n’importe quelle interface graphique.
Il n’est en particulier pas nécessaire de connaître PHP et MySQL pour réaliser une interface graphique originale sous SPIP.
Cependant, le système de cache est totalement compatible avec PHP : le webmestre peut, s’il le désire, intégrer des fonctions PHP dans ses formats-types (squelettes), ou des passerelles CGI. On peut donc enrichir SPIP avec des scripts spécialisés pour compléter ou remplacer des fonctions manquantes (par exemple : compteur, moteur de recherche plus puissant, etc.).
La partie privée qui permet de gérer le site dispose d’une interface graphique complète, très simple d’utilisation.
q Cette interface s’adapte en fonction des activités de chaque rédacteur ou administrateur, et en fonction de l’activité du site. Ainsi chaque auteur a-t-il accès rapidement à ses propres articles, et les articles proposés à la publication sont signalés à tous les utilisateurs. De même l’interface est différente selon que l’on est rédacteur ou administrateur.
q Chaque utilisateur peut personnaliser son interface. Il peut choisir entre une interface simplifiée, qui n’offre que les fonctions principales, et une interface complète. Il peut également modifier quelque peu l’habillage graphique de l’interface.
q Lorsqu’un site accueille plusieurs rédacteurs, SPIP devient un outil de travail coopératif : débats autour des articles, système de validation, travail à plusieurs sur un même article...
Si l’interface graphique du site public et la gestion du contenu sont, dans SPIP, strictement séparées (par exemple, on ne fixe pas la couleur du fond d’écran du site public dans l’espace privé), il est cependant possible de configurer certains comportements du site dans l’espace privé :
q accepter ou refuser certains éléments du contenu des articles : ainsi on peut décider d’interdire l’utilisation des surtitre, soustitre, descriptif, chapeau ou post-scriptum, ou la date de publication antérieure et les mots-clés ;
q configurer (ou désactiver) les forums publics ;
q indiquer si l’on publie les articles avant la date de publication qu’on leur a fixé (cette option permet par exemple de partir en vacances, le site publiant des articles pendant cette absence) ;
q désactiver le système de brèves (en effet, certains sites n’en ont pas l’usage ; les désactiver permet de simplifier l’interface pour les rédacteurs) ;
q activer ou désactiver les statistiques ;
q activer ou désactiver le moteur de recherche.
q Afin de faciliter le suivi éditorial du site, plusieurs options sont offertes :
q envoi des contributions des forums aux auteurs des articles ; lorsqu’un visiteur du site poste un message sous un article, l’auteur de cet article en est informé par mail, ce qui lui permet de suivre l’activité de son article par mail ;
q suivi de l’activité éditoriale ; si le site est le fruit d’une équipe de rédacteurs, on peut signaler automatiquement les annonces importantes de l’activité éditoriale à une adresse email (dans l’idéal, une liste de de diffusion) ; ainsi, lorsqu’un article est publié ou proposé à la publication, cette liste en est informée ;
q annonce des nouveautés ; SPIP peut envoyer automatiquement, selon une fréquence fixée par les administrateurs, un courrier électronique recensant les dernières publications sur le site.
Le webmestre du site peut réaliser une sauvegarde de sa base de données (un fichier est alors créé) ; si le serveur le permet, cette sauvegarde sera réalisée dans un fichier compressé, facilitant ainsi sa récupération par FTP. SPIP intègre bien entendu la fonction qui permet d’importer un tel fichier.
L'article http://www.spip.net/fr_article884.html recense quelques sites fonctionnant sous SPIP.
Si vous êtes webmestre d’un site fonctionnant sous SPIP, merci de remplir le formulaire ci-joint (uniquement des sites réellement en fonctionnement, SVP). Indiquez également si vous publiez vos squelettes ou si vous acceptez de les fournir à ceux qui vous en feraient la demande.
Les espaces d’entraide entre utilisateurs de SPIP sont nombreux et très actifs. Chacun est donc invité à faire son possible pour ne pas les surcharger inutilement : les personnes qui interviennent le font à titre bénévole et ne répondront pas à des demandes trop pressantes ou déplacées.
Avant tout, commencez par bien consulter la présente documentation, notamment les FAQ qui y figurent ; beaucoup de questions y sont abordées. De nombreux utilisateurs de SPIP tiennent à jour le site des contributions externes SPIP-CONTRIB : c’est une mine d’informations et de solutions à des problèmes variés.
Une dernière recommandation : ne multipliez pas inutilement les appels à l’aide en postant le même message en différents endroits (listes de discussion, forums...). C’est le meilleur moyen de vous faire mal voir des personnes qui auraient pu vous apporter de l’aide.
Liste de discussion
Cette liste est destinée à toutes les questions autour de l’utilisation de SPIP. C’est la liste sur laquelle vous aurez le plus de chances d’obtenir de l’aide.
Il s’agit donc de notre liste principale : si vous êtes webmestre d’un site SPIP, rédacteur d’un site SPIP, et que vous voulez discuter de différents problèmes liés à l’utilisation de SPIP, c’est là qu’il faut vous rendre...
Si vous débutez avec SPIP, nous vous conseillons vivement de vous abonner à cette liste des utilisateurs (tout cela est évidemment gratuit). Cette liste est désormais très animée, réactive, et vous y obtiendrez rapidement de nombreux conseils et des réponses à toutes sortes de questions.
Cette liste est très active. Avant de poster, merci de consulter ses archives pour voir si le sujet n’a pas déjà été abordé. Merci également de consulter la présente documentation (en particulier les FAQ). |
Le présent site vous propose un forum de discussion. Il est recommandé pour les utilisateurs occasionnels. Comme sur tout forum, merci de consulter les messages déjà postés pour voir si votre question n’a pas déjà été posée précédemment et la réponse publiée.
Une liste d’hébergeurs compatibles ou non avec SPIP est désormais disponible sur le Spikini de SPIP-contrib.
N’hésitez pas à contribuer à l’enrichissement de cette liste, il s’agit d’un outil apprécié par de nombreux utilisateurs débutants.
Il faut savoir que pour faire fonctionner SPIP, il faut un hébergeur qui dispose de MySQL (base de données) et de PHP (langage de script).
Listes en date
du mois d’avril 2005 Source : http://www.spip-contrib.net/spikini/ListeDesHebergeurs |
q Oleane : Cela ne fonctionne pas (détail technique : il paraît que l’on ne peut utiliser la base mysql que par phpmyadmin, pas par php !!! ). En fait, ça marche avec Oléane mais impossible d’avoir une fonction phpmail (confirmation de la part des services techniques). Sinon, l’installation se passe normalement en manuel.
10/06/2004 : j’ai un site SPIP 1.7 chez Oléane et ça fonctionne très bien, sans aucune restriction. C’est le site d’une commune (www.ville-annoeullin.fr), l’hébergement m’a été imposé. Bonne disponibilité de la plate-forme. Mais support mauvais, ce qui est un comble au prix (élevé) que ça coûte !
24/09/2004 :
Ce n’est pas trivial, mais il faut retrouver le nom de sa base de données. Pour
cela, il faut vous connecter sur le site http://sql.fr.oleane.com/ , s’y
connecter et prendre l’url situe dans les YY : " Database foo running
on YYYYY". Mettez l’adresse YYYYY dans la configuration de Spip et ça doit
marcher (ici, ça tourne)
q Lycos-Multimania : les publicités envahissantes provoquent des erreurs d’affichage. En effet, certaines pubs créent des frames au dessus de votre SPIP ce qui bloque certaines fonctionnalités, surtout dans la partie administration (recalcul de pages, récupération de la base, mise à jour de SPIP...). En insistant, en recalculant et en relançant le login dans l’espace privé on fini par arriver à se connecter. Le problème est moins criant avec les version de SPIP 1.7.2 et 1.8.
q Wanadoo et Voila : le fournisseur d’accès Wanadoo ne permet pas, pour l’instant, l’utilisation de PHP ou MySQL pour les pages personnelles. (11/03/2005 :) Si ! mais le php/sql ainsi que l’ip fixe faisait traditionnellement partie du forfait Pro !!! Cependant il suffisait de demander. Disponible en payant : offre premium php4 pour 9 euros ttc par mois. 150 Mo d’espace web, PHP 4 et 30 Mo pour votre base MySQL phpMyAdmin, htaccess avec une interface
Il
n’en reste plus beaucoup (voir aussi les hébergeurs F.A.I.)
q Lycos-Multimania : on peut considérer qu’il est
gratuit si ce n’est les publicités envahissantes qui bouffent littéralement un
bon cinquième de l’affichage et détruisent l’habillage de la page. Hormis les
problèmes sus-cités, il permet de disposer de 50Mo d’hébergement gratuit (mais
c’est vraiment pas de tout repos). Il existe un tutoriel pour l’installation
sur Lycos. (<= Cette page conduit à une erreur 404, le
02/03/05)
q Médicalistes : propose un hébergement gratuit (web,
mail, MySQL,
domaines, etc...) à condition que le contenu à héberger rentre dans le domaine
de la santé (associations de malades ou individuels, professionnels de la
santé). C’est aussi un hébergeur associatif, mais l’adhésion est facultative
si l’hébergé (asso ou individuel) a de petits moyens.
q Webdynamit : Propose 70Mo d’espace pour un SPIP.
Fonctionne très bien mais les inscriptions
sont en stand-by depuis quelques semaines (toujours vrai le 22 janvier 2005).
Tout devrait retourner dans l’ordre bientôt après acceptation de la nouvelle
charte d’hébergement pour les webmestres déjà hébergés. La nouvelle charte doit
empêcher les sites boulets de proliférer sur les serveurs, sites qui
décrédibilisent l’hébergeur gratuit. Une toute petite pub est à afficher dans
les 600 premiers pixels du site et les fichiers à télécharger sont limités en
taille (hors de question de placer des fichiers zip ou mp3 de plus de 2Mo).
q Dhost.hopto.org :
en anglais Propose 100MB d’espace, 300GB de bande passante, un accès en
ftp, php & MySQL,
autorise les downloads. Pas de problème à l’installation. Deux ombres au
tableau : le serveur fonctionne d’une manière intermittente ; et
durant la soirée l’internaute est accueilli par un pop-up souvent érotique,
parfois pornographique. Un aperçu, tout de même ici et ici. remarque le 20/2/2005 : ces 2
sites sont HS.
q Neoskills.com :
Hébergement gratuit des projets libres intéressants (biospip.neoskills.org par exemple) ainsi
que des bonnes causes (munci.org , cometeinternational.neoskills.org
) Propose 100MB d’espace disque , 500 MB de bande passante mensuelle, un accès
en ftp, php & MySQL, autorise les downloads.
Passez proposer votre projet sur irc ://irc.freenode.org#neoskills
ou sur la mailing liste des admins
q TransatHost* : Hébergeur francophone proposant
un pack gratuit (120 Mo espace disque, 2 bdd..) ou quatre pack payants allant
de 30 à 149 euros par an. Support réactif (par e-mail + forum) et convivial,
sont ouverts à toute possibilité d’élargir votre abonnement (gratis ou pas) un
petit peu même ! SPIP et tous systèmes de publi dans le genre y tournent
comme une girouette parfaitement huilée :) Evidemment, d’autres
spécificités et fonctions pour chaque pack à aller scruter en ligne pour plus
d’infos (http://transathost.com/index.php ?page=hébergement)
q 100WebSpace
qui a quelques problèmes de performance et impose un bandeau (discret tout de
même... pour l’instant). Un bon endroit pour faire des tests mais aujourd’hui,
la fiabilité s’améliore mais reste instable et le petit bandeau de pub (quoique
plus discret que celui de multimania) en interdit tout usage le moindrement
sérieux. Note : Shyper a
définitivement mis fin à son offre d’hébergement gratuite et a fermé
brutalement tous les comptes gratos.
q L4FH (LoOk* for free host) : Un annuaire d’une centaine d’hébergeurs gratuits à travers le monde, il propose un outil de recherche selon des critères (espace, bande passante, base de donnée...).
q Free : Depuis le 1er mai 2004, la
connexion FTP pour les nouveaux comptes "Accès Libre" se fait
uniquement depuis une ip Free, via : login*.free.fr (source1 source2).
C’est à dire dans les faits que même si vous êtes en adsl chez un autre FAI,
vous devrez vous connecter avec votre bon vieux modem56k. A noter tout de même
que si vous possédez un compte "forfait" chez eux (ADSL, forfait RTC),
vous pourrez accéder à votre ftp depuis un autre FAI (votre lieu de travail par
exemple) via l’ancien système ftpperso.free.fr (qui vous sera autorisé
UNIQUEMENT si vous êtes un abonné forfaitaire).
— A part cela, l’hébergement est
"gratuit", sans pub, et on peut désormais utiliser la version normale
.PHP3 (avant, il tournait un peu plus vite en utilisant cette contrib en
.PHP, problème de rapidité résolu depuis), et la fonction mail.
— Procédure : Inscrivez-vous pour un compte "Accès Libre".
Vous recevrez un courrier avec vos identifiants. Connectez-vous ensuite ici, et activez votre compte pour les
pages perso.
Nota Bene :
— A lire également, cet article dans
la doc officielle, et celui-ci : «Free.fr : pour eux, la liberté n’est qu’un
slogan».
— Quelques infos complémentaires
de version (juillet 04) : phpmyadmin 2.5.6.rc1, Mysql 4.0.20, serveur
sql.free.fr
— Il semble y avoir un problème au
moins avec la v1.71 : un message d’avertissement qui s’affiche
souvent : "Warning ... /var/www.free.fr/7/1/monsite/ecrire/inc_db_mysql.php3"
(voir les messages sur spip@rezo.net à ce sujet). __19/10/2004 : Free a
ajouté récemment des restrictions à l’accès FTP : on peut lire ceci sur la
FAQ de Free :
"Vous vous devez de conserver une copie locale de vos données, c’est
pourquoi le téléchargement depuis les serveurs FTP de Free n’est pas
autorisé.".
Cette restriction empêche, au final, de
garder une copie locale, puisqu’il est dorénavant impossible de
récupérer :
-les sauvegardes (dump) de la base MySQL,
-les images déposées par les auteurs
(et qui se trouvent dans le répertoire IMG).
- etc...
Pour résumer, la nouvelle politique de
Free va poser de sérieux problèmes pour l’administration d’un site SPIP chez
Free. Doit-on déplacer cet hébergeur dans le chapitre Les hébergeurs où SPIP
NE FONCTIONNE PAS ou très mal ? Ou peut-être les freenautes
peuvent-ils se mobiliser et envoyer des mails à la hotline pour réclamer un ftp
complet ?
- 27/11/2004 : Aucun
problème chez Free, je ne vois pas la concrétisation des annonces de la FAQ de
Free. J’ai pu sans problème installer, récupérer la sauvegarde SPIP de la base
aussi bien sur des vieux comptes Free que sur des nouveaux et ceci via un accès
ADLS Wanadoo.
[Phil]
- 21/12/2004 Pour autant que je sache, cette
restriction sur les downloads s’applique uniquement aux nouveaux comptes web.
Concernant l’accès depuis un autre FAI,
Free a semble t’il changé récemment sa politique : "L’offre étant
réservée à la France métropolitaine, aucune connexion FTP ne fonctionnera
depuis un autre pays". Plus de restrictions sur le FAI d’origine, donc.
- 21/01/2005 : Effectivement, il est
impossible sur les nouveaux comptes de downloader. J’ai 3 sites Free
associatifs sous Spip à maintenir, pour les 2 premiers (comptes free créés il y
a 2 ou 3 ans), pas de souci, pour le dernier, créé hier, download interdit ;
plus de sauvegardes possibles, impossibilité de récupérer les photos... Chez
free, ils commence vraiment à être pénibles !
[Eric]
— 15/12/2004 : SPIP est désormais
disponible en installation automatisée sur free. Si quelqu’un a testé ce
que cela donne... http://subscribe.free.fr/persov2/persov2.pl
- 9/01/2004 : L’installation automatique met en
place la version 1.7.2. Installation transparente, rien à faire, on se connecte
le lendemain, ca roule. La sauvegarde fonctionne (testé avec un article dans la
base). A tester avec un contenu plus important. Le download en ftp fonctionne
donc pas de souci pour récupérer son fichier de sauvegarde (connecté en adsl
free).
- 3/02/05 : A noter la possibilité chez
Free de porter son espace à 1 Go
q Netpratique ,
autorise SPIP sans aucun problème. Quelques soucis toutefois avec les librairies GD. sur abonnement
ADSL ?
q Tiscali :
en fait il suffit de s’abonner en forfait libre (et gratuit)...accepte PHP4,
oui et du même acabit que free, c’est en IP interne (=connexion par tiscali en 56k), voir la blague de leur
webftp qui télécharge les fichiers 1 par 1... là j’ai pas eu le
courage...spip=188 fichiers...
- 31/07/04 : attention tiscali ne propose le
MySql que pour ses packs
payants ! :-( Signé : kinder_pingui
- 22/08/04 : je confirme que Tiscali ne propose
l’option MySql
que pour son
phttp://www.spip-contrib.net/spikini/RechercheTexte&phrase=ListeDesHebergeurs
ListeDesHebergeursack*
moyennant une rallonge de 9 euros par mois. Soit un Montant total annuel :
107.64 € TTC (90 euros HT). C’est pas cool pour de petit budget. Firma Loic
q La Poste :
Propose théoriquement 50Mo d’espace Web. Certains ont pu y héberger leur SPIP
en s’ouvrant un accès Internet gratuit (même démarche que pour free.fr).
Malheureusement les ouvertures de comptes semblent bloquées malgré l’air
incrédule des opératrices du service client
téléphonique
— (Exemple de spip hébergé par la
poste ici :
aucun problème pour l’ouverture du compte, activation de l’espace web et de la
base dans les deux heures ; ouvert le 25/04/04).
— 09/07/2004 : j’ai un
site SPIP 1.7.2 chez Laposte qui fonctionne correctement, il n’est pas très
rapide alors que je me connecte avec l’offre Adsl 1024 de Wanadoo. Très facile
à installer, pas d’attente pour disposer de la base MySql, par contre la
plateforme ne semble pas très stable ! Signé Gg
— 30/08/04 : j’ai un
site SPIP 1.7.2 chez Laposte qui fonctionne correctement, malheureusement la
syndication ou le contrôle d’"url" ne fonctionne pas. Signé asso.bachant@laposte.net
— 22/11/04 : j’ai installé un site SPIP 1.7.2 à La Poste. A
priori tout fonctionne correctement, sauf la syndication et l’envoi de mails.
Pour les mails, j’ai pu constater que seuls les mails vers des adresses formée
sur laposte.net ... ce qui est un peu restrictif ! Frederic
Mohier@laposte.net
— 27/11/04 : La Poste
est capable de supprimer votre compte sans préavis si vous avez ne serait-ce
qu’un seul fichier à télécharger sur votre site. Ils précisent bien que LaPoste*.net n’est pas
un service de téléchargement et ils appliquent à la lettre cette consigne. En
bref, j’avais un fichier zip de squelettes pour SPIP à télécharger (1,1Mo) et
le site a été tout bonnement fermé (disparition complète, fermeture du compte)
sans préavis, sans demande de retirer le fichier incriminé... Pas très
fair-play comme comportement surtout si on ajoute l’incompétence notoire du
service client qui ne comprennent jamais ce qui se passe et qui s’en étonne
sans jamais trouver ni proposer de solution.
q all2all (be)
q Alterezo (be)
Association sans but lucratif (ASBL, équivalent association loi 1901)
s’adressant prioritairement au monde associatif militant et culturel en
Belgique francophone. Tarif de base : 100 euros/an. De nombreux sites sous
spip y sont hébergés.
q
Altern
q APINC : Il est juste
necessaire de faire l’install en uploadant tous les fichiers, et en n’usant pas
de l’installeur.
Héberge recherche-en-danger.apinc.org par exemple comme
site sous spip
14euros/an pour 200Mo, mail illimités,
mysql illimité, et 3Go de trafic mensuel. Remarques : deux jours sur
Apinc : c’est chouette ! Tout est installé (spip et email). C’est
autre chose que Free.
J’ai mis en place www.biospip.org et
www.biotechno.org chez Apinc et, à part des petites mises en rideau pour corriger
et mettre à jour le serveur, tout se passe nickel. Vive l’hébergement
associatif !
q l’Autre Net (autogéré) Inscriptions closes pour
l’instant.
q Cassiopea (belgique)
ASBL. Hébergement, expertise, installation et configuration de logiciels
internet open sourçe pour le monde associatif. Création de squelettes pour
spip. Attention, prix bizarres, on parle de 30 euros pour l’installation de
spip + 5 euros mensuels) + le reste !!!
q Devveb Cet hébergeur
existe-t-il encore ?
q Domaine public (Be) Structure d’hébergement internet
non-marchand et indépendant, gérée collectivement par les membres. 30 Euros/an.
q F-et-T.com ::
pointage des DNS + hébergement de votre site spip avec acces ftp + 10
e-mails : 10euros/mois
q Fr@terNet (Agence
Web Associative)
q Globenet (destiné
aux associations)
q MarsNet,
marsnet.org, hébergeur associatif et participatif
(Marseille)
q Infini (Brest et sa région)
q JPBerlin est
un des rares hébergeurs alternatifs en Allemagne. L’administrateur Peer Heinlein héberge aux prix variables
(tu donnes ton avis comment tu peux payer) qui couvrent même pas les coûts.
Beaucoup d’initiatives et associations comme attac
Allemagne ou bientôt attac
Autriche. L’installation est simple, toutefois les droits d’écriture
(chmod 777) sont activés par le support, mais ils répondent sous quelques
heures. Mon spip
est là.
q Médicalistes
(Listes de discussion "santé" et hébergeur associatif gratuit)
q Ouvaton (Coopérative,
dispose d’un forum spécifique pour les Spipeurs) Ouvaton est une SA à forme coopérative
qui propose de l’hébergement internet. Chaque utilisateur en est également sociétaire, ses membres sont
des hébergés-hébergeurs. Fin 2004, la coopérative est forte de plus de
3 000 membres et héberge plus de 5 000 sites dont une forte proportion
de Spip.
q Propagande
(hébergement gratuit pour sites Punk, Ska, Rock...)
q Réseau Associatif et Syndical (R@S) Hébergement sur cooptation. Chacun
paye ce qu’il veut... Le R@S héberge plus de 200 associations et syndicats,
dont en vrac ATTAC, SudPTT*, le Mrap, la LDH,
RasLFront*,
la coordination Lesbienne de France, le FSE et de nombreux FSLs, le CCIPPP...
q Tuxfamily (gratuit,
réservé aux sites ayant un rapport avec le logiciel libre)
q Newscout Hosting (gratuit, qualité professionnelle et
parfaitement accessible y compris aux débutants, pour l’hébergement de sites
francophones ayant trait au scoutisme. Hébergement à la carte (jusqu’à
1Go !), fonctionnalités "spéciales Spip" pré-installées) News du
30/09 : à compter du 01/10/2004 plus aucun plan n’est disponible.
q Africa Computing Pour promouvoir la production
d’informations africaines, Africa Computing met à la disposition de toute
personne ou structure qui le souhaite un service gratuit d’hébergement de sites
WEB
Vous pouvez aussi trouver une liste à
jour d’hébergeurs alternatifs ici http://twiki.zaup.org/view/Riha/Lis....
A priori, SPIP fonctionnera sur tout
hébergeur payant traditionnel (qui propose PHP et MySQL) Cette liste
d’hébergeurs étant maintenant éditable par tous, nous proposons de donner un
prix indicatif par an pour un hébergement d’un site avec 50 Méga, sans le nom
de domaine, préciser s’il y a lieux les frais d’installation divers. Merci de
ne pas mettre des remarques du genre "l’hébergeur truc il est super"
dans la liste. Vous pouvez poster des commentaires pour partager votre
expérience en bas de la page .
q Elassar SPIP
fonctionne chez Elassar. Pour un hébergement mono domaine mensuel il faut
compter 9 Euro par mois avec 200 Mo d’espace disque. La formule Multi domaines ( 25
domaines sur un compte hébergement ) coute dans les 24 Euro par mois avec 500
Mo d’espace disque. Pour les dédiés il faut compter dans les 149 Euro. Les
serveurs sont managés, les mises à jour effectués etc. Le support est présent 24/24 et 7/7. La mise en
route d’une formule d’hébergement dédié ou mutualisé se fait dans l’heure.
q Le village :
Je vous conseille ce site !, une vraie ambiance, une disponibilité sans
faille des admins et des prix tout à fait corrects (en + spip est proposé en
application clé en main ! rien a installer, juste cliquer sur 2
boutons !)
q Esope : je confirme : pour 42 euros par
an. Clair et facile à dominer.
q 123serveur hébergeur
fiable et rapide, grande capacité de stockage Vraiment très bien : je suis
parti d’OVH qui m’avait filé au rebut avec un serveur MySQL très lent pour cet
hébergeur : sérieux, pas de plantage, réponses email rapides, franchement,
que du bonheur : vous pouvez tester la rapidité d’exécution des pages sur
mon site Helloduck
q Abricoo hébergeur
français très sympa et réactif, orienté petites structures (TPE/PME,
associations...). L’installation de SPIP se fait sans aucun problème sur leur
architecture, et le support propose même l’installation et la configuration au
besoin
q Agora System
hébergeur français super sympa et très compétitif au niveau des prix. aucun pb
pour SPIP.
q Aladin Hébergeur Suisse
(avantage pour les sociétés : exonération de TVA). Très réactif. Très
rapide. Autre avantage (hors SPIP) a installé un serveur Tomcat.
q Alphanetinfo Installation
automatisée fonctionnelle - Tarif pour monde associatif
q Amen (une précision par Amen : FAQ, des
précisions par des ex-clients )
q Aqua Ray
(hébergement sur XServe Mac OS X Server - une offre 60 Mo à partir de 12 Euros
par an, ou 100 Mo avec nom de domaine propre pour 48 Euros par an. Bonne
réactivité. Leur site est en SPIP)
q Arts du Web
Hébergement Web, FTP, Mysql, PHP4, courriel,statistiques Webalizer.
Surveillance, monitoring de serveurs et site Web. Support gratuit par courriel.
Création de site Web
q AZ Hosting
(qc) 50 MB : 6,95$ US par mois, MySQL, PHP4.3, mailing
lists, Webmail, panneau de contrôle exhaustif (hébergements avec MySQL à partir de 20 $ US
par an, domaine non compris)
q BleuBlancNET* 150 Mo / 29 ? TTC par an
q Behostings.be
(be) Hébergement et création de sites spip, hébergement a partir de 40 ?
Ht / an, 50 mo et nom de domaine inclus, panneau de controle DirectAdmin
q Celeonet
Hébergement à partir de 29,88 € HT /an pour 75 Mo, 7 Go de trafic mensuel, 10
comptes mail, nombre de comptes ftp et de bases mysql illimitées, Statistiques
avec Awstats. Espace clients accessible en démo sur http://www.celeonet.fr/clients/index.php
avec comme login : démo et pass : démo. L’équipe de Celeonet est
celle de Webdynamit qui a déjà prouvé sa compétence. // A noter qu’il est
possible d’installer Spip directement depuis le panel d’administration de
l’hébergeur en remplissant, dans un unique formulaire, les champs proposés par
Spip lors d’une installation classique (aucun upload de fichier, pas même le
spip_loader.php3) - Olivier (24/06/2004).
q Claranet :
en hébergement mutualisé et à partir des packs Biz, tout est impeccable. Même
si l’hébergement a un certain coût, tout se passe facilement, sans aucune
anicroche. PhpMyAdmin*
pour la gestion des bases. PAR CONTRE, il semble que Claranet n’accepte pas la
syndication des sites.
q Cliranet :
200 Mo d’espace, 5 Go de trafic accepte PHP, MySQL et PERL pour 1euros
68 par mois !
q Club-internet :
tenté d’installer SPIP, pas marché. Entrée sur rép. écrire laisse page blanche.
Offrent pourtant MySQL
et PHP (depuis peu). // Chez moi SPIP s’installe bien mais il faut créer la base
par phpmyadmin. Par contre connexion partie privée impossible. Apres pseudo il
renvoi a la page d’accueil.
q DERTERNET :
50 Mo redondants pour 1 euro HT/mois
q Digital Rural - dri.fr ( DRI ) - Hébergement à partir de 38 ? Ht
/ an = 100 mo, 50 boîtes, 2 bases Mysql - plusieurs sites SPIP à fort trafic,
hyper fluides, déjà hébergés. Un extrait de la liste des CLIENTS (beaucoup
d’assos) qui est ici , support technique
7/7j.
q Discount hosting (Nfrance ; fonctionnement non garanti)
q Easyserv
(N’existe plus, et si ils reviennent évitez les !)
q eBusiness.be
- Hébergement et création de sites SPIP, hébergement de 50 Mo à 300Mo, 2 à 5
bases MySQL.
q
Elginux
q Europeanservers installation de SPIP 1.7.2
pré-configuré en un seul clic !
q FranceOnline* - Attention escrocs, serveurs
fréquemment en panne, sans préavis ni excuses. Faites des recherches sur
internet pour en savoir plus, c’est édifiant.
q Galacsys 30
euros TTC par an, mais seulement 20 Mo
q GoDaddy*
4$/mois, 25M de disque et 1G de bp. Interface
en anglais, plus pratique pour les sites gérés par un non-francophone.
SpipLoader*
ne passe pas. Extensions .php, corrigeables facilement avec un fichier
.htaccess. Pas super-rapide, support qui ne casse pas des briques, et des
pratiques commerciales contestables...
q Haisoft A
partir de 24.90 euros par an pour 100
Mo Scripts CGI, Perl, PHP et bases MySql, gestion de mails.
Présent dans plusieurs pays, HotLine en Français en
France (Orléans), En fait premier prix à compter de €19.90 par an. Grand plus
par rapport à d’autres hébergeurs : l’extension PEAR est installée en standard, ainsi d’ailleurs que la plupart
des extensions PHP. Le support technique est excellent et très rapide (dans mon
cas dans les 2 heures).
q Hebergement-discount (NFrance ; attention, beaucoup de
complications techniques mais
installation possible voir forum de l’article)
q Hebergeur.be
à partir de 60 euros HTVA par an pour 50 Mo d’espace disque avec PHP / MySQL (et la possibilité
d’utiliser SPIP bien entendu ;-)
q
HEXANET
q ICODIA (fr) Spip fonctionne
parfaitement chez cet hébergeur direct qui offre par ailleurs, des services de
grande qualité.
q Infomaniak (ch)
utilisateur de spip nous dit :
La société Infomaniak Network SA, qui héberge actuellement notre site, ne
permet pas les pages longues car dixit : "La durée maximale d’éxécution d’un script est
fixée à 10 secondes, pas une de plus." !!! Bémol :
Infomaniak fonctionne malgré tout très bien à date avec spip ... il ne semble
pas y avoir de problèmes particulier même avec des squelettes
"lourds" :).
q Iscream Hébergement
web Montréalais. Déjà deux sites au moins turbinent chez eux sans problèmes.
Ils ont donc une expérience de la chose maintenant. Service à la clientèle ben
correct malgré que la compagnie ne soit pas gigantesque, forte volonté de
régler les problèmes qui peuvent surgir quoi comparé à d’autres hébergeurs.
Prix commencent à 8,95$ (ou 5,95Euro) pour 100 mo d’espace et 5 gig de
transfert. Je recommande en tout cas. Pour m’écrire.
q
Insite
q Jexiste Spip fonctionne très
bien, il est rapide et fiable. Bref c’est le top. Compatible php (3,4 et 5),
mySQL et Html (bien sûr !)
q Jn-Hébergement à partir de 6 euros/an
q Loco-web
500 Mo pour 60 euros/an
q Lost Oasis :
des gens de chez TuxFamily*
et Idealx... à partir de 15 ?/an. (Je n’ai pas encore essayé SPIP
dessus... // moi je viens d’essayer : aucun problème, les prix sont à majorer de
5euro pour avoir MySQL.)
Attention à la fiabilité et au sérieux : ils ont réussi à perdre
simultanément les données de leurs hébergés et les backups associés.
q Lycos-WebCenter* 250Mo pour 6.99 euros/HT par mois
q Maximedia
(ch)
q
modulix
q NetAktiv* NetAktiv*,
membre fondateur de l’opérateur Internet indépendant Gitoyen. Ils hébergent «
le plus gros site SPIP du Web » : le journal "l’Humanité"
(150.000 articles, 10.000.000 de visites par an). Le forfait d’hébergement
démarre à 35 euros HT/mois.
q Nexen.
Parfait pour des sites professionnels à coût réduit. Aucun problème de time
out, aucun problème de phpmail, des "robots" pour automatiser des
tâches nocturnes et une hotline qui connaît SPIP et est réactive. Des mises à
jour régulières de PHP et MySQL. En mutualisé, moins
de 100 euros par an (au 23/05/2004).
q nexlink .
J’ai dû installer la distribution de SPIP avec extension .php car les pages en .php3 n’étaient pas exécutées
(alors qu’en théorie Nexlink configure les .php3) (4 mai 2004)
q Nfrance .
500Mo d’espace web pour 10 euros HT/mois (formule basique). Installé SPIP 1.8b2 sans problème particulier.
Chez NFrance, les hébergements
basiques sont plus intéressants au niveau prix.
q NqNwebs*
- Argentina Efficace et économique service de logement. Seulement u$s80 par
année. 250mb/15gb de transfert. SPIP fonctionne parfaitement.
q One2netFrance* Moteur htdig proposé en mutualisé
q Online.fr/proxad
Vieille version de PHP incompatible avec SPIP 1.7. _ !!! je suis sur
online la fonction mail est remplacée par email doc fournie php est
récent !!! PHP 4.3.1 en ce moment !!! php3 = v. 3.0.18, donc pas
compatible. Si si ça marche, install avec spip_loader.php, aucun soucis (SPIP
1.7). 1.7.2 : nécessite d’installer la version SPIP 1.7.2 avec extensions .php,
si on veux des vignettes auto pour les images jpg et png (juin 2004) 100 Mo
pour 29,90 Euros/ans Problème de Mail, qui a eu ce problème ?
réponse : pas de pb de mail pour moi...
q Spip fonctionne en effet chez Online,
mais attention au paramétrage PHP imposé dans php.ini : le temps maxi
d’exécution est de 18s insuffisant pour les gros articles. Hébergeur totalement
à déconseiller, donc, pour les sites effectuant de la publication de façon
professionnelle.
q A éviter même avec la version .php. Les
accès à la base sont trop longs et les pages ne peuvent pas se charger.
q Ovh : 60Mo pour moins de 15 euros/an.
Attention aux droits d’accès des fichiers, OVH interdit l’ouverture de fichiers
à plus de 755 (chmod) ce qui est une bonne chose. On peut toutefois utiliser le
Spip_loader_755.php3
ATTENTION : si votre base MySQL dépasse un certain
quota (15 Mo), ils déplacent votre base sur un serveur lent comme un
veau ; à éviter donc pour des sites SPIPés > 700 pages.
q Oxito Hébergeur très facile
à utiliser : compatible spip 1.7 et 1.8. Très bon support, rapide et
efficace
q Oxyd Pas observé de problème particulier
chez eux avec spip. Que ce soit avec des versions 1.5, 1.6 1.7 ou 1.8cvs. Pas
essayé spip_loader.
q Testé 1.7.2 sur un pack
"nickel" : aucun problèmes. Spip_loader marche. (Alexis)
q Pages-Web.com
Configuration standard incluant PHP 4.3.10 + Zend Optimizer. SPIP (1.7.2)
fonctionne parfaitement (exemple)
y compris Spip_loader. Hébergement complet à partir de 20$ CA/an ( 15
Euros/an) incluant Administration PLESK 7, Spamassassin, ClamAV*, etc ... 20% sur tous
les services pour les associations.
q Phpnet La syntaxe des
fichiers .htaccess est spécifique : ils s’écrivent htaccess.fi. Cela rend
inopérants les fichiers .htaccess générés automatiquement par l’activation de
l’option ad hoc [Espace privé / Administration du site]. C’est donc très
dangereux car les répertoires CACHE et ecrire/data ne sont pas protégés contre
les intrusions (Antoine). Spip_loader fonctionne sans problème.
q Planet work Très bon hébergeur, toujours dispos
pour régler les problèmes, bons services, tout marche à merveille
q PROSYGMA Hébergeur
rapide et fiable ! Install sans problème y compris avec spip loader.
q PROWEBSERVER Hébergeur
vachement sympa. Les types super dispo et très bons techos , même si la boite
semble petite .
q Rapidomaine.fr
Pas trop cher, fiable et rapide. Une très bonne aide technique
q Rekcah Hosting Hébergeur rapide et fiable sur la
durée, support très réactif de plus le prix est vraiment bas.
q Serveur4u :
Hébergeur Gratuit & Payant, sans pub avec le safe_mod off et la fonction
mail() on
q Sivit : Autant sur leurs offres mutualisées
que dédiées, il n’y a aucun problème quant à l’utilisation de SPIP. Un seul
bémol chez eux, le support technique n’est pas rapide et semble complètement
absent durant la période estivale et ment parfois aux clients. Aucun problème non
plus avec la fonction mail.
q Solin Solution Internet : Hébergeur de premier plan a Montréal,
Québec, Canada offrant DirectAdmin
a partir de seulement 4.95$cnd
q Syloé :
Hébergeur à taille humaine acceptant SPIP et toute application
(PHP/Mysql/PostgreSql*).
Grande qualité de service. Plateforme située dans un Data-Center à Montpellier
dans l’Hérault. Solutions dédiées et mutualisées. Hotline Téléphonique très
disponible. Prix mensuel pour 150Mo 29 euros HT.
q
Venigo
q
Xelacom
q Webact :
Hébergeur situé dans la technopole d’Angers.
q WebHostingAce* Hebergeur Américain, de très bonne
qualité et aux tarifs avantageux !!! Je paye 32$ par an pour 100mo et tout
illimité(compte pop Sql etc ...) Un aperçu ici
q WebsiteOut*
(support e-mail très efficace, réponse en moins d’une heure mais les prix ont
augmenté en moins d’un an de manière scandaleuse sept 03 : 53 euros ttc
pour 50Mo aujourd’hui 113 euros TTC, spip fonctionne bien)
q Webviso
q Zonealta
q Yellis
q Imingo
q PICSARL
via leur filiale VHN (Votre-Hebergement.Net) :
hébergement sites SPIP, très rapide, sérieux, prix selon bande passante
utilisée
q WZ-Hébergement hébergement à haute valeur ajoutée de
sites PHP/MySQL
ou PostgreSQL*
100% compatibles SPIP, propose aussi une offre "Serveur dédié
administré" à un prix très attractif (avec la possibilité d’avoir des
config PHP ou Apache particulières). Sauvegarde des données comprise dans
toutes les offres.
q Averdata :
Hébergement en anglais, mais spip 1.7 marche sans incident et assez rapidement.
Tarifs intéressants et pas de limite de bande passante... Il faut tout de même
maîtriser les aspects techniques car le support ne m’a pas l’air très
performant... l’accès ssh est souvent désactivé par sécurité et ils ne font pas
la gestion des noms de domaine.
q Elogiciel.org : Pour une expérience qui sort de l’ordinaire. Hébergement du sytème de publication SPIP via un organisme O.S.B.L. québécois de concept "équitable" 100 euros/an. Spip peut être installé sur demande et sans problème. Service complet de noms de domaine, web-mail, MySQL, PHP,etc. En plus vous bénéficierez gratuitement d’un hébergement (réel celui-là) de courtoisie au Québec (en Gaspésie) si vous ou un membre de votre organisation venait à être de passage dans cette belle région de l’est du Québec ; question d’ouvrir la porte aux contacts, aux rencontres et aux échanges entre utilisateurs du système de publication SPIP et les membres de ce groupe d’artistes multimédia et d’activistes communautaires installé en pleine nature dans la péninsule gaspésienne. Contact téléphonique : 1-418-797-5186. Demander Georges ou Cérika.
A savoir Le spip_loader de www.spip.net a été réécrit pour fonctionner sur davantage d’hébergeurs. Si l’installation automatisée de Spip sur l’un de serveur ne fonctionne pas, cela ne devrait plus être à cause d’une restriction des chmods ou droits d’accès. |
L’installation de
SPIP est très simple : il n’y a pas, en particulier, de fichier à modifier « à
la main » avec des variables ésotériques. La procédure est très simple (elle
est détaillée ci-après) :
1. Récupérez le fichier de SPIP sur notre serveur, et le décompacter sur votre ordinateur personnel. Vous obtenez un dossier « SPIP... » contenant l’ensemble des fichiers du système SPIP.
2. Installez le contenu de ce dossier sur votre site (par FTP, comme vous le faites habituellement pour installer vos pages sur votre site).
3. Connectez-vous avec votre navigateur sur votre site, dans un dossier intitulé « ecrire », où SPIP vous proposera une interface graphique vous permettant de configurer le système. Une fois ces quelques informations de configuration fournies, SPIP sera totalement installé et vous pourrez commencer à travailler sur votre site.
Vous devez disposer d’un hébergement Web avec :
q un accès FTP pour l’installation des fichiers ;
q le support de PHP3 ;
q un accès à une base de données MySQL.
Avant l’installation, vous devez avoir une base mySQL disponible. Sur de très nombreux hébergements, il faut soit demander l’activation d’une base mySQL à l’administrateur, soit suivre une procédure automatique en ligne (dans tous les cas, l’activation de la base mySQL n’a rien à voir avec SPIP ; si vous avez des difficultés, seul votre hébergeur peut vous fournir les mots de passe nécessaire et vous expliquer comment activer votre compte mySQL).
Vous devez connaître les données de votre connexion MySQL (fournies par l’hébergeur) :
q l’adresse de la base MySQL : par exemple sql.free.fr, ou localhost, ou vide ;
q votre login MySQL : souvent le même login que votre compte Web ;
q votre password MySQL : souvent le même que le compte Web ;
Lors de l’installation, une fois ces informations indiquées, il faudra aussi préciser :
q le nom de la base de données : souvent le même login que votre compte Web - il est possible que le serveur vous offre la possibilité de créer vous même cette base.
Exemple : si vous disposez
d’un compte nommé « monsite » chez Free (adresse http://monsite.free.fr),
l’adresse de la base mySQL est « sql.free.fr », le nom de la base de données
est « monsite », votre login est « monsite » et le mot de passe est celui de
votre compte. Il vous suffit d’activer votre base de données pour php |
Ces éléments sont indispensables : si vous ne les connaissez pas, contactez votre hébergeur et demandez-lui de vous les rappeler.
Aucune configuration spéciale n’est nécessaire sur votre ordinateur personnel, SPIP se gère entièrement sur le Web. Tout ce dont vous avez besoin, c’est d’un navigateur Web (n’importe lequel), et d’un logiciel de transfert FTP pour installer les fichiers sur votre compte.
Il existe pour SPIP une procédure d’installation ultra-simplifiée : un fichier à télécharger sur votre serveur et ça s’installe. Attention : cette procédure ne fonctionne pas sur tous les serveurs. Si elle ne fonctionne pas (vous vous en rendrez compte immédiatement), passez à l’étape 1 ci-dessous.
Récupérez le fichier spip_loader.php3 à l’adresse ci-dessous (si le fichier s’affiche dans votre navigateur, faites « Enregistrer sous... ») :
q http://rezo.net/spip-dev/INSTALL
et téléchargez-le tel quel sur votre serveur (chez votre hébergeur) par FTP. « Visitez » cette page avec votre butineur Web habituel (à l’adresse du style : http://www.moncompte.com/spip_loader.php3) et suivez la procédure indiquée.
Si la procédure fonctionne, ce petit fichier va récupérer SPIP sur notre propre serveur et l’installer chez votre hébergeur. Ensuite la procédure de configuration démarre automatiquement (étape 3 ci-dessous).
SPIP est disponible en téléchargement par le Web à l’adresse :
http://www.spip.net/spip-dev/DISTRIB/
Dans ce dossier vous trouverez :
q un fichier spip.zip : il s’agit de la version complète de SPIP, comprenant toutes les traductions existantes ;
q un sous-dossier où sont déposées les versions monolingues de SPIP (identifiées par le code de la langue en deux ou trois lettres) ; celles-ci peuvent être utiles pour minimiser l’espace d’hébergement occupé et/ou le temps de téléchargement.
Choisissez la version qui vous intéresse, décompactez l’archive sur votre ordinateur dans un répertoire de votre choix, puis transférez le contenu de ce répertoire chez votre hébergeur via FTP.
Installez l’ensemble des fichiers de SPIP sur votre site, à l’endroit où vous voulez que le site géré par le système soit accessible au public : le plus souvent à la racine de votre site, mais ce n’est pas impératif.
À titre d’information, la structure est la suivante :
· répertoire racine
· squelettes .html
· nombreux fichiers .php3
· dossier /CACHE (vide)
· dossier /IMG
· dossier /NAVPICS
· dossier /ecrire (le plus important)
· nombreux fichiers .php3
· dossier /AIDE
· dossier /img_pack
· dossier /data (vide)
· dossier /lang
· dossier /upload (vide)
Désormais tout se déroule en ligne. Il vous suffit d’aller « visiter » votre dossier « /ecrire » par le Web.
Exemple : selon notre
exemple précédent, il s’agirait de l’adresse http://monsite.free.fr/ecrire.
Lors de la première connexion à cette adresse, une procédure d’installation pas-à-pas démarre. L’interface est très simple, il suffit d’entrer les informations demandées (essentiellement les informations concernant la base de données mySQL indiquées au début). Une fois que c’est terminé, le système vous demande l’identification que vous avez indiquée et vous pouvez commencer à gérer votre site. Par la suite, c’est toujours dans ce dossier « /ecrire » que vous irez travailler, muni de vos codes d’identification.
À chaque étape
de la procédure d’installation, vous trouverez un lien vers l’aide (comme ceci ),
qui provoque l’affichage d’une aide en ligne expliquant chaque détail de
l’utilisation de SPIP. (La seule opération un peu complexe apparaît sur
certains serveurs : il vous faudra peut-être modifier les « droits d’accès » de
certains dossiers ; l’opération n’est pas bien méchante, et l’aide en ligne
vous fournit tous les détails nécessaires.)
Si tout s’est bien déroulé jusqu’ici, la procédure d’installation est terminée, et vous pouvez créer et gérer votre site sans aucune autre manipulation ésotérique...
En cas de grosse erreur (du genre : vous avez oublié votre propre ccès au site - fréquent au début...), pour « relancer » cette procédure d’installation, il faut utiliser votre logiciel FTP et effacer les fichiers suivants : q /ecrire/inc-connect.php3 q /ecrire/.htaccess (s’il
existe) La connexion suivante dans le dossier « ecrire »
relancera alors la procédure de configuration (en réalité, c’est l’absence de
fichier « inc-connect.php3 » qui provoque le lancement de cette procédure). |
Afin de nous aider à améliorer cette procédure d’installation, merci de faire part de votre expérience dans le forum « installation » sur ce site, ou en écrivant à spip@rezo.net (attention : dans les deux cas vos réponses seront publiées sur notre site, soit sur le forum, soit dans les archives de notre liste de discussion). Si vous effectuez l’installation vous-même, veuillez indiquer :
q le nom de votre hébergeur (important, ça, qu’on ait une idée des différents hébergeurs compatibles, notamment les gratuits) ;
q les éventuelles difficultés rencontrées (y compris les difficultés d’interface et de compréhension du processus d’installation, histoire qu’on puisse améliorer l’interface ou la documentation) ;
q même si votre installation s’est déroulée sans aucune difficulté, merci de l’indiquer (c’est une info intéressante).
Pour publier votre site sur le Web, vous avez certainement besoin d’un hébergeur. Mais en attendant, vous voulez peut-être faire des essais et des réglages sans être gêné par la lenteur de la connexion Internet, et sans laisser vos futurs visiteurs admirer dès maintenant vos premiers pâtés. La solution est d’héberger votre propre petit « serveur Web » sur votre machine personnelle, pour votre usage privé. Cela s’appelle « travailler en local ».
Pour les utilisateurs ayant un PC fonctionnant sous Windows, la solution la plus simple pour tester SPIP consiste à installer EasyPHP sur sa propre machine.
Le site Ecran de Bureau propose, sur SPIP-Contrib, un fichier PDF expliquant graphiquement la marche à suivre. Ce document est destiné aux débutants.
Les autres systèmes (MacOS, Linux) permettent aussi de monter son petit serveur personnel, parfois automatiquement, parfois au prix d’un léger effort de configuration à la main. Nous vous conseillons de vous reporter à la documentation de votre système ou aux sites Web d’entraide dédiés à celui-ci.
Soulignons qu’il s’agit essentiellement d’une solution
pour tester SPIP. Dans le cadre d’une utilisation réelle pour diffuser de
l’information sur l’Internet, il faudra réaliser une installation chez un
véritable hébergeur.
Effectuer une mise-à-jour de SPIP est très
simple. Cependant, voici une méthode recommandée pour éviter les erreurs.
La procédure, décrite en
détail ci-après, peut sembler compliquée. En réalité, nous entrons
volontairement dans le détail de chaque opération pour vous éviter certaines
erreurs ; mais dans la pratique, la mise-à-jour de SPIP se réalise
en quelques minutes et est d’une
grande simplicité.
Avant toute modification
importante d’un système informatique, il est toujours conseillé d’effectuer une
sauvegarde de précaution.
Notez bien : il s’agit uniquement
d’une précaution. Vous n’êtes pas obligé de l’effectuer, et le fichier de cette
sauvegarde ne vous servira certainement à rien, puisque la mise à jour de SPIP se
déroulera sans problème !
C’est la même logique que
lorsque vous modifiez le système d’exploitation de votre ordinateur (installer
une nouvelle version de Windows, de MacOS ou de Linux...) : vous
sauvegardez vos documents importants, mais vous savez très bien que, si la
mise-à-jour s’est bien
déroulée, vous n’aurez pas besoin de réinstaller ces documents.
Ce point est
important : sauvegardez votre base de données avant la mise-à-jour, mais ne la réinstallez pas ! En effet, nous avons
constaté que de nombreux utilisateurs sauvegardaient leur base de données,
effectuaient la mise-jour, puis réinstallaient leurs documents à partir de
cette sauvegarde ; c’est une erreur, et leurs sites présentaient alors
des dysfonctionnements. La sauvegarde est une simple précaution en cas de gros
problème lors de la mise à jour, mais si l’opération se déroule bien (ce qui
est presque toujours le cas !), vous ne devez pas réinstaller
cette sauvegarde. (La sauvegarde est réalisée avec une structure des
données correspondant à la version précédente de SPIP ; si vous installez
ces données après la mise à jour, vous les réinstallez dans une structure qui a
évolué, provoquant ainsi l’apparition de problèmes.)
Pour réaliser la
sauvegarde de votre base de données (c’est-à-dire de l’intégralité de vos
documents réalisés avec SPIP), rendez-vous dans la page « Sauvegarde/restauration
de la base » de l’espace privé, et cliquez sur le bouton « Sauvegarder
la base ».
La procédure d’authentification par FTP
démarre :
La nouvelle page vous
indique un nom à recopier, du type « admin_xxxxx ». Copiez ce nom, et
démarrez votre logiciel-client FTP. Rendez-vous sur votre compte FTP
correspondant à votre site, et placez-vous dans le dossier « /data »
qui se trouve à l’intérieur du dossier « /ecrire ».
Dans ce dossier « /data », créez un nouveau dossier auquel vous
donnez le nom indiqué ci-dessus (votre nouveau dossier aura donc un nom de la
forme « admin_xxxx »).
Une fois ce dossier créé,
revenez à la page de votre butineur, et cliquez sur le bouton « recharger
cette page ». La sauvegarde est alors effectuée.
Si vous le désirez, vous
pouvez vérifier dans votre logiciel FTP que le document « dump.xml »
(ou « dump.xml.gz ») a été créé : ce document est la sauvegarde
de votre site. Vous pouvez la laisser sur votre compte FTP, ou la télécharger
sur votre propre ordinateur.
La véritable procédure de
mise-à-jour commence ici.
Le principe est très
simple : il suffit d’installer les fichiers de SPIP une nouvelle fois,
exactement comme vous l’aviez fait lors de la première installation. Soit avec
« spip_loader » qui effectue l’installation automatique des fichiers,
soit plus traditionnellement en décompactant SPIP sur votre propre disque dur
et en envoyant tous les fichiers par FTP chez votre hébergeur.
q Notez bien : il n’est pas nécessaire de supprimer les
fichiers de la version précédente. Cela n’est ni nécessaire ni conseillé :
en effet, si vous supprimez les anciens fichiers, vous devrez certainement
procéder à nouveau au paramétrage de SPIP (indiquer les données de connexion à
la base de données, etc.), procédure inutile si vous vous contentez d’écraser
les anciens fichiers avec les nouveaux. En effaçant les anciens fichiers, vous
risquez même d’effacer les images contenues dans vos articles !
Donc : restez simple : inutile d’effacer quoi que ce soit avant d’installer
les nouveaux fichiers ; les nouveaux écraseront les anciens
automatiquement...
Une fois tous les fichiers réinstallés (par FTP, ou
automatiquement avec « spip_loader »), rendez vous dans l’espace
privé de votre site.
q Notez bien : attendez que tous les fichiers soient bien installés chez votre hébergeur. Inutile d’essayer d’intervenir sur votre site pendant le transfert des fichiers, vous obtiendriez des résultats incohérents...
Dans votre espace privé, vous obtenez invariablement le message : « Message technique : la procédure de mise à jour doit être lancée afin d’adapter la base de données à la nouvelle version de SPIP. Si vous êtes administrateur du site, veuillez cliquer sur ce lien. » :
En tant
qu’administrateur, suivez le lien pour pouvoir déclencher la mise-à-jour de SPIP. Vous
arrivez sur un écran d’authentification par FTP, exactement similaire à
la procédure décrite plus haut (pour la sauvegarde de la base) :
Une nouvelle fois, copiez
le mot indiqué par cet écran et, avec votre logiciel-client FTP, créez un
nouveau répertoire dans « ecrire/data », et donnez-lui le nom que
vous venez de copier.
Cliquez sur « recharger
cette page », ce qui déclenche la mise à jour de la base de
données de SPIP.
Voilà, l’opération
de mise-à-jour est
terminée.
Répétons ce
conseil, car c’est une erreur très classique : ne réinstallez pas
la base de données à partir de la sauvegarde effectuée précédemment.
Cette sauvegarde correspond désormais à une ancienne structure des données,
elle est donc plus ou moins inutilisable. Si l’opération s’est bien déroulée,
vous pouvez même détruire cette ancienne sauvegarde.
En cas de pépin !
q À certains endroits de
l’espace privé (et parfois sur le site public), j’obtiens des messages d’erreur
du type « file not found », « file missing », ou d’autres
messages indiquant un problème de fichier incomplet ou manquant.
Il y a peut-être eu des
problèmes lors du téléchargement des fichiers par FTP ; avec votre
logiciel-client FTP, vérifiez la taille des fichiers incriminés ;
notamment, si un fichier a une taille de 0 ko, réinstallez ce fichier.
q J’obtiens beaucoup
de messages d’erreur.
Réinstallez
à nouveau l’intégralité des fichiers par FTP. On ne sait jamais...
q Mon site fonctionne à peu
près correctement, mais certaines fonctionnalités ne fonctionnent pas bien, les
rédacteurs rencontrent des problèmes alors que cela fonctionne bien pour les
administrateurs, etc.
Rendez-vous sur la liste de
diffusion des utilisateurs
de SPIP. Dans un premier temps, consultez les archives de cette liste pour
voir si votre problème n’a pas été déjà abordé. Sinon, exposez votre question
sur la liste en étant le plus précis possible : quel hébergeur, à partir
de quelle version avez-vous effectué la mise-à-jour ; n’oubliez pas de signaler si ce problème
apparaissait déjà ou non dans la version précédente. Si votre problème est un
bug encore inconnu, les développeurs travailleront très rapidement sur la
question pour livrer une version corrigée.
Les prémices de SPIP
remontent au courant de l’année 1998 : Pierre Lazuly souhaite développer
un système de publication pour faciliter la gestion de son site « Les chroniques du Menteur ». ARNO* a
réalisé en Server Side Includes (une technologie très rudimentaire) un petit
outil pour gérer les éditos du Scarabée
et, de son côté, Erwan a développé un outil pour gérer L’Ornitho.
Erwan est alors le seul à
savoir gérer une base de données, Pierre est en train de s’initier à PHP, et
ARNO* ne connait ni PHP ni les bases de données. Mais Pierre passe ses vacances
sur un bateau baptisé « SPIP » ; et comme « SPIP » est
l’acronyme de « Système de Publication pour l’Internet », cela suffit
à lancer le projet : on a le titre, le reste devrait être facile...
Cependant, malgré
quelques essais (un premier système gère un site à base de PHP, mais pas de
base de données, les informations étant stockées dans des fichiers selon un
format spécifique - une sorte de XML qui s’ignorait -, avec un premier
système d’identification des rédacteurs), le projet ne progresse guère. Il
faudrait en effet :
q pouvoir réaliser
n’importe quel type de site avec un même outil ;
q gérer ce site avec une
interface accessible à tous.
Lors d’une soirée, Erwan
dessine sur un bout de la nappe en papier du restaurant la structure d’une base
de données qui permettrait de réaliser n’importe quelle structure de site.
L’esthétique de la chose effraie ses deux compères, et SPIP en reste à ce stade
de la nappe de restaurant tâchée de café.
Pierre définit
l’utilisation de touches rarement utilisées dans un texte (les accolades
notamment) pour créer rapidement de l’italique et du gras, ce qu’il nomme les
« raccourcis SPIP ». Le système de publication des éditoriaux en
Server Side Includes est traduit en PHP, mais pas d’utilisation de la base de
données mySQL.
Juste avant l’été 2000, ARNO* réalise le site des éditions Vuibert, dont le principe est un système PHP/mySQL, une interface privée où les personnels de l’entreprise enrichissent eux-mêmes le site, et un système de droits qui permet à certaines personnes (les « administrateurs » du site) de valider certains éléments avant leur mise en ligne. À partir des éléments fournis par les éditeurs, le système permet en outre de fabriquer des documents de gestion interne à partir de fichiers HTML contenant des éléments conditionnels, auxquels on peut attribuer des filtres, ce qui deviendra un des principes des squelettes de SPIP.
Parallèlement, avec Fil,
il créé un système de publication simplifié pour gérer les « Cahiers
documentaires » du Monde
diplomatique pour lesquels, notamment, le système de raccourcis
typographiques est plus développé. La fonction qui gère la typographie
française et les raccourcis est diffusée à partir de la fin mai 2000 sous la
forme d’un fichier intitulé « spiplib.inc ».
Durant l’été 2000, le
Minirézo décide de relancer son site uZine, sous la forme d’un site dynamique
auquel n’importe qui pourrait participer. ARNO* développe un outil à base de
PHP et de MySQL, dont la particularité est la simplicité de l’interface de
gestion du site. L’ensemble est affreusement mal programmé, mais fonctionne...
En septembre 2000, le
lancement d’uZine 2 avec ce système valide l’idée qu’on peut utiliser une
interface graphique très simple pour gérer un site relativement complexe, afin
que n’importe qui puisse y participer sans connaissances techniques.
L’objectif de pouvoir réaliser n’importe quel type de site est écarté (le système correspond, à la base, aux besoins d’uZine 2), mais il est décidé que le système allait servir de base au système SPIP lui-même.
L’interface d’origine SPIP
Cette première version
comprend un correcteur orthographique basé sur le dictionnaire des mots communs
de l’ABU. Ce correcteur sera finalement
abandonné : impossible à diffuser à cause de la taille du dictionnaire
(plusieurs mégaoctets, plus de 300 000 mots) et, appliqué à un texte très
long, il mettait n’importe quel serveur sur les genoux... On trouve également
une exportation automatique de l’intégralité d’une rubrique vers un autre site
(fonctionnalité elle aussi abandonnée, et remplacée par un système de
syndication de
contenus) ; ainsi, les site Insurgence et Radiophare proposaient-ils des textes
tirés de rubriques d’uZine, récupérés automatiquement et reformatés selon leur
propre interface graphique.
Antoine participe à
partir de ce moment au développement de SPIP, Fil soutient le projet, et le
développement continue dans l’optique d’offrir un système complet sous licence
libre.
Une procédure
d’installation automatisée est intégrée, le principe des squelettes permettant
de réaliser des interfaces graphiques sans utiliser PHP est élaboré, un système
de cache est installé, et surtout des modifications importantes du système
d’authentification des rédacteurs permettent de faire fonctionner SPIP chez un
grand nombre d’hébergeurs.
Quelques semaines avant
le lancement officiel de SPIP, les sites uZine,
du Monde diplomatique et de Vacarme testent le système en conditions
réelles d’utilisation, et permettent de valider le système de cache, la gestion
d’une grande quantité d’information et le principe de l’interface de gestion
d’un site.
Le 1er juillet
2001 : SPIP 1.0 est lancé officiellement. L’intervalle de
temps important entre l’ouverture d’uZine 2 (avec une pré-version de SPIP)
et le lancement de SPIP est dû à plusieurs éléments :
q développer de nouvelles
fonctionnalités, stabiliser le produit (éliminer des bugs), nettoyer une partie
du code (qui était particulièrement sale), assurer une plus grande
compatibilité avec de nombreux hébergeurs ;
q redessiner une interface
graphique pour l’espace privé, qui permette d’inclure et hiérarchiser les 200 000
nouvelles fonctionnalités ajoutées au produit initial ;
q tester les choix du
système sur plusieurs sites aux contenus et aux fréquentations très
différents ;
q rédiger une documentation
complète du système (une véritable plaie !).
Octobre 2001 : SPIP 1.2 (il n’y a
pas eu de version officielle 1.1). Le processus de développement a
évolué : en effet, depuis le lancement officiel, il y a d’autres
utilisateurs de SPIP que ses développeurs ! Ainsi, les nouvelles
fonctionnalités répondent beaucoup plus aux besoins réels exprimés par les
webmestres (et non plus aux besoins d’uZine), plusieurs informaticiens
compétents apportent ponctuellement des solutions pour le développement, et le
débogage se fait quasiment en temps réel.
Janvier 2002 : SPIP 1.3. Le
développement continue, avec son lot de nouveautés. Un changement
dans le développement : de nombreux utilisateurs sont désormais très
compétents avec SPIP. De ce fait :
q les réponses aux
questions des utilisateurs débutants sont largement prises en charge par
d’autres utilisateurs, ce qui libère énormément de temps pour le développement
du système (le lancement officiel de SPIP avait provoqué une charge de travail
énorme pour les développeurs, dans l’explication de l’utilisation du
système) ;
q ces utilisateurs devenant
plus compétents, les nouvelles fonctionnalités de SPIP sont moins spectaculaires,
et concernent largement une utilisation poussée du système.
L’interface de SPIP 1.3
Septembre 2002 : SPIP 1.4. Refonte radicale de l’interface de l’espace privé ; le nombre de fonctionnalités devenait trop important pour l’ancienne interface, la nouvelle permet de mieux structurer et hiérarchiser les fonctions de SPIP. Fontion très attendue : SPIP permet désormais d’incorporer des documents joints (notamment multimédia) à son site.
L’interface de SPIP 1.4
Décembre 2002 : SPIP 1.5. Cette
version propose de nouveaux squelettes par défaut, nettement plus compatibles
avec la norme xhtml. Les autres modifications sont beaucoup plus discrètes pour
l’utilisation quotidienne de SPIP, mais renforcent nettement la stabilité et la
cohérence du système.
Mai 2003 : SPIP 1.6. L’énorme
nouveauté de cette version est la possibilité de changer la langue de l’espace
privé : on peut désormais utiliser SPIP anglais, italien, espagnol,
danois, allemand, arabe, créole réunionais, vietnamien... Un outil spécifique
facilitant la traduction de l’interface est créé. Les volontaires pour proposer
des traductions se regroupent sur la liste spip-trad.
L’interface de SPIP 1.6 en
arabe
N.B. L’interface graphique
est affichée de droite à gauche.
Janvier 2004 : SPIP 1.7. La
principale nouveauté de cette version est d’introduire le multilinguisme :
un site sous SPIP peut contenir des articles dans plusieurs langues, gérer des
règles typographiques et des affichages automatiques (dates, formulaires...)
dans plusieurs langues, et présenter les liens entre les différentes
traductions d’un article.
1.0.3. Cette version corrige
quelques petits bugs dans le moteur typographique, et accélère notablement
l’usage du cache.
1.0.4. Dans la foulée, nous
sortons la version 1.0.4, qui corrige un bug de la précédente, qui ne
concernait que certains serveurs. Si vous aviez installé la version 1.0.3 et
rencontré une erreur du type « Parse error on line 394 », installez
cette version 1.0.4.
1.0.5. Nouvelle version de
SPIP :
q La gestion des sites
syndiqués est améliorée. On peut désormais désactiver la syndication dans la page de
configuration (pour alléger l’interface).
q Les brèves proposent
également des forums internes, utilisables pour la validation (comme pour les
articles).
q Une nouvelle page permet
de suivre/gérer les forums publics, selon leurs threads, pour chaque article
individuel. Accès via la page de chaque article, et via la page générale de
suivi des forums.
q La fonctionnalité
« doublons » dans les squelettes est améliorée. Il y a
désormais des doublons pour les auteurs, les breves, les mots-cles, les
articles, les rubriques et les forums.
q Dans le site public, la
rapidité est accrue sur certaines grosses pages affichant beaucoup de titres
d’articles (notamment plan du site, rubriques, sommaire). En effet, le texte
d’un article n’est plus récupéré que quand il est réellement affiché.
q L’envoi de mail marche
désormais sur online.fr.
q L’envoi automatique des
messages de forum aux auteurs des articles marche de nouveau.
Parmi les nouvelles
fonctionnalités, les plus importantes sont :
q Administrateurs à
accès restreint
Cette fonction très
demandée (mais à l’utilité toute relative...) permet de créer des
administrateurs aux responsabilités limitées à une ou plusieurs rubriques du
site - et ainsi de déléguer une partie de la gestion, sans pour autant donner
« tout pouvoir » ; pour les rubriques qui ne lui sont pas
attribuées, cet administrateur a les mêmes droits qu’un rédacteur. Certaines
pages réservées aux administrateurs, qui concernent la gestion globale du site
(telles que « Configuration précise », ou la gestion des rédacteurs),
ne sont pas accessibles aux administrateurs à accès restreint.
q Messagerie interne
Un système de messagerie
interne complète les outils destinés à faciliter le travail coopératif sur un
site SPIP. Les rédacteurs peuvent échanger des messages (à un ou plusieurs
destinataires), chaque message ouvrant un forum privé entre ses destinataires.
Il est également possible de noter des « pense-bête ». Un calendrier
affiche les rendez-vous importants et récapitule l’activité éditoriale du site
selon une nouvelle présentation graphique.
La messagerie interne (que
l’on peut activer ou désactiver pour l’ensemble du site, mais à laquelle chaque
rédacteur peut décider individuellement de ne pas participer) est complétée
d’une liste des rédacteurs connectés à l’espace privé. Chaque rédacteur
connecté peut être ainsi contacté par l’envoi d’un message, simplement en
cliquant sur le logo associé à son nom. Chaque rédacteur peut décider,
individuellement, de ne pas apparaître dans la liste des rédacteurs connectés.
q Nouveau système de cache
L’espace public (toujours
calculé à partir des squelettes) bénéficie d’un nouveau moteur (nom de
code : « Pantagruel ») et d’un nouveau système de cache. Le
système de cache est désormais décomposé en deux opérations : l’analyse
des squelettes (création d’un fichier PHP pré-interprété), puis l’intégration
des données de la base de données pour chaque page et sauvegarde d’un fichier
cache indépendant pour chaque page.
Les gains de vitesse (et de charge sur le
serveur) apportés par ce nouveau moteur sont très importants.
q Flux compressé
SPIP utilise désormais,
lorsque le serveur l’autorise et lorsque le navigateur du visiteur est
compatible, la compression des données de PHP4 : les données échangées
entre le client et le serveur sont compactées, réduisant ainsi de manière très
importante la bande passante utilisée et les temps de chargement.
q Feuilles de style et
variables PHP pour modifier un peu plus les squelettes
Certaines informations
générées à partir de la base de données et des squelettes sont désormais
complétées d’indications de feuilles de style. Le webmestre a donc la
possibilité, s’il le souhaite, de pousser la personnalisation de sa mise en
page. Par exemple : des classes CSS différentes sont attribuées aux liens
hypertextes à l’intérieur du site et vers l’extérieur, ce qui permet de les
différencier graphiquement.
q Mots-clés sur les brèves
Des
mots-clés peuvent être associés aux brèves.
q Moteur de recherche interne
Un moteur de recherche interne permet
d’effectuer des recherches sur les titres des articles et des brèves.
q Syndication RSS1.0
La syndication des sites
(récupération de fichiers backend) par SPIP est désormais compatible
avec les fichiers RSS 1.0 (jusque là, seuls les RSS 0.9x étaient
compatibles).
q Critères négatifs dans
les boucles des squelettes
Il est possible
d’utiliser des critères d’exclusion dans les critères de sélection des boucles.
Par exemple de choisir les articles dont le surtitre n’est pas égal à
« Edito », les rubriques autres que la rubrique 6...
Les utilisateurs
trouveront encore une foule de petites modifications graphiques (la plupart
discrètes), il y évidemment de nombreuses corrections de bugs, et de nombreuses
fonctions ont reçu des optimisations permettant de gagner plus ou moins de temps
(très variables selon les sites, les textes...).
Une version de SPIP,
1.2.1, est disponible en ligne.
Elle corrige un bug
apparu chez certains hébergeurs (notamment Altern), pour des sites ayant
effectué la mise-à-jour de la version 1.0.6
à la 1.2. Ce bug se manifeste par la disparition des messages des forums
lorsque la messagerie interne de SPIP est activée. Ce problème ne concerne donc
que quelques sites.
Si vous avez rencontré ce
problème lors d’une mise à jour de votre site,
cette version 1.2.1 corrige le problème.
Si l’installation de la
version 1.2 n’a pas provoqué de difficultés avec les messages des forums, vous
n’avez pas besoin d’effectuer cette mise-à-jour.
La version 1.3 de SPIP
contient de très nombreuses modifications et nouvelles fonctionnalités. Les
nouveautés peuvent sembler peu spectaculaires (la version 1.2, notamment,
proposait des nouveautés beaucoup plus visibles), mais elles sont très
importantes. La plus visible est sans doute le nouveau système de
référencement de sites.
Les nouvelles
possibilités offertes par le langage de boucles concernent essentiellement les
webmestres qui savent créer leur propre interface graphique avec les squelettes
de SPIP ; fonctionnalités discrètes, mais qui permettent de réaliser des
sites à la navigation beaucoup plus complète qu’auparavant.
On trouvera le détail de
ces nouvelles modifications dans l’« Aide en ligne » de l’espace
privé de son site, dans la documentation de
SPIP (sur uZine), et dans le nouveau tutorial sur l’utilisation
avancée des boucles.
q Système de référencement
de sites. Le précédent système de syndication de sites Web est
entièrement refondu. Il est désormais possible de référencer n’importe quel
site Web ; pour chaque site référencé, on peut indiquer de manière
optionnelle une syndication de contenu (récupérer automatiquement la liste des
derniers articles publiés sur un site). De plus, pour chaque site référencé, on
peut installer un logo, et lui attribuer des mots-clés.
Les sites référencés
peuvent être proposés par les administrateurs, les rédacteurs ou les visiteurs
du site public (selon réglage dans la « Configuration précise » du
site). Un forum est attribué à chaque site pour discuter dans l’espace privé du
référencement (ou non) d’un site ; il est également possible d’attribuer
un forum public à chaque site référencé.
Le fonctionnement de la
syndication de contenu est
affiné : les auteurs et le descriptif de l’article sont récupérés (si le
site syndiqué les indique) ; il est possible de bloquer un article
syndiqué précis sans bloquer l’intégralité de la syndication. Lorsqu’un site
syndiqué n’est plus accessible, ou son fichier backend inutilisable, la
syndication est désactivée et les administrateurs se voient signaler le
problème (ce qui évite les blocages d’une rubrique contenant un site syndiqué
défaillant).
Cette nouvelle
fonctionnalité est sans doute la modification la plus visible de cette version
1.3.
q Éléments dépliables. Dans l’espace privé,
afin de limiter l’encombrement de certaines pages, et de privilégier la
présentation de certaines informations, de nombreux éléments apparaissent
masqués, mais affichages d’un simple clic sur un triangle noir. Cette
fonctionnalité n’est disponible qu’avec Mozilla et MSIE (pour les autres
butineurs, les éléments ne sont pas masqués).
La présentation des
mots-clés se fait désormais selon plusieurs menus déroulants, par groupes
de mots-clés.
q Date des brèves. Il est désormais
possible de modifier manuellement la date d’une brève (auparavant, la date
était fixée automatiquement lors de la validation et il n’était pas possible de
la modifier).
q Dates imprécises. Pour les articles et les
brèves, il est possible d’indiquer une date imprécise. C’est-à-dire une date
sans jour, ou même sans mois. On peut ainsi indiquer une date du genre « 5 mai
2001 » ou « mai 2001 » ou « 2001 ».
q Upload d’images par FTP. Pour contourner la
limitation imposées par certains hébergeurs qui interdisent l’installation
d’images par l’intermédiaire d’un formulaire Web, il est possible d’installer
les fichiers des images par FTP dans un dossier « /ecrire/upload ».
Ces fichiers seront alors proposés, dans l’espace privé, dans un menu déroulant
remplaçant l’interface de téléchargement habituelle.
q Forum interne des
administrateurs. En plus de l’habituel forum interne accessible à tous les
rédacteurs, apparition d’un forum interne réservé aux administrateurs.
q Nouveau raccourci <cadre>. Pour afficher un morceau
de code dans un article, un nouveau raccourci : <cadre>...</cadre>. Le texte à l’intérieur
de ces balises sera affiché dans une fenêtre de formulaire, ce qui facilite le
copier-coller par le lecteur.
Cela donne par
exemple :
<html> <head> <title>Le
titre</title> </head> <body> <h1>Ma
page</h1> Blah blah blah... </body> </html> |
q Les déplacements de
rubriques gèrent de manière plus cohérente le déplacement des brèves qui s’y
trouvent.
q Lorsque l’on peut
supprimer une rubrique (parce que cette rubrique est vide - on ne peut pas
effacer une rubrique contenant des éléments publiés, proposés ou en cours de
rédaction), un bouton « Supprimer cette rubrique » apparaît sur la
page de cette rubrique (auparavant, il fallait passer par la page
« Afficher tout le site »).
q Une rubrique qui ne
contient pas d’articles publiés, mais seulement des brèves ou des sites
référencés, est désormais accessible sur le site public (auparavant, il fallait
au moins un article publié).
Les
modifications qui suivent concernent le site public. Elles concernent donc,
pour l’essentiel, le système de boucles qui permet de créer les squelettes de
l’interface du site public.
q Modification backend. Le fichier de backend
d’un site sous SPIP peut désormais n’afficher que les articles d’un secteur.
« backend.php3 » affichera les derniers articles de l’ensemble du
site ; « backend.php3 ?id_rubrique=3 » n’affichera que les derniers articles d’un
secteur (où « id_rubrique=3 » indique le numéro du secteur).
q Backend pour les brèves. On peut désormais
appeler un fichier backend contenant les dernières brèves publiées sur le
site : « backend-breves.php3 ». Possibilité également de
restreindre l’affichage à un secteur.
q Sélection d’éléments
selon un mot-clé ou un groupe de mots. Il est désormais possible de sélectionner des
articles, des brèves ou des sites référencés en fonction d’un nom de mot-clé,
ou d’un nom de groupe de mot-clé.
Par exemple :
<BOUCLE_importants(ARTICLES){id_rubrique}{titre_mot=importants}> |
sélectionne les articles
de la rubrique courante, liés au mot-clé « importants ».
<BOUCLE_importants(ARTICLES){id_rubrique}{type_mot=note}> |
sélectionne les articles
de la rubrique courante, liés à des mots-clés du groupe de mots
« Note ».
Limitation : il
n’est pas possible de sélectionner selon plusieurs critères « titre_mot » dans une même boucle. Par exemple, on ne peut pas
récupérer en une seule boucle les articles associés aux mots
« importants » et « résumé ». Pour cela, il faut imbriquer
deux boucles successives.
q Date des rubriques. Il est désormais
possible de trier les rubriques {par date}. La « date »
des rubriques est calculée automatiquement : il s’agit de la date du
dernier article publié dans cette rubrique ou ses sous-rubriques. Cela permet
ainsi d’afficher les rubriques en fonction des derniers articles publiés dans
ces rubriques.
q Nouveau critère d’âge. Il était possible
d’afficher les rubriques en fonction de leur « âge » par rapport à la
date actuelle. Par exemple, les articles sélectionnés selon le critère {age < 30} étaient les articles publiés depuis moins de 30
jours. Un nouveau critère apparaît : « age_relatif », qui calcule l’âge par rapport à une date
« courante » (par exemple la date d’un article, ou même une date
passée dans l’URL de la page.
Ce nouveau critère permet
par exemple :
d’afficher les articles
publiés avant ou après un autre article ;
de créer des affichages
sous forme de calendrier (tous les articles publiés en mai 2002, par exemple).
q Nouveaux squelettes. Les squelettes fournis
en standard avec SPIP sont nommés « article-dist.html »,
« rubrique-dist.html »... Lorsque l’on réalise ses squelettes
personnels, on les nomme « article.html »,
« rubrique.html »... ; de cette façon, lors d’une mise à jour de SPIP, les
squelettes personnels ne sont pas écrasés.
q Squelettes pour une seule
rubrique. On peut désormais créer un squelette qui ne s’applique qu’à une seule
et unique rubrique (et non à ses sous-rubriques). Par exemple :
« article=60.html » s’applique à la rubrique 60, mais pas à ses
sous-rubriques.
Pour
résumer la nouvelle façon de nommer les squelettes :
q « article=60.html »
s’applique aux articles de la rubrique 60, mais pas aux articles de ses
sous-rubriques ;
q « article-60.html »
s’applique à tous les articles de la rubrique 60 et aux sous-rubriques de la
rubrique 60 ;
q « article.html »
est le squelette personnalisé qui s’applique à l’intégralité du site (si le
fichier « article.html » existe, « article-dist.html »
n’est plus du tout utilisé) ;
q « article-dist.html »
est le squelette fourni par défaut avec SPIP.
q Classement numéroté. Pour forcer l’ordre
d’affichage d’éléments tels que les rubriques ou les articles, il est très
simple de faire précéder leur titre d’un numéro d’ordre (par exemple :
« 1. Mon premier article », « 2. Mon deuxième
article »...).
Pour forcer l’affichage
selon le numéro qui précède le titre, on peut utiliser le critère {par
num titre}. Si l’on se contente d’utiliser {par
titre},
on obtient un classement du type : 1, 10, 11, 2, 3...
De plus, pour ne pas
afficher ce numéro, on utilise le filtre « supprimer_numero ». Dans les squelettes concernés, il suffit
d’afficher le titre ainsi :
[(#TITRE|supprimer_numero)] |
Une bonne
partie de ces nouvelles fonctionnalités concerne les utilisateurs confirmés de
SPIP, c’est-à-dire les webmestres qui modifient eux-mêmes les squelettes de
leur site.
Afin de montrer
comment utiliser ces nouvelles fonctions, mais aussi pour réaliser des sites à
la navigation plus complète (et complexe) que les sites réalisés avec les
squelettes standards, un nouveau tutorial explique l’utilisation avancée des
boucles et des mots-clés. Ce tutorial exploite notamment plusieurs des
nouvelles fonctionnalités de la version 1.3 (par exemple l’appel d’articles en
fonction d’un mot-clé).
Enfin il y a une
multitude de petites modifications d’interface, souvent très discrètes,
l’optimisation de certaines parties du code, et la correction de nombreux bugs.
Cette version 1.4
de SPIP, après six mois de
développement, propose des changements très importants. Certains concernent
tous les utilisateurs (notamment les rédacteurs), d’autres sont destinés à
faciliter le travail des webmestres qui crééent leurs propres squelettes, et
certains sont très techniques (sécurité, développement...).
La mise à jour peut se faire
depuis n’importe quelle version antérieure de SPIP.
Si vous utilisez
habituellement l’installation automatique, il vous suffit d’appeler le fichier
spip_loader.php3 depuis votre navigateur comme pour les versions précédentes,
puis de suivre les instructions affichées pour la mise à niveau de la base de
données.
Si vous préférez
l’installation manuelle à partir d’une archive téléchargée depuis l’URL
ci-dessus, il vous faut :
1. décompresser l’archive
que vous aurez choisie (il y a trois formats : zip, sit et tgz, mais ce
sont les mêmes fichiers) ;
2. envoyer les fichiers
par FTP sur votre site (en écrasant éventuellement les fichiers
précédents : pensez à faire une sauvegarde de vos squelettes auparavant,
en cas de fausse manipulation).
3. vous rendre dans
ecrire/ et suivre les instructions (il vous faudra créer un fichier ou
répertoire particulier dans ecrire/data/ puis laisser SPIP faire la mise à
niveau de votre base de données).
Et c’est tout !
Remarques
importantes :
q Vous pouvez auparavant
faire une sauvegarde de votre base de données ; sachez toutefois que vous
n’aurez normalement pas besoin de cette sauvegarde, SPIP se chargeant tout seul
de la mise à niveau de votre base de données. D’autre part, cette sauvegarde ne
pourra pas être restaurée sans dommage sur une version plus récente que votre
version actuelle ; elle ne doit donc être utilisée qu’en dernier
ressort !
q Surtout, NE VIDEZ PAS
VOTRE BASE DE DONNÉES AVANT DE FAIRE LA MISE À JOUR. (L’erreur est
classique, certains imaginant, à tort, qu’il faut vider la base de données pour
ensuite restaurer la sauvegarde).
En cas de soucis
d’affichage sur le site public, essayez de vider le cache de votre site pour
voir si le problème persiste.
q Si votre site affiche des
messages d’erreur étranges (erreurs PHP, etc.) vérifiez que tous les fichiers
ont été correctement transférés via FTP, et qu’aucun des fichiers n’a une
taille zéro sur le serveur. Eventuellement, réessayez le transfert en changeant
le mode de transfert dans
votre logiciel FTP (le mode binaire est normalement préférable).
q Si vos problèmes
persistent, ou pour toute autre question, n’hésitez pas, après avoir cherché
dans la documentation, à écrire à spip@rezo.net. N’oubliez pas de mentionner la
version de SPIP utilisée et de décrire précisément le problème (URL de la page
incriminée, etc.).
q L’interface privée propose une interface
graphique radicalement différente des versions précédentes. Elle permet en
particulier :
q de mieux distinguer et hiérarchiser les
différentes fonctionnalités de SPIP ;
q une intégration facilitée des nouvelles
fonctionnalités tout en conservant la cohérence de la navigation ;
q de créer (pour les prochaines versions) des
versions non françaises de SPIP.
Impossible de détailler
toutes les nouvelles caractéristiques de l’interface, celle-ci étant
entièrement nouvelle. Signalons tout de même :
q le choix entre une
interface « normale » (logos et textes), une interface réduite
n’affichant que les icones, et une interface allégée entièrement en mode texte (pour les
connexions lentes) ;
q une plus grande
différenciation entre l’interface simplifiée et l’interface complète,
facilitant le travail des débutants ;
q un mode « grand
écran » pour les utilisateurs disposant d’écrans à la largeur supérieure
ou égale à 1024 pixels ;
q des
« raccourcis » dans l’interface proposant les fonctions les plus
utilisées en fonction de la page où l’on se trouve.
Il s’agit sans doute de
la fonction la plus attendue de cette nouvelle version : SPIP permet
d’associer des documents de formats multimédia (audio, vidéo, PDF...) à des
articles ou de les installer dans des rubriques.
q Ces documents peuvent
être présentés en tant que documents joints, ou présentés à l’intérieur d’un
article (sous la forme d’une vignette dotée d’un lien hypertexte). Pour cela,
SPIP propose un nouveau raccourci : <docxxx|center>.
Il est possible également
d’insérer directement certains documents (vidéo, animations flash...) à
l’intérieur des articles, grâce au nouveau raccourci : <embxxx|center>. Il est possible, pour ceux qui désirent un contrôle
plus précis du comportement de ces documents, de compléter ce raccourci des
paramètres propres à ces formats, par exemple :
<embxxx|center|autostart=true|quality=high> |
Pour gérer les documents
qui ne sont pas directement insérés dans le texte des articles, un nouveau
format de boucles apparaît : (DOCUMENTS).
q Au passage, grâce à
l’introduction de ces documents, les images profitent de certaines
améliorations : possibilité de leur donner un titre et d’indiquer un
descriptif. Ces informations seront affichées dans les articles grâce au
raccourci : <docxxx|center>.
De
plus, on peut désormais insérer des images dans les brèves.
q Sur certains serveurs,
SPIP facilite grandement la création automatisée de portfolio (collections
d’images présentées sous forme de vignettes cliquables), avec création
automatique de vignettes de prévisualisation.
Le système de mots-clés
évolue largement, afin d’offrir une plus grande précision des affichages ;
cette nouveauté est en particulier conçue pour les webmestres qui gèrent beaucoup
de mots-clés sur leur site.
q Mots-clés sur les
rubriques.
q Les mots-clés
appartiennent forcement à un groupe de mots.
q Chaque groupe peut etre
« lié » aux articles, et/ou brèves, et/ou rubriques, et/ou sites
syndiqués. De plus, on peut décider que certains groupes sont réservés aux
admins et/ou aux rédacteurs. On peut également décider que certains groupes de
mots sont accessibles à partir des forums publics, et même avec des icones.
q Possibilité d’entrer
plusieurs mots-clés d’un seul coup dans les cases de formulaire, séparés par
des virgules ou des points-virgule. À partir de 4 mots-clés associés a un
article, un bouton « retirer tous les mots » apparaît.
q Prévisualisation des
messages des forums publics avant de poster.
q La modération des forums
se décide désormais article par article, avec une option par défaut (qui
s’applique également aux forums de rubrique, de brèves, etc.. de manière
indifférenciée pour le coup).
q Prévisualisation des
messages des forums privés avant de poster.
q Quand on demande un
article depuis une page recherche, coloration des mots de la recherche dans le texte de
l’article.
q La recherche dans l’espace
privé utilise désormais, en plus des « titres et numéros », la
recherche en texte intégral si elle est disponible.
Il est possible de gérer
plusieurs sites sous SPIP dans une même base MySQL : configuration
manuelle dans ecrire/inc_version.php3, tout au début (mettre un préfixe
différent pour chaque installation).
Attention : cette fonctionnalité est
réservée aux utilisateurs confirmés.
q Possibilité de passer
certains sites syndiqués en « modération a priori », de manière à
valider les articles syndiqués un par un. Évidemment, cela enlève beaucoup de
charme à la syndication de sites, censée
faire vivre votre propre site en l’absence du webmaster
q Possibilité d’utilisation
d’un proxy HTTP pour syndiquer les sites (réservé aux utilisateurs confirmés).
q Inclusion de squelettes à l’interieur d’un autre squelette. Pour inclure un squelette machin.php3 en lui passant le numéro de rubrique, faire par exemple :
<INCLURE(machin.php3){id_rubrique}> |
q Modification du
comportement de #INTRODUCTION des articles :
q s’il y a un descriptif,
c’est ce descriptif qui est directement utilise (tel quel, avec propre) ;
q s’il n’y a pas de
descriptif, comportement habituel (resume chapeau + texte).
q Critère {branche}, qui permet de récupérer
toutes les sous-rubriques d’une rubrique (expérimental).
q Nouvelles balises #LOGO_RUBRIQUE_SURVOL et #LOGO_RUBRIQUE_NORMAL, utile pour une maquette ou le logo de la rubrique
courante est toujours affichee en survol. (Principe similaire aux #LOGO_ARTICLE_NORMAL et #LOGO_ARTICLE_SURVOL qui existent déjà dans les versions
précédentes.)
q Nouvelle balise #LOGO_BREVE_RUBRIQUE, qui affiche le logo de
la brève ou, à défaut, celui de la rubrique contenant la brève. (Principe
similaire à #LOGO_ARTICLE_RUBRIQUE.)
q Nouvelle balise #FORMULAIRE_ECRIRE_AUTEUR qui affiche un formulaire permettant d’écrire
à un auteur, sans jamais faire apparaître son adresse email sur le site public.
q Gestion des filtres sur LOGO_xxx et sur FORMULAIRE_RECHERCHE, la syntaxe [(#TOTO||filtre)] assure que |filtre est un filtre.
q Aide au débogage des
squelettes en cas d’erreur MySQL
q Variables de présentation
du type $debut_intertitre... réglables soit de
manière globale dans mes_fonctions.php3, soit de manière plus
fine dans article.php3, rubrique.php3, etc.
De nouveaux raccourcis
complètent la gestion des listes :
Raccourci |
Fonction |
- (tiret
espace) |
puce spip
standard |
_ (underscore
espace) |
<br>
saut de ligne sans puce |
* ,
**... |
<ul><li>...
Listes hiérarchiques |
# ,
## ... |
<ol><li>...
Listes numériques |
q Nouveau système
d’authentification des visiteurs (dans l’espace privé, mais aussi dans l’espace
public), à base de cookies. Le système est conçu pour assurer un plus grand
niveau de sécurité, mais aussi pour offrir une plus grande compatibilité avec
les différents hébergeurs.
Lors de la mise a jour de spip, il est
conseillé de vérifier qu’on n’utilise pas la méthode « .htaccess »
(supprimer le fichier
ecrire/.htaccess s’il existe). Si on ne veut pas de cookies (ou si
le navigateur ne les aime pas), le système propose de basculer sur une
authentification http a l’ancienne.
q Le système propose deux
niveaux de sécurité : l’un est plus adopté aux utilisateurs qui
« bidouillent » avec plusieurs navigateurs en même temps, ou plus
ordinateurs simultanément, et un système nettement plus strict, qui interdit
toutes connexions simultanées et offre un niveau de sécurité plus élevé.
q Un bouton « Se
déconnecter » est proposé en permanence, son utilisation est notamment
conseillée aux utilisateurs « mobiles » (connexion depuis un
ordinateur qu’ils ne sont pas seuls à utiliser).
q Pour les utilisateurs qui
ont oublié leur mot de passe, le système gère désormais la possibilité de
récupérer un nouveau mot de passe, grâce à un échange d’email.
q ATTENTION : On ne crée plus
les fichiers .htpasswd et .htpasswd-admin s’ils
n’existent pas déjà (sécurite).
Nouveau système de
statistiques, nettement plus fiable que la version précédente (la version
précédente était destinée à fournir une « indication » des visites,
et non une information précise).
Le système se composé de
deux parties : visites (relativement léger) et referers (plus lourd). La
connaissance des referers permet de plus la mise à jour quotidienne d’un
« pourcentage de popularité » par article. Ainsi l’article le plus
« populaire » est à 100%. (Pour plus de détails lire La « popularité » des
articles.)
La nouveauté la plus
visible est la présence de graphiques affichant l’évolution des visites jour après jour pour
l’ensemble du site et pour chaque article publié.
q Exportation de la base en
plusieurs étapes si le serveur interrompt la sauvegarde avant la fin de
l’exportation complète.
q Amélioration de la
compatibilité avec les différentes configurations de PHP : les tags PHP
passent en <?php (compatibilité avec l’option PHP
« short_open_tags »).
q Ajout d’une page ecrire/admin_repair.php3 permettant de mettre en
œuvre le système d’auto-réparation de MySQL suite à un plantage (crash disque,
etc.) [Versions de MySQL à partir de 3.23.14]
Quelques incompatibilités et petits bugs ont été corrigés
depuis la sortie de la version 1.4 - après les avoir corrigés, nous avons
publié une 1.4.2 dont les caractéristiques principales sont identiques à celles
mentionnées dans cet article. Pour plus de détails voir les annonces récentes.
La mise à jour peut se faire
depuis n’importe quelle version antérieure de SPIP.
Si vous utilisez
habituellement l’installation automatique (spip_loader.php3), il vous suffit de
recharger ce fichier et de suivre les instructions.
Si vous utilisez
l’installation manuelle à partir d’une archive téléchargée depuis l’URL
ci-dessus, il vous faut :
La mise à jour est un peu plus
lourde que pour les versions précédentes, puisqu’il vous faudra supprimer le
fichier ecrire/inc_connect.php3 et entrer de nouveau vos données de connexion à la
base (nota bene : avant d’effacer inc_connect.php3, faites-en une copie sur votre disque dur - ce fichier
contient les données de connexion en question, ce qui pourra vous être utile si
vous les avez oubliées).
Et c’est tout !
Remarques
importantes :
q Vous pouvez auparavant
faire une sauvegarde de votre base de données ; sachez toutefois que vous
n’aurez normalement pas besoin de cette sauvegarde, SPIP se chargeant tout seul
de la mise à niveau de votre base de données. D’autre part, cette sauvegarde ne
pourra pas être restaurée sans dommage sur une version plus récente que votre version
actuelle ; elle ne doit donc être utilisée qu’en dernier ressort !
q Surtout, ne videz
pas votre base de données avant de faire la mise-à-jour. (L’erreur est classique, certains imaginant, à
tort, qu’il faut vider la base de données pour ensuite restaurer la
sauvegarde).
q Comme indiqué dans la documentation,
sauvegardez votre base de données avant la mise-à-jour, mais ne la réinstallez pas ! Cette sauvegarde ne sert
que pour assurer la sécurité en cas de problème lors de la manipulation, mais
ne doit surtout pas être utilisée si la mise-à-jour s’est déroulée
correctement.
La documentation de SPIP
a été mise à jour pour la version
1.5, vous la trouverez à l’adresse http://www.uzine.net/spip ;
les nouveautés sont mentionnées par [SPIP 1.5].
Si vous relevez une
erreur, une incohérence, ou un passage incompréhensible, merci de bien vouloir
le signaler sur la liste
des développeurs, en précisant bien le nom ou l’adresse URL complète de la
page.
Rappelons par ailleurs
que vous pouvez trouver sur ce site une liste de toutes les balises
mise à jour.
q En cas de souci
d’affichage sur le site public, essayez de vider le cache de votre site pour
voir si le problème persiste.
q Si votre site affiche des
messages d’erreur étranges (erreurs PHP, etc.) vérifiez que tous les fichiers
ont été correctement transférés via FTP, et qu’aucun des fichiers n’a une
taille zéro sur le serveur. Eventuellement, réessayez le transfert en changeant
le mode de transfert dans
votre logiciel FTP (le mode binaire est normalement préférable).
q Si vos problèmes
persistent, ou pour toute autre question, n’hésitez pas, après avoir cherché
dans la documentation, à écrire à spip@rezo.net. N’oubliez pas de mentionner la
version de SPIP utilisée et de décrire précisément le problème (URL de la page
incriminée, etc.).
Entre la version 1.4.2 et la version
1.5 de SPIP de nombreux changements ont été apportés, de nombreux bugs ont été
corrigés. Tous ne sont pas mentionnés ici. Voici toutefois une liste des
principales nouveautés de la version 1.5
La nouveauté la plus
spectaculaire est l’apparition de nouveaux squelettes par défaut. Les autres
modifications sont beaucoup plus discrètes pour l’utilisation quotidienne de
SPIP, mais renforcent nettement la stabilité et la cohérence du système.
q Nouveaux squelettes par
défaut, à peu près conformes W3C, accessibles, plus jolis et plus propres que
les anciens.
q Accessibilité :
ajout d’une page sommaire-texte.php3, gérée depuis le
squelette sommaire-texte(-dist).html ; cette page en
texte seul présente les 3 derniers articles et les 5 dernières brèves du site.
Elle vise à fournir un début de solution à ceux qui veulent faciliter la
lecture du site aux utilisateurs de terminaux texte, braille, synthèse vocale,
etc. Notons que les nouveaux squelettes par défaut sont relativement lisibles
en mode texte, bien que
plus évolués graphiquement dans un navigateur classique.
Par convention, cette
page est accessible par l’adresse oo (deux fois la lettre
« o » minuscule), par exemple http://www.uzine.net/oo.
Tous retours sur la
commodité des nouveaux squelettes sur navigateurs non-graphiques bienvenus
(l’espace privé, quant à lui, est toujours difficilement praticable en mode texte,
malheureusement).
q Le raccourci [->http://lien_très_long......long] voit son texte coupé à
35 caractères. Cela ne concerne donc que les liens constitués d’une URL.
q Meilleur affichage des
« auteurs » du site (y compris les « visiteurs »,
c’est-à-dire les participants aux forums sur abonnement).
q Modification des
processus d’identification à l’espace privé. De nouveaux mécanismes permettent
de simplifier l’interface tout en augmentant la souplesse et le la sécurité.
q L’interface simplifiée
devient plus cohérente, et utilisable en permanence pour des sites pas trop
sophistiqués
q Ajout d’un tag #PUCE correspondant à la petite « puce »
utilisé à l’intérieur des articles pour marquer les énumérations (correspondant
la plupart du temps au fichier graphique puce.gif).
q Dans la boucle ARTICLES, une nouvelle balise #DATE_MODIF (au format date, à utiliser, donc, avec des
filtres comme |affdate) donne la date de « dernière modification de
l’article » : en fait, il s’agit, plus précisément, de la dernière
date à laquelle on a ouvert l’article en édition, même si on n’a ni modifié
ni validé l’article. Ce n’est pas un bug ;-)
q Possibilité de mettre
tous les squelettes dans un dossier (dont le nom est défini de manière
centralisée dans mes_fonctions.php3), ce qui permet d’essayer plus facilement plusieurs jeux
de squelettes. Voir à ce sujet la variable dossier_squelettes de la documentation sur les
variables de personnalisation.
q Boucle (GROUPES_MOTS) avec les balises #TITRE, #ID_GROUPE... pour la gestion des
groupes de mots-clés.
q Possibilité de mettre
plusieurs #FORMULAIRE_ECRIRE_AUTEUR dans une même page.
q Les mails « Quoi de
neuf » (annonce des nouveautés sur une mailing-list par exemple) sont
personnalisables via un squelette nouveautes(-dist).html.
q Passage de paramètres
dans les filters. La syntaxe est :
[(#BALISE|filtre{arg1, arg2}|...)] |
Le filtre doit être
défini de la manière suivante dans mes_fonctions.php3 :
function filtre($texte, $arg1='valeur par defaut1', $arg2='valeur par défaut 2') { ....calculs.... return (une chaine de caractères); } |
Cela permet donc aux
utilisateurs maîtrisant PHP de créer des filtres utilisant des fonctions PHP à
plusieurs variables (jusqu’à présent, les filtres pour les squelettes de SPIP
étaient par définition des fonctions PHP à une seule variable).
q Ajout d’une balise #EMAIL_WEBMASTER (configurable depuis ecrire/) correspondant à
l’adresse du webmestre « principal » du site.
q
Ajout de id_syndic_article dans le contexte et gestion dans la boucle(SYNDIC_ARTICLES) du critère {id_syndic_article}
q Nouveau tag #FORMULAIRE_ADMIN pour placer les boutons d’admin (recalculer,
modifier cet article, etc.) où l’on veut dans la page. Par défaut, si le tag
n’est pas utilisé, les boutons restent affichés en bas de HTML comme
auparavant, ce qui pouvait entraîner des bizarreries de rendus dans certains
squelettes utilisant du HTML relativement spécifique.
q Ajout d’une balise #CHARSET, qui par défaut vaut iso-8859-1, mais peut se régler sur
une autre valeur dans la configuration du site / options avancées. Les
différentes fonctions de SPIP marchent correctement en iso-8859-1, et
raisonnablement bien en utf-8 ; d’autres charsets pourront être ajoutés
par la suite.
q Nouveau tag #URL_LOGOUT, qui fait le pendant de #LOGIN_PUBLIC ; ce tag accepte un
seul filtre, l’URL de destination post-logout (par défaut, il tourne sur
lu-même).
q Ajout du support LDAP
Le support LDAP permet
d’authentifier et importer automatiquement de nouveaux auteurs depuis un
annuaire extérieur. Le réglage est effectué à l’installation si l’extension LDAP est présente
dans PHP. L’authentification d’un nouvel auteur depuis LDAP entraîne ensuite la
création d’une nouvelle entrée dans la table auteurs. Les caractéristiques
propres à SPIP (statut, préférences...) continuent à être gérées dans cette
table (l’annuaire n’est pas encombré d’infos supplémentaires). D’autre part, on
peut continuer à ajouter des auteurs sous SPIP indépendamment de leur présence
ou non dans l’annuaire externe.
q Correction d’un bug de
lecture des backend (la description d’un article pouvait passer comme
description du site)
q Calcul des referers plus
solide, et toutes les 30 minutes au lieu d’une
fois/jour
q Possibilité d’avoir un
mot de passe MySQL contenant des « $ »
q Mise à jour obligatoire du
fichier ecrire/inc_connect.php3 : soit votre site
vous prend par la main et explique qu’il faut supprimer ce fichier pour
réinstaller, soit il affiche subitement une page blanche (ce n’est pas le cas
en général, mais selon le moment où vous avez installé, ça peut arriver)...
tout revient à la normale dès que vous avez supprimé inc_connect.php3 puis réinstallé la connexion
à la base.
q Introduction d’un
mécanisme de log. Les événements importants sont consignés dans le fichier ecrire/data/spip.log. Les anciens fichiers
sont automatiquement supprimés (pas de risque d’exploser l’espace disque).
q La possibilité d’ajouter
des documents joints aux articles et/ou aux rubriques est désormais
configurable. Par défaut on peut joindre des documents aux articles, mais pas
dans les rubriques.
q Les rédacteurs peuvent
mettre eux-mêmes un logo sur leurs articles (tant que ceux-ci sont éditables,
bien sûr).
q Meilleure gestion en cas
d’erreur d’écriture sur le disque : en particulier, on ne traîne plus un
skel_xxx vide qui pouvait planter le site indéfiniment.
q Compatibilité
installation sur les serveurs nexen.
Quelques petites corrections
faites depuis la sortie de la version 1.5 - et un gros trou de sécurité repéré
dans la version 1.5.1 - sont rassemblées dans cette version 1.5.2, dont les
caractéristiques principales sont identiques à celles mentionnées dans cet
article. Pour plus de détails voir les annonces récentes.
La mise à jour peut se faire
depuis n’importe quelle version antérieure de SPIP.
Si vous utilisez
habituellement l’installation automatique, il vous suffit de lancer le fichier
spip_loader.php3 depuis votre navigateur et de suivre les instructions
affichées.
Si vous utilisez
l’installation manuelle à partir d’une archive téléchargée depuis l’URL
ci-dessus, il vous faut :
q Choisir une archive : le format ne
dépend que de vous, les fichiers à l’intérieur sont identiques ; notez que
si vous avez une connexion lente, vous pouvez choisir une version monolingue
(l’archive est alors suffixée du code de la langue : par exemple
"-fr" pour le français).
q Décompresser l’archive que vous aurez
choisie.
q Envoyer les fichiers par FTP sur votre site
(en écrasant éventuellement les fichiers précédents : pensez à faire une
sauvegarde de vos squelettes auparavant, en cas de fausse manipulation).
Attention : veillez à ne pas écraser
au passage le contenu du répertoire IMG/. Celui-ci contient en effet toutes les
images et les documents attachés de votre site !
q Vous rendre, avec votre navigateur, dans
ecrire/ et suivre les instructions (il vous faudra créer un fichier ou
répertoire particulier dans ecrire/data/ puis laisser SPIP faire la mise à
niveau de votre base de données).
Et
c’est tout !
Remarques importantes (et
habituelles) :
q Vous pouvez auparavant
faire une sauvegarde de votre base de données ; sachez toutefois que vous
n’aurez normalement pas besoin de cette sauvegarde, SPIP se chargeant tout seul
de la mise à niveau de votre base de données. D’autre part, cette sauvegarde ne
pourra pas être restaurée sans dommage sur une version plus récente que votre
version actuelle ; elle ne doit donc être utilisée qu’en dernier
ressort !
q Surtout, NE VIDEZ PAS VOTRE BASE DE DONNÉES AVANT DE FAIRE LA MISE À JOUR. (L’erreur est classique, certains imaginant, à tort, qu’il faut vider la base de données pour ensuite restaurer la sauvegarde).
La documentation a été mise à jour ; elle comporte deux nouveaux
articles :
C’est le plus gros
changement dans SPIP depuis la version 1.5 : l’espace privé, l’aide en
ligne et une petite partie de l’espace public (à savoir les formulaires gérés
automatiquement par SPIP) sont désormais disponibles en plusieurs langues.
Au moment de
l’installation de SPIP, vous pourrez choisir une langue pour l’affichage de
l’interface. Cette langue sera également adoptée comme "langue par
défaut" de votre site. C’est ce réglage qui déterminera :
q la langue dans laquelle sont affichés les
formulaires de l’espace public (formulaires de recherche, de commentaires dans les forums,
d’identification pour l’espace privé, etc.)
q les règles appliquées par le moteur
typographique (seuls le français et l’esperanto subissent la correction
typographique française complète)
Ne vous inquiétez pas,
vous pouvez modifier ce réglage par la suite, à tout moment, dans la
configuration du site sous la catégorie "options avancées". De plus
chaque rédacteur ou administrateur peut, indépendamment du reste, modifier la
langue utilisée par l’interface lorsqu’il visite l’espace privé. Vous pouvez
ainsi accueillir des communautés de rédacteurs / administrateurs de langues variées.
D’autres langues sont en
préparation, et si vous voulez participer à l’effort de traduction, vous pouvez
prendre contact avec la liste spip-trad@rezo.net
Si vous souhaitez discuter
de SPIP dans une des langues déjà intégrées, des listes spécifiques ont été
mises en place, ainsi que des sites de référence : leur adresse est
spip-xx@rezo.net et http://www.uzine.net/spip-xx (où xx doit être remplacé par
le code de la langue en question). Parfois le "site de référence" ne
propose que la liste : c’est que tout est encore en chantier.
REMARQUE
IMPORTANTE : il est très probablement préférable de commencer, lors
d’une nouvelle installation, par aller dans la configuration avancée pour choisir
le jeu de caractères ’utf-8’ plutôt que le traditionnel et vieillissant
’iso-8859-1’.
Plusieurs jeux de
caractères courants sont supportés, notamment utf-8, iso-8859-1, iso-8859-15,
windows-1251 (cyrillique) ; la syndication est, elle aussi,
totalement compatible d’un site à l’autre indépendamment des jeux de caractères
choisis.
q Fonctions de
translittération multilingue : dans la mesure du possible les caractères
accentués ou non-occidentaux sont traduits dans leurs "équivalents"
(non-accentués, phonétiques...) ; la précision de la translittération
dépend en partie de la configuration de PHP, pour les jeux de caractères non
intégrés à SPIP.
Ainsi un mot en
cyrillique sera indexé sous sa forme translittérée en ASCII, (par
exemple : "teoreticheskaya"). La recherche donnera des
résultats aussi bien sur la forme originale du mot que sur la forme
translittérée. C’est en fait une généralisation du mécanisme qui permettait
déjà d’effectuer des recherches en français, allemand (etc.) sans avoir à taper
les accents.
q Quand la langue du site
est ’vi’ (vietnamien), la translittération est plus complexe : les accents
sont codés par des chiffres, et la recherche peut se faire
aussi bien à partir de mots tapés avec tous les accents qu’à partir de la
translittération classique (a^.) ou spip (a65)...
q Le tiret bas (underscore)
n’est plus considéré comme un séparateur de mots, mais comme un caractère
alphabétique (documentation informatique).
q On peut maintenant
indexer les sigles de deux lettres et plus, y comprenant ceux contenant des
chiffres (G8, CNT...). Un sigle est un mot ne comprenant aucune minuscule.
q En raison de ces
améliorations, la mise à jour de SPIP déclenche
exceptionnellement la réindexation complète de votre site (si le moteur de
recherche est activé).
q Modification du
fonctionnement du $dossier_squelettes, pour le rendre plus
souple et compatible avec <INCLURE> : désormais SPIP recherche, dans l’ordre, dossier_squelettes/fond=10.html, puis dossier_squelettes/fond-8.html (en remontant la
hiérarchie des rubriques 10, 8, etc. vers la racine), puis dossier_squelettes/fond.html, puis ./fond.html à la racine du site,
puis ./fond-dist.html
Pour les <INCLURE(fichier.php3)>, SPIP regarde si le
fichier dossier_squelette/fichier.php3 existe (et l’inclue le
cas échéant) ; et sinon il inclue ./fichier.php3 (sans nécessairement
vérifier son existence).
q La génération automatique
de vignettes (activable dans la configuration du site, dans la catégorie
"options avancées") est désormais compatible avec plus de systèmes,
et les vignettes générées sont de meilleure qualité (il est conseillé
d’utiliser PHP 4.3 ou supérieur pour avoir des résultats optimaux).
q La syndication des sites
référencés accepte un plus grand nombre de formats de « backends »,
et reconnaît plus d’informations à l’intérieur de ceux-ci (compatibilité avec
les formats RSS 0.91, 1.0, 2.0, et récupération des dates et auteurs selon
divers formats)
q Les fichiers de
syndication générés par SPIP (backend.php3 pour les articles, backend-breves.php3 pour les brèves) sont
plus complets, ils contiennent notamment la date exacte de publication des
"items" syndiqués.
q La balise #DATE_NOUVEAUTES permet d’afficher la date du dernier envoi du
mail présentant les nouveautés.
q correction du bug des
critères {age} et {age_relatif} ; ceux-ci permettent désormais de distinguer deux
articles publiés le même jour (notion de
« précédent » de « suivant »)
q introduction des critères
{jour_relatif}, {mois_relatif} et {annee_relatif}, comme extension de l’{age_relatif}, mais arrondi au jour, au
mois et à l’année (ce qui permet de faire désormais une boucle pour « tous
les les articles du mois de mars 2003 » [spéciale dédicace aux amateurs de
weblogs])
q nettoyage de la date
passée dans l’URL : 2003, 2003/01, mais aussi, à partir de php3.0.12
(utilisation de la fonction strtotime), date=-1year, date=1march1970, etc.
q #DATE peut s’utiliser hors des boucles (contexte ou
URL)
Au total, et en utilisant
habilement les balises <INCLURE()>, toutes les manipulations sur les dates sont
maintenant permises. Tous les critères de date permettent désormais de comparer
des date_redac entre elles ou à la date
passée en URL (ajouter _redac à la fin)
Nous avons ajouté une
série de raccourcis clavier dans l’espace privé afin de faciliter la navigation
pour les systèmes non-graphiques. Toutes ces touches sont gérées par le
navigateur et le système d’exploitation : c’est-à-dire qu’il faut les
utiliser, si votre système le permet, en combinaison avec « Alt »,
« Ctrl » ou « Pomme »... A vous de tester.
Résumé des
raccourcis :
q Les touches 1, 2, ... 9,
0 déclenchent les différentes entrées des menus de navigation (les deux rangées
d’icônes en haut de l’écran). En raison du nombre limité de chiffres
disponibles, seules les premières icônes de la deuxième rangée sont accessibles
par ce biais ;)
q (NB : si vous êtes
sur un clavier azerty, n’oubliez pas d’utiliser en plus la touche shift, ou de
passer par le pavé numérique)
q La touche S saute
directement à la colonne « de droite », qui présente le contenu utile
de la page courante (utile avec les systèmes à synthèse vocale pour ne pas
énumérer tous les choix de navigation de la colonne de gauche et des menus
d’icônes)
q La touche R saute
directement à la case recherche (note : n’oubliez
pas que cette case est uniquement disponible en interface complète), ce qui
vous permet de chercher rapidement un contenu (tapez Ctrl R, puis le texte à
chercher, et appuyez sur la touche Entrée)
q Les touches A, B, C, etc.
permettent de sauter à chacun des « blocs d’affichage » présents sur
la page (un « bloc » est par exemple une liste d’articles, un
formulaire...). Le nombre de touches ainsi disponible dépend du nombre de
blocs.
q propre() est un peu plus
compatible avec les normes html modernes
q Une nouvelle variable $ligne_horizontale permet de personnaliser
le filet <hr>
q Attention les intertitres
changent par rapport à l’historique : pour retrouver l’ancien style, il
faut personnaliser $debut_intertitre et $fin_intertitre
q Nouveau filtre « |sinon » : [(#TEXTE|sinon{"pas de texte"})] affiche le texte ; si celui-ci est vide,
affiche « pas de texte ».
q Nouveaux tags #LOGO_AUTEUR_NORMAL et #LOGO_AUTEUR_SURVOL
q Dans le menu
« ajouter un document depuis le répertoire upload », les noms de fichiers s’affichent par ordre
alphabétique ; de plus, les sous-répertoires éventuellement installés dans
upload/ sont pris en compte.
q le fichier engines-list.ini est déplacé dans ecrire/ et renommé en engines-list.txt : si vous l’avez modifié,
attention à reporter vos corrections dans le nouveau fichier : l’ancien
sera supprimé.
q le fichier inc_meta_cache.php3 passe dans ecrire/data/ (permet éventuellement
d’assurer un fonctionnement normal de SPIP tout en verrouillant le répertoire ecrire/)
q Le critère {branche} est officiellement
supporté
q Ajout de nouveaux types
de documents autorisés
q Changement de stratégie
sur les ?var_recherche=toto : ils ne sont plus ajoutés dans les URLs
qu’au sein des boucles {recherche} (et pas dans toute la page), et il n’est plus nécessaire
de les définir dans les inc-urls... (si vous avez un inc-urls... personnalisé [autre que
’standard’ ou ’html’], il est conseillé de le réviser en supprimant la partie
qui s’occupe de var_recherche).
q Bug : on peut
désormais utiliser #POINTS pour les sites référencés
q Bug : suppression
des forums attachés quand un site référencé est supprimé
q Bug : ne pas
accepter les changements de nom/email dans les forums sur abonnement
q Bug : vignettes non
supprimées à la suppression d’un document
q Bug : les pétitions
avec email unique ne fonctionnaient pas
q Patch
hébergement-discount
[SPIP 1.7.2] introduit de
nouveaux critères et balises, et des corrections de bugs, notamment :
Le chinois vient
compléter la liste des langues disponibles : arabe, bulgare, créole
réyoné, danois, allemand, anglais, espéranto, espagnol, farsi, français,
galicien, italien, néerlandais, occitan (7 versions), polonais, portugais,
vietnamien... et chinois !
q Plutôt que GD, on peut
utiliser ImageMagick, si cette librairie est présente sur le serveur sous la
forme du module php « imagick », ou de la ligne de commande
« convert ». (NB : si vous utilisez fink (Mac OS X),
il faudra préciser le chemin d’accès /sw/bin/convert dans le fichier inc_version.php3). ImageMagick donne
généralement de meilleurs résultats graphiques.
q Que vous utilisiez la
librairie GD ou ImageMagick, les vignettes sont désormais recréées en cas de
besoin (on peut donc les effacer si on change de méthode de création, ou de
taille, de vignette).
q Attention : Il faut vous rendre dans
la configuration avancée du site pour sélectionner votre méthode préférée de
fabrication de vignettes. Si plusieurs méthodes sont disponibles, cliquez sur
l’image ayant le meilleur rendu ; si « imagick » est présent,
préférez-le à « convert » : la méthode d’appel est plus
« propre ».
Les critères optionnels
permettent d’avoir des boucles à plusieurs usages : il suffit désormais
d’ajouter un point d’interrogation à un critère pour que celui-ci ne soit pris
en compte que s’il est passé dans le contexte. Cela permet par exemple de
simplifier énormément les boucles de backend-dist.html tout en gardant la
possibilité de préciser qu’on veut le backend « restreint aux articles en
créole » (backend.php3?lang=cpf) ou « de la
rubrique 7 et de ses sous-rubriques » (backend.php3?id_rubrique=7).
La boucle elle-même est
alors :
<BOUCLE_backend(ARTICLES){lang?}{branche?}{par date}{inverse}{0,10}> |
q le critère {lang_select} sert à forcer la
sélection de la langue pour la boucle (AUTEURS), qui normalement ne le fait pas (à l’inverse, le critère {lang_select=non} permet de dire aux
boucles (ARTICLES), (RUBRIQUES) ou (BREVES) de ne pas sélectionner la langue).
q la variable de
personnalisation $forcer_lang indique à SPIP qu’il
doit vérifier si le visiteur dispose d’un cookie de langue, et si oui le
renvoyer vers la page correspondante. C’est ce que fait la page de connexion à
l’espace privé livrée en standard avec SPIP.
q les balises #MENU_LANG (et #MENU_LANG_ECRIRE) affichent un menu de
langue qui permet au visiteur de choisir « cette page en... ». La
première balise affiche la liste des langues du site ; la seconde la liste
des langues de l’espace privé (elle est utilisée sur la page de connexion à
l’espace privé).
q enfin, les critères
optionnels permettent d’utiliser une même boucle (en fait, un même squelette)
pour afficher soit tous les articles du site dans toutes les langues, soit
seulement les articles dans la langue passée dans l’URL. Ca peut être utile,
par exemple, dans les boucles de recherche :
<BOUCLE_recherche(ARTICLES){lang?}{recherche}{par points}{inverse}{0,10}> |
q SPIP 1.7.1 avait
introduit un bug avec la puce, qui ne respectait plus le saut de paragraphe qui
la précédait.
q dans l’affichage des
statistiques, on a désormais une « prévision » du résultat à la fin
de la journée, basée sur la moyenne (pour les visites du site) et sur la
popularité de l’article (pour les visites d’un article). Ca vaut ce que ça
vaut...
***
SPIP 1.7.1 apportait pour
sa part les nouveautés suivantes :
Indexation des pétitions
et des forums. A noter, les forums sont indexés par thread, et non pas message
par message.
q Amélioration du tri {par
points} : les articles
contenant les mots précis demandés ont beaucoup plus de points (que ceux qui ne
contiennent que des mots commençant par les mots de la requête) ; de même,
si une requête porte sur plusieurs mots, les articles comportant tous ces mots
sortiront désormais en tête de liste. Le moteur de recherche offre donc des
résultats beaucoup plus pertinents.
q Amélioration du moteur
pour les articles en allemand et en vietnamien :
·
en allemand on
peut taper « über », « ueber » ou « uber » pour
trouver le premier de ces trois mots (« über ») ;
« ueber » en est la translittération « complexe », et
« uber » la translittération simple.
·
en vietnamien,
ce sont les accents qui sont très riches : ainsi pour retrouver le mot
« Ngi » avec tous ses accents, on peut le taper aussi bien
o
avec les bons
accents
o
sous la forme
« nguoi » (sans accents)
o
« ngu7 »,
les accents étant transcodés, en interne, avec des chiffres
o
Note
technique : pour permettre des recherches aussi sous la forme
« ngu+ » (c’est-à-dire directement dans la translittération
habituelle du vietnamien sur Internet), il faut faire un pré-traitement de la
variable $_GET['recherche'] pour y remplacer les '`?~.^+(- par le transcodage 123456789 ; évidemment SPIP ne peut fournir ce
pré-traitement en standard, car il ne concerne que les recherches en langue
vietnamienne).
q Le surlignement des
résultats de recherche est compatible
utf-8
q Le critère {tout} dans une boucle (RUBRIQUES) affiche aussi les
rubriques vides
q la balise #EXPOSER pour mettre en valeur le chemin d’accès à un
article dans les listes de rubriques ou d’articles. (Voir la documentation).
q Un nouveau filtre pour
les fichiers « backend » :
|texte_backend
q Suppression systématique
des numéro-titres dans les réponses des forums
q Il est désormais possible
d’appeler un squelette avec un paramètre lang=...
De même <INCLURE(...){lang}> ou <INCLURE(...){lang=xx}> fonctionnent enfin et
sont capables d’aller éventuellement chercher un squelette affiné par langue (fichier article.xx.html).
q Ajout des id_auteur dans les boucles (FORUMS)
q possibilité d’utiliser un
critère {url==...} dans les boucles (SYNDIC_ARTICLES)
q Balise #URL_AUTEUR.
q Le filtre |couper{} est plus smart,
notamment pour des longueurs très courtes ([(#TITRE|couper{5})] donnera bien 5
caractères).
q Le filtre |reduire_image permet de réduire des
images à la volée, soit en utilisant la librarie gd (ou gd2) si elle est
présente, soit en précisant width=... height=.... dans le code HTML
produit.
q Ajout d’une balise <poesie>...</poesie> qui permet d’entrer des vers ou des paroles
de chanson avec des sauts de lignes adaptés.
q Meilleure gestion typographique (en français) des exclamations multiples (Whoah !??!!).
en interface
complète la page ecrire/articles.php3?id_article=x permet une « révision
des insécables » en les affichant en grisé (le réglage est à faire dans le
fichier ecrire/mes_options.php3).
q retour des boutons de
messagerie dans la liste des auteurs
q Création de points
d’entrée dans typo() et propre() pour des patches particuliers
q ajout de l’option $cookie_path (pour bidouiller spip
avec des scripts externes comme Spikini).
***
SPIP 1.7 (3 janvier 2004)
complétait l’internationalisation de SPIP en apportant la possibilité, souvent
demandée, de construire des sites multilingues. Le site officiel, désormais
hébergé sur http://www.spip.net, est lui-même
multilingue (les volontaires pour continuer les traductions sont d’ailleurs les
bienvenus : rendez-vous à http://www.spip.net/rubrique4.html).
Il est conseillé de
sauvegarder la base de données avant de mettre à jour SPIP. Pour cela,
allez dans la partie « Administration du site » de l’espace privé,
puis « Maintenance du site » et cliquez sur « Sauvegarde de la
base de données ». Une fois la sauvegarde effectuée (vous devrez pour cela
créer un fichier au nom particulier dans le répertoire ecrire/data), vous
pourrez récupérer le fichier résultant (dump.xml ou dump.xml.gz).
Après cette sauvegarde,
vous pourrez mettre SPIP à jour comme expliqué
plus bas.
Si vous avez un problème et qu’il faut restaurer la sauvegarde effectuée ci-dessus : réinstallez d’abord la version de SPIP avec laquelle vous avez effectuée la sauvegarde (TRÈS IMPORTANT) ! Ne cherchez surtout pas à restaurer sous la version 1.7 une sauvegarde que vous aurez effectuée avec la version 1.6 (par exemple) ! Une fois la bonne version de SPIP réinstallée, vous pourrez restaurer la sauvegarde que vous aviez faite précédemment.
N’oubliez pas non plus
que pour une sauvegarde complète, il faut également recopier le contenu du
répertoire IMG/ en lieu sûr. Ce répertoire contient en effet les logos, images,
documents que vous aurez uploadés depuis l’interface de rédaction.
Important : cette
sauvegarde est une simple précaution. Ne cherchez pas à la restaurer si tout
fonctionne correctement. N’effacez pas non plus la base de données avant de
faire la mise à jour, c’est inutile et dangereux !
La procédure de mise à
jour est la même que
d’habitude. Vous avez deux possibilités :
q Utiliser l’installateur
automatique, spip_loader.php3 : ce fichier que vous trouverez à l’adresse http://www.spip.net/spip-dev/INSTALL,
remplacera automatiquement votre version courante de SPIP par la version 1.7.
Note : si l’installation automatique n’est pas compatible avec votre système, spip_loader.php3 vous en avertira et vous devrez alors utiliser l’installation manuelle décrite ci-dessous.
q Télécharger manuellement
SPIP 1.7 sur votre site. Pour cela, vous devrez :
1.
Choisir une des archives du répertoire http://www.spip.net/spip-dev/DISTRIB ;
vous avez le choix entre la version complète, qui contient toutes les langues,
et les versions monolingues qui contiennent chacune une seule langue mais sont
plus légères à télécharger.
2.
Télécharger cette archive sur votre ordinateur personnel, et la
décompacter en utilisant l’utilitaire approprie (par exemple Winzip sous
Windows).
3.
Envoyer les fichiers ainsi décompactés sur votre site Web, par FTP.
Les fichiers doivent bien sûr être envoyés au même endroit que la version
précédente de SPIP.
Une fois la nouvelle
version installée, vous devrez permettre au système de mettre à jour la base de
données. Pour cela il vous sera demandé de créer un fichier d’un nom
particulier dans le répertoire ecrire/data. Cette sécurité permet d’assurer que la personne
qui effectue la mise à jour est bien autorisée à le faire.
Note : si un problème vous empêche par
la suite d’accéder à l’espace privé de votre site, vous pouvez recréer un accès
en effaçant simplement du répertoire ecrire le fichier inc_connect.php3, ce qui
relancera le formulaire d’installation du site.
Une fois SPIP mis à jour, vous pouvez profiter des nouveautés qu’offre la version
1.7. Celles-ci sont détaillées ci-après.
Bonne chance et publiez
bien
L’équipe de SPIP.
La version 1.6
enrichissait enfin SPIP d’un lot de traductions permettant d’utiliser l’espace
privé dans différentes langues, et élargissant ainsi l’usage de SPIP à des
rédacteurs de diverses langues. La version 1.7 complète désormais cet ajout en
permettant également au site public d’être multilingue sans aucun effort de
mise en place (à part quelques options de configuration à modifier). Cette
fonctionnalité majeure (qui recouvre divers aspects comme l’affichage des dates
et formulaires, la sélection de la typographie, la gestion des traductions
d’articles) fait l’objet d’articles de documentation séparés.
Le multilinguisme inclut
l’apparition de plusieurs outils dédiés, dont :
q Des options de
configuration spécifiques
q Un système de gestion des
traductions entre articles
q Une page de gestion des
traductions par langue
q Un paquet de chaînes
pré-traduites en diverses langues pour l’espace public
La palette des langues
disponibles s’est enrichie, puisque, à ce jour, l’interface de rédaction de SPIP est traduite dans les
langues suivantes :
q français
q Anglais
q Néerlandais
q Vietnamien
q Espagnol
q Arabe
q Farsi
q créole de la Réunion
q allemand
q danois
q espéranto
q italien
q bulgare
q polonais
q catalan
q portugais
q sept variantes
différentes d’occitan : niçard, languedocien, gascon, provençal,
auvergnat, limousin et vivaro-alpin !
Votre site public
bénéficie également de ces traductions grâce à un système de textes
pré-traduits livrés avec SPIP. Vous pouvez voir ce système en action dans les
squelettes par défaut de SPIP 1.7 : changez la langue du site ou d’un
article, recalculez la page publique correspondante, et les textes communs
(navigation, dates, formulaires...) s’affichent dans la langue choisie !
La documentation
elle-même commence à être traduite en diverses langues sur notre nouveau site
officiel (http://www.spip.net). Tout cela
représente un travail très important, et il y a largement de la place pour de
nouveaux participants (rendez-vous dans l’« espace des
traducteurs »).
Une barre graphique de
raccourcis fait son apparition au-dessus des champs d’édition les plus
importants (texte des articles, brèves, forums). Elle permet aux débutants de
se familiariser avec les principaux raccourcis typographiques en utilisant dans
un premier temps les boutons de la barre plutôt que leur équivalent au clavier.
Dans l’écran de login, on
peut choisir de rester identifié quelques jours, ce qui évite de retaper trop
souvent son mot de passe.
Refonte du calendrier
personnel (agenda)
Calendrier mensuel
L’interface du calendrier
différencie davantage les éléments éditoriaux (publication d’articles et de
brèves) et les rendez-vous (annonces à tous les participants et messages
personnels).
Affichage d’une journée
La colonne principale affiche l’intégralité des rendez-vous. Le code
couleur permet de repérer les pense-bêtes (bleu), les rendez-vous avec d’autres
participants (verts) et les rendez-vous qui concernent tout le monde (jaune).
Dans la colonne de gauche, un bouton permet de revenir à aujourd’hui,
et des calendriers réduits facilitent la navigation d’un jour à l’autre.
Dans la colonne de droite (non montrée dans cette copie d’écran), on
trouve l’affichage graphique de la journée suivante.
q Une page de suivi à
distance de la vie du site permet de récupérer l’adresse de syndication (RSS) et
d’injecter les événements du site dans un calendrier (format iCal).
q Nouveau système de
navigation dans l’ensemble du site.
Le nouveau système de navigation
Ajout de la balise #DATE pour la boucle
DOCUMENTS.
q On peut désormais
configurer une adresse mail expéditrice des mails du site (si elle est laissée
vide, l’adresse apparente de l’émetteur est identique à celle du destinataire,
comme précédemment).
q Lors d’une mise à jour de la base, SPIP
teste d’abord si les droits d’accès à la base de données sont suffisants, et
affiche un message d’erreur sinon.
q L’affichage des referers
a été totalement revu.
q Deux variables de
configuration supplémentaires pour mes_options.php3 : on peut décider que SPIP va ignorer les
connexions par REMOTE_USER (.htaccess) et/ou par authentification http.
q Les mots de passe peuvent
désormais contenir des accents (avec un jeu de caractères 8 bits de type
iso-8859-1, pas utf-8...)
q Quand on poste un message
dans un forum public, le nom et l’email utilisés sont mémorisés et pré-remplis
automatiquement si l’on poste d’autres messages durant la même session. Cela
évite d’avoir à retaper systématiquement son nom quand on participe beaucoup
aux forums.
q Les pages correspondant à
un article non publié ne sont plus mises en cache
q Message d’erreur au lieu
d’une page blanche lorsque le serveur ne peut pas calculer la page et qu’elle
n’est pas dans le cache (MySQL indisponible, sur le moteur de recherche, par exemple).
q Distinction plus précise
des erreurs MySQL dans les squelettes.
q Correction d’un léger bug
sur les forums publics : dans certains cas, la page n’était pas
automatiquement recalculée lors de l’ajout d’un commentaire.
q Correction du bug des doublons avec la boucle
hiérarchie.
q Pour les
bidouilleurs : possibilité de redéfinir la balise #INTRODUCTION, en plaçant dans mes_fonctions.php3 une nouvelle fonction
introduction(...). On peut se baser, pour démarrer, sur la fonction calcul_introduction qui se trouve dans inc-calcul.php3
q Ajout d’un champ nom_site
et url_site aux articles (à activer, sous le nom de « lien
hypertexte », dans la configuration du site). Les balises #NOM_SITE et #URL_SITE permettent d’afficher
ces valeurs.
q Support des jeux de
caractères arabes (windows-1256 et iso-8859-6)
q La configuration de l’URL
du glossaire externe (pour les raccourcis de type « [?terme
à rechercher] ») accepte maintenant une écriture plus souple (sous la forme
"url_glossaire_avec_des_%s", où %s sera
remplacé par le "terme à rechercher").
q Compatibilité MySQL 4.1.0
q Introduction d’un
mécanisme de gestion de la charge (plutôt destiné aux hébergeurs) :
lorsque SPIP détecte la présence, dans ecrire/data/, d’un fichier nommé lock, et si ce fichier n’est
pas trop vieux (moins de 10 minutes), il évite de faire des calculs pas absolument
nécessaires : indexation, statistiques, etc.
q Nouveau raccourci
typographique « <quote> ... </quote> », pour citer un
morceau de texte (utile dans les forums publics).
q et diverses corrections
et améliorations.
Vendredi 1er avril 2005 : [SPIP 1.8] est téléchargeable à l’adresse www.spip.net/spip-dev/DISTRIB/.
Cette nouvelle version de SPIP constitue
l’aboutissement de plus d’une année de travail (la version 1.7 date en effet de
janvier 2004), et il est impossible d’en lister ici toutes les nouveautés
de façon exhaustive.
Les plus grands efforts ont été faits, malgré des
transformations importantes (visibles et invisibles) de tous les composants du
programme, pour que la mise à jour d’un site
sous n’importe quelle version ancienne de SPIP se déroule sans (trop de)
difficultés.
En cas de problème de mise à jour, n’hésitez pas toutefois à demander de l’aide sur
la liste spip@rezo.net,
ou à consulter le nouveau site de forums de la communauté SPIP, à l’adresse http://forum.spip.org/.
La transformation la plus spectaculaire est
certainement celle de l’espace privé. Ce dernier a bénéficié d’une refonte
graphique et ergonomique complète, permettant de publier plus vite et de naviguer
plus aisément.
Un article
de la documentation détaille les évolutions ergonomiques introduites dans
cette version de SPIP.
Plusieurs outils d’aide à la publication ont fait
leur apparition :
Le correcteur orthographique
Une fois un article écrit, on peut corriger les
fautes d’orthographe grâce à un serveur externe de correction.
Une note à ce propos : le correcteur
d’orthographe n’étant pas installé « en local », les mots à vérifier
sont envoyés (dans le désordre) à des « serveurs d’orthographe »
développés par le SPIP Lab’ et mis à
votre disposition par divers membres de la communauté des utilisateurs de SPIP.
Afin d’éviter d’ouvrir une brèche de « confidentialité », il est
demandé aux webmestres qui le désirent d’activer expressément cette
fonctionnalité sur leur site.
La prévisualisation
Une fois un article proposé à la publication,
chacun (administrateur ou rédacteur, selon le réglage du site) peut le
prévisualiser avec le squelette du site. Ainsi, on peut vérifier le bon
affichage final de l’article sans devoir le « publier » puis le
« dépublier ».
L’historique des modifications
Pour faciliter le suivi éditorial et l’écriture
collaborative, [SPIP 1.8] introduit
l’historique des modifications (également développé par SPIP-Lab). On peut
ainsi obtenir une liste des derniers articles édités, et voir les modifications
faites entre différentes versions d’un article.
Le portfolio
[SPIP 1.8] introduit une nouvelle mise en page pour les
documents associés à un article. Tous les documents associés à un article — qui
ne se trouvent pas déjà dans le texte — sont affichés dans un portfolio en
dessous de l’article.
Depuis ce portfolio, on peut facilement éditer les
titre et description d’un document. On peut aussi — si les bonnes librairies
graphiques sont installées et configurées sur le serveur — faire tourner les
images de 90 ou 180 degrés.
Ce portfolio est complété par la possibilité
d’associer plusieurs documents à un article, en une seule fois. On peut :
Un
article de la documentation précise l’utilisation des outils de traitement
d’images.
Emplacement des fichiers squelettes
Les squelettes par défaut (anciennement nommés
« article-dist.html ») livrés avec [SPIP 1.8] ne sont plus la racine du site,
mais dans un sous-répertoire dist/ ; ceci en accord avec un début de
réorganisation des fichiers de SPIP, qui permet de placer les squelettes
personnalisés dans le répertoire squelettes/, et plus seulement à la racine du site (le réglage
éventuel de la variable $dossier_squelettes est toujours accepté).
Nouveau compilateur de squelettes
Innovation moins spectaculaire, mais sans aucun
doute aussi importante que tout ce qui précède, [SPIP 1.8]
introduit un « compilateur de squelettes ». Initialement présenté sur
le site SPIP Contrib’, ce
compilateur a permis, après des mois de travail
acharné, d’obtenir une réécriture complète du système qui permet à SPIP
d’interpréter le langage de boucles, de balises, de filtres et de critères.
Les avantages directs de cette réécriture ne sont
pas forcément évidents au premier abord. L’important (outre le dépassement de
certaines contraintes de programmation qui commençaient à peser lourd, et
l’amélioration générale du code) est qu’elle permet d’introduire relativement
facilement de nouvelles <BOUCLES()>, de nouveaux {critères} et de nouvelles #BALISES par simple ajout de fonctions dans le fichier mes_fonctions.php3
— à l’instar des |filtres des versions précédentes de SPIP.
Un bon exemple est la contrib Portrait ou Paysage ?
publiée sur SPIP Contrib’, qui
offre trois nouveaux critères de tris des images : {portrait}, {paysage} et {carre}.
Ce nouveau modèle devrait ouvrir le développement
de SPIP à une frénésie de contributions, déjà bourgeonnante. Si vous ajoutez de
votre côté de nouvelles fonctionnalités à SPIP, n’hésitez pas à en faire
profiter toute la communauté !
Au passage, notons que l’on peut désormais :
intégrer
une boucle dans le code optionnel avant d’une autre boucle (entre <B_articles> et <BOUCLE_articles(ARTICLES){critères...}>).
Les
balises peuvent être « imbriquées » les unes dans les autres, par
exemple : [ [(#SURTITRE)]
(#LOGO_ARTICLE)]
De
même, on peut mettre des <INCLURE()> dans les parties optionnelles d’une balise :
[<INCLURE(debut.php3)>(#SURTITRE) ]
On
peut accéder sans programmation supplémentaire, dans les squelettes, à
n’importe quel champ d’une table à travers la balise #NOM_DU_CHAMP
la
syntaxe #_nom:TEXTE permet
d’accéder à la balise #TEXTE
de la boucle englobante nommée _nom. On peut ainsi accéder à des balises de boucles
englobantes dont le nom serait ambigu dans le contexte de la boucle actuelle
(typiquement, #TITRE et #_rubrique:TITRE).
On
peut utiliser une balise dans l’évaluation d’un critère : {titre
= #TITRE}
En
définissant de nouvelles boucles, on peut accéder à des tables situées dans
d’autres bases de données.
Un débogueur accompagne ce compilateur :
d’une
part, le webmestre voit s’afficher des messages d’erreur en cas de problème de
construction de ses squelettes ;
d’autre
part, en remplaçant dans l’URl de recalcul de la page le code var_mode=recalcul par var_mode=debug, le webmestre accède à un mode de visualisation
qui expose précisément le code PHP et MySQL produit par le compilateur à partir
des squelettes. Un outil certes difficile de prime abord, mais précieux pour
celles et ceux qui souhaitent comprendre en détail le fonctionnement de telle
ou telle balise — et notamment quand il s’agit d’en construire de nouvelles.
[SPIP 1.8] bénéficie aussi de l’important travail de sa
toujours croissante communauté de traducteurs. Il est désormais disponible dans
les 33 langues suivantes, avec souvent une documentation complète (les
nouvelles venues sont signalées en gras) :
code |
langue |
trad. |
العربية
|
arabe |
|
български |
bulgare |
|
català |
catalan |
|
Kréol réyoné |
créole réunionnais |
|
Kreyòl ayisyen
|
haïtien |
|
dansk |
danois |
|
Deutsch |
allemand |
|
English |
anglais |
|
Esperanto |
esperanto |
|
Español |
espagnol |
|
فارسى |
farsi |
|
fongbè |
fongbé |
|
français |
français |
|
galego |
galicien |
|
magyar |
hongrois |
|
italiano |
italien |
|
日本語
|
japonais |
|
Lëtzebuergesch |
luxembourgeois |
|
Nederlands |
néérlandais |
|
polski |
polonais |
|
Português |
portugais |
|
Português do Brasil
|
brésilien |
|
română |
roumain |
|
Türkçe |
turc [SPIP 1.8.1] |
|
Tiếng Việt |
vietnamien |
|
中文
|
chinois |
et toujours les 7 variétés d’occitan : òc auvernhat, òc gascon, òc
lemosin, òc lengadocian, òc niçard (en deux parfums), òc provençau, òc
vivaroaupenc !
Les traducteurs et apprentis-traducteurs sont les
bienvenus, pour toutes les langues de la Terre. Il y a de la place pour tout le
monde. Faites circuler l’information et n’hésitez pas à « embaucher »
vos amis ! La page de référence des traductions est toujours www.spip.net/rubrique4.html ;
contact par email, sur la liste spip-trad@rezo.net
De nouveaux raccourcis
Quelques nouveaux raccourcis font leur
apparition :
on
peut maintenant insérer du
code LaTEX dans un article grâce à la balise <math>. Ce code sera traité par un serveur externe pour
le transformer en une image qui sera intégrée au texte.
Par exemple, le texte suivant : <math>la
valeur de $x$ est $\sqrt{\frac{y^{2}}{z^{2}}}$</math>
s’affichera sous la forme :
la valeur de est
le
raccourci -- sera
remplacé par un semi-quadratin —.
Nouvelles balises, critères et filtres
Quelques nouveaux filtres, critères et balises sont
listés dans la documentation, accompagnés de la mention [SPIP 1.8].
Signalons par exemple, pour les amateurs de
présentation à la façon « blog », le filtre |unique qui assure qu’un élément récurrent (une date par
exemple) n’est affiché qu’une fois ; ou encore le critère {id_article IN 1,2,3} qui affiche les articles 1,2 puis 3 dans cet
ordre.
PHP 4.0.8, PHP 5. La version minimale supportée est désormais la 4.0.8
avec la librairie preg installée. [SPIP
1.8] est compatible avec PHP 5. La compatibilité avec PHP 3
est en revanche abandonnée.
Note : Pour des raisons « historiques », les fichiers de la distribution
officielle continuent à se nommer xxx.php3 ; ce schéma de nommage
disparaîtra dans la prochaine version de SPIP, au profit des xxx.php.
Une version php de [SPIP 1.8] est
toutefois disponible au téléchargement.
MySQL 3, 4.1.x Aucun problème de compatibilité n’a été relevé
avec MySQL jusqu’aux versions 4.1.x. Si toutefois vous rencontrez un problème
avec MySQL 4.1, merci de le signaler sur la liste de développement, spip-dev@rezo.net
Librairies graphiques. [SPIP 1.8]
supporte la génération de vignettes avec NetPBM qui est facilement installable
par ftp (voir http://gallery.menalto.com/modules....
chez les hebergeurs où il n’est pas déjà présent), mais aussi GD1, GD2, et
Imagick (en module php, ou en ligne de commande sous le nom
« convert »).
« W3C. » Le moteur de raccourcis fait son possible pour
être conforme aux recommandations du W3C en matière de codage du HTML.
Toutefois cela n’est pas parfait dans toutes les situations, notamment lorsque
les utilisateurs entrent des textes comportant des balises complexes ou du code
HTML.
Note : Pour parfaire les résultats [SPIP 1.8.1]
introduit un mode « tidy », qui permet d’assurer que toutes les pages du
site sont « valides XHTML1.0 » ; ce mode fonctionne déjà sur
www.spip.net, même s’il n’est pas totalement stabilisé. Pour plus
d’informations voir Tidy :
validation XHTML 1.0.
Sans oublier :
* * *
Introduite le 15 avril 2005, [SPIP 1.8.1]
règle les quelques soucis d’installation qui se sont fait jour après la
sortie de la version 1.8. Elle apporte en plus :
le
mode « tidy » (voir ci-dessus) ;
un
nouveau fichier htaccess.txt pour la gestion des URLs personnalisées (voir Utiliser des URLs personnalisées) ;
une
révision de l’aide en ligne ;
une
mise à jour du module
LDAP
Dernier point à noter, la balise #PARAMETRES_FORUM a été
revue. Il n’est en effet plus besoin désormais de passer l’adresse de retour
dans les paramètres de forum, car, par défaut, SPIP redirige désormais le
visiteur qui vient de poster un message vers l’adresse #URL_FORUM de ce
message. Si le résultat ne vous convient pas, vous pouvez récupérer l’ancien
fonctionnement en passant l’adresse de retour en argument de la balise, sous la
forme [(#PARAMETRES_FORUM{#SELF})]
Au passage, ce nouvel argument « page de
retour » qu’on peut désormais passer à la balise permet de faire des
redirections vers une page de votre choix, par exemple
[(#PARAMETRES_FORUM{message_recu.php?id_article=#ID_ARTICLE})]
si vous souhaitez afficher un texte particulier après l’envoi du message. (Ce
qui peut être pertinent pour des forums modérés a priori.)
Amusez-vous bien !
Comme d’habitude le téléchargement de SPIP se fait
depuis www.spip.net/spip-dev/DISTRIB/.
La mise à jour s’effectue
de la manière classique, voir Effectuer
une mise à jour. Les sites installés à l’aide de spip_loader peuvent être
mis à jour automatiquement.
Lorsque vous installez, par FTP, les fichiers de
SPIP sur votre propre serveur, certains répertoires ne sont
pas configurés correctement : vous devez donc intervenir sur ces
répertoires, avec votre logiciel de FTP habituel, pour modifier leur
configuration.
Il s’agit pour vous de « fixer les droits
d’accès » des répertoires suivants :
q /CACHE
q /IMG
q
/ecrire/
q
ecrire/data
Les logiciels (« clients ») FTP ont des
fonctionnement différents, mais la procédure est généralement la
suivante :
q sélectionnez le dossier dont vous voulez modifier
les « droits d’accès » ;
q trouvez dans votre logiciel de FTP une fonction
intitulée « changer (ou modifier, ou fixer) les droits
d’accès » ;
q si cette fonction se présente sous la forme d’une
interface graphique, vous devez cocher la case correspondant à
« Ecriture », pour l’utilisateur « Autres » (ou « Tous
utilisateurs ») :
q si cette modification se fait en mode « texte », la configuration numérique est
« 777 ».
Lors vous avez effectué cette opération pour chaque
répertoire signalé par le système d’installation, rechargez la page, la procédure
se poursuit automatiquement.
q Cette étape consiste à indiquer les informations
nécessaires à la connexion de SPIP au serveur MySQL.
q Adresse de la base de données : en fonction des choix de votre hébergeur, cette
information sera simplement « localhost », ou bien l’adresse de votre
site (« www.monsite.org »).
q Le login de connexion : souvent, il s’agit du même login que celui utilisé
pour le téléchargement de vos fichiers par FTP.
q Le mot de passe de connexion : souvent, il s’agit du même mot de passe que celui
de votre accès FTP au site.
q Ces informations ne s’inventent pas : si vous
ne les connaissez pas, c’est que votre hébergeur ne vous les a pas fournies.
Donc : si n’avez pas sous la main ces trois informations, vous ne pouvez
pas continuer.
q Ces informations vous sont fournies par
l’hébergeur de votre site : pour les obtenir, vous devez le
contacter directement (ne demandez pas à l’équipe de développement de SPIP de
vous les fournir, nous ne les connaissons pas !). Chez certains
hébergeurs, ces informations vous sont fournies dans un mode d’emploi en
ligne.
q Notez encore que, très souvent, il faut demander
à votre hébergeur d’activer votre accès MySQL, ou effectuer vous-même une
opération spécifique dans ce but. Beaucoup d’hébergeurs annonçant un
hébergement doté d’une base de données MySQL n’activent pas automatiquement
cette connexion lors de l’ouverture du site ; une démarche supplémentaire
de votre part (après l’ouverture de votre compte chez cet hébergeur) est
souvent nécessaire. Dans ce cas, voyez la documentation de votre hébergeur pour
savoir comment activer votre connexion MySQL. (Là encore : l’équipe
de SPIP ne peut pas vous aider.)
q Vous devez indiquer le nom de la base de
données que vous a attribué votre hébergeur. Cette information vous est fournie
par votre hébergeur : si vous ne l’avez pas, demandez-la lui, ou bien
consultez la documentation en ligne de cet hébergeur (inutile de la demander à
l’équipe de développement de SPIP, nous ne connaissons pas cette information).
q Très souvent, cette information correspond au login
de votre compte d’hébergement (celui que vous utilisez pour vous connecter à
votre site par FTP).
q Première possibilité (le plus souvent) : une
liste de comptes est affichée (parfois un peu longue, selon la configuration
fixée par votre hébergeur). Parmi les comptes indiqués, un seul correspond au
vôtre, il vous suffit donc de le sélectionner et de valider pour passer à
l’étape suivante.
q Deuxième possibilité : un seul nom,
correspondant à votre compte, s’affiche (automatiquement, votre hébergeur a
configuré son système pour que s’affiche uniquement votre propre compte).
Facile : sélectionnez ce compte et validez.
q Troisième possibilité (généralement sur un hébergement
pour professionnels, ou s’il s’agit d’une machine sur laquelle vous avez des
droits élevés) : vous devez créer votre propre base. Dans ce cas
(après avoir bien vérifié qu’un tel compte n’existait pas dans la liste
indiquée ci-dessus), vous pouvez indiquer le nom de votre choix à la suite de
l’indication « Créez une nouvelle base »
q Dernière possibilité (échec) : votre compte
n’apparaît pas dans la liste proposée, et vous ne pouvez pas en créer
vous-même. C’est assez rare : cela signifie que votre hébergeur a créé
pour vous un accès au serveur de la base, mais a oublié de vous créer un
compte. Dans ce cas, vous devez directement consulter votre hébergeur.
Cette étape est très simple, mais doit être
effectuée attentivement. En effet, c’est elle qui détermine vos identifiants de
connexion à votre propre site ! Si vous procédez trop vite, vous risquez
de ne pas pouvoir vous connecter...
Notez qu’une fois votre site installé, vous aurez
la possibilité de modifier ces informations.
q Votre identité publique : c’est ce qui apparaîtra en tant que signature de
vos articles.
q Vos identifiants de connexion : il s’agit ici des identifiants que vous
choisissez vous-même pour vous connecter à votre propre système SPIP.
Ces informations n’ont aucunement besoin d’être identiques à celles que votre
hébergeur vous a indiquées pour vous connecter à votre compte par FTP. Au
contraire, nous vous recommandons très fortement de ne pas utiliser les
mêmes identifiants pour votre accès SPIP (que vous choisissez librement) et
pour votre connexion FTP (imposées par votre hébergeur).
Certaines fonctionnalités de SPIP influent
directement sur la structure et le contenu mêmes de la base de données
(notamment : mise-à-jour, sauvegarde et restauration de la base...). Pour
ces fonctionnalités, particulièrement sensibles, il a été ajouté une procédure
d’identification par FTP, de façon à les réserver aux quelques personnes ayant
accès au serveur du site par FTP (généralement, si un site peut comporter
plusieurs administrateurs pour SPIP, l’accès FTP est réservé à un webmestre
principal).
Pour utiliser ces fonctionnalités, vous devez
simultanément :
q vous connecter par le Web avec votre butineur habituel ; lorsque vous lancez l’action, SPIP vous indique un nom du type « admin_xxxxx », qu’il vous faut recopier ;
q vous connecter au serveur de votre site par FTP ; là, dans le dossier /ecrire/data, créez un fichier (ou un répertoire vide) portant le nom « admin_xxxxx » ;
q une fois ce fichier ou ce dossier créé, retournez à votre butineur Web, et rechargez la page. Dès lors, l’authentification par FTP est réalisée, et l’action désirée est déclenchée.
Lorsque SPIP se trouve confronté à une erreur dans
sa communication avec la base de données MySQL, il affiche à l’écran la requête
qui a échoué, ainsi que le message d’erreur renvoyé par la base de données (en
rouge).
Le problème peut provenir :
q soit d’une erreur dans la définition de votre
squelette, si vous êtes en train de modifier votre site ;
q soit d’une panne de la base de données.
Par exemple, un message du type
> Unknown
column 'articles.chapi' in 'where clause' signale que la boucle fait appel à un critère de sélection (chapi) qui n’est pas prévu.
En revanche, un message du type
> Can't
open file: 'spip_articles.MYD'
signale un grave problème de la base MySQL elle-même : voyez alors avec
votre hébergeur pour qu’il révise son installation et/ou répare votre base de
données. Si vous disposez d’une version récente de MySQL (à partir de 3.23.14),
vous pouvez aussi tenter une
auto-réparation de la base.
Pour faciliter la mise en page des documents
publiés avec SPIP, le système propose un certain nombre de « raccourcis
SPIP » destinés :
q
à
simplifier l’utilisation par des utilisateurs ne connaissant pas le HTML ;
q
à
faciliter le traitement automatique de la mise en page.
Par conséquent naturellement vous pouvez toujours
utiliser le code HTML dans vos documents SPIP, mais nous vous conseillons
d’utiliser de préférence ces quelques raccourcis SPIP (peu nombreux), qui sont
beaucoup plus faciles à mémoriser et plus particulièrement permettent au
système certaines opérations automatisées.
Dans un premier temps, nous présentons ici les
raccourcis typographiques les plus courants et les plus simples. Pour les
utilisateurs qui souhaiteraient affiner encore le contrôle de la mise en forme
de leurs textes, nous présenterons des versions plus complexes de ces
raccourcis.
N.B.
Les raccourcis simples répondent déjà largement à la grande majorité des
besoins, et permettent de publier en ligne presque aussi simplement que l’on
écrit un mail.
q Typographie française automatique
SPIP respecte automatiquement les principales
règles d’espacement de la typographie française - ainsi des espaces insécables
sont ajoutées devant les caractères « :», « ; », « ! »,
« ? » -, et place des espaces insécables avant et après les
guillemets « à la française ».
(Note : cette fonctionnalité n’est activée que
sur les sites dont la langue principale est le français.)
q Créer des paragraphes
Pour créer des paragraphes, il suffit de laisser
une ligne vide, un peu comment on sépare les paragraphes dans un email (on
« saute » une ligne).
Le fait de simplement « revenir à la
ligne » (retour-chariot) sans séparer les deux paragraphes par une ligne
vide ne suffit pas pour provoquer un changement de paragraphe (cela ne provoque
même pas un retour à la ligne).
Vous pouvez laisser plusieurs lignes vides à la
suite sans que cela modifie la présentation.
q Fabriquer des listes ou des énumérations
On peut fabriquer des listes dans SPIP de la même
manière que dans un email : il suffit de revenir à la ligne et de
commencer la nouvelle ligne avec un tiret (« - »).
Notez : ici un simple retour à la ligne suffit
(on peut faire des énumérations dans le même paragraphe) ; mais si l’on
« saute » une ligne avant la ligne commençant par un tiret, une ligne
vide est affichée avant l’énumération
Par exemple,
- Qu'est-ce que cela peut faire que
je lutte pour la mauvaise cause puisque je suis de bonne foi? - Et qu'est-ce que ça peut faire que
je sois de mauvaise foi puisque c'est pour la bonne cause.
(Jacques Prévert) |
sera affiché ainsi :
Ø
Qu’est-ce que cela
peut faire que je lutte pour la mauvaise cause puisque je suis de bonne
foi ?
Ø
Et qu’est-ce que ça
peut faire que je sois de mauvaise foi puisque c’est pour la bonne cause.
(Jacques Prévert)
q Gras et italique
On indique simplement du texte en italique
en le plaçant entre des accolades simples : « ...du texte {en italique}
en... ».
On indique du texte en gras en le
plaçant entre des accolades doubles : « ...du texte {{en gras}}
en... ».
q Intertitres
Les intertitres sont des titres à l’intérieur d’un
texte permettant d’en indiquer la structure. Dans SPIP, on les indique très
simplement en les plaçant entre des accolades triples : « {{{Un titre de partie}}} » donnera : affichera le texte en gras
et centré :
Un titre
de partie
q
Trait de
séparation horizontal
Il est très simple d’insérer un trait de séparation
horizontal sur toute la largeur du texte : il suffit de placer une ligne
ne contenant qu’une succession d’au moins quatre tirets, ainsi :
---- |
Donne :
q Les liens hypertextes
On fabriquera facilement
un lien hypertexte avec le code suivant :
SPIP est une initiative du
[minirézo->http://www.minirezo.net/]. |
devient :
SPIP est une initiative du minirézo.
(Mnémotechnique : le tiret suivi d’un chevron dessine une sorte de flèche qui indique que le texte du lien (avant la flèche) « pointe vers » une adresse.)
L’adresse du lien peut être une adresse absolue
(commençant, comme ici, par http://),
une adresse relative (vers une autre page du même site), un lien vers un
document utilisant un protocole de l’internet (ftp://...), une adresse email (« [->minirezo@rezo.net] »)...
Application spécifique : vous pouvez afficher
en toutes lettres un lien cliquable sous la forme d’une adresse URL, en
n’indiquant rien avant la « flèche ». Par exemple :
[->http://dmoz.org/World/Deutsch/Kultur/Literatur/Autoren_und_Autorinnen/P/Proust,_Marcel/] |
affiche :
http://dmoz.org/World/Deutsch/Kultu...
Notez que, dans le cas des URL très longues,
l’affichage est tronqué (pour éviter de dégrader votre interface graphique),
mais le lien hypertexte pointe vers la bonne adresse.
q Liens hypertextes à l’intérieur du site
Ce même système de liens hypertextes facilite, de
plus, la création de liens à l’intérieur de votre site sous SPIP. La seule
subtilité consiste à repérer le numéro de l’article, de la rubrique, ou
de la brève vers laquelle vous voulez mener votre lien hypertexte : lorsque
vous « visitez », dans l’espace privé, un article, une brève ou une
rubrique, la colonne de gauche contient un pavé indiquant, en gros caractères,
ce numéro.
C’est ce numéro que vous allez indiquer dans le
lien hypertexte :
Application spécifique : on peut, là aussi, ne
rien spécifier avant la « flèche » ([->aut13]...). SPIP insérera automatiquement les
informations nécessaires. Dans le cas d’un document joint ou d’une image, si
l’on a indiqué un titre manuellement, c’est ce titre qui sera affiché ;
sinon c’est le nom du fichier lui-même qui sera utilisé.
q
Notes
de bas de page
Une note de bas de page est, habituellement,
signalée par un numéro placé à l’intérieur du texte, numéro repris en bas de
page et proposant un complément d’information.
Dans SPIP, cette fonctionnalité (assez lourde à
gérer manuellement en HTML) est automatisée : les notes sont numérotées
par SPIP, qui gère également des liens hypertextes à l’intérieur du document
pour passer directement de l’appel de note au texte de la note correspondante,
et vice-versa.
Une note de bas de page est indiquée, dans SPIP,
entre doubles crochets : « Une note[[Voici un complément d'information.]] de
bas de page. » sera affiché
sous la forme : « Une note[1] de bas de page. »
q Citer un extrait (de forum)
Il est souvent pratique, dans un forum de discussion,
de citer un extrait du message auquel on est en train de répondre. Pour
homogénéiser la présentation de telles citations, SPIP propose le raccourci ....
Par exemple :
<quote>C drôlement bien,
SPIP.</quote> Kikou, je suis bien d'accord :-) |
donne :
C’est drôlement bien, SPIP.
Kikou, je suis bien d’accord :-)
Les raccourcis qui suivent offrent des
fonctionnalités plus puissantes et d’un usage plus spécifique. Si cela est
votre premier contact avec les raccourcis de SPIP, il est sans doute inutile
que vous tentiez de les apprendre par cœur dès maintenant. Il vous suffit de
savoir qu’ils existent ; lorsque vous en aurez réellement besoin, revenez
sur cette page, il sera alors beaucoup plus facile pour vous de mémoriser des
raccourcis dont vous avez réellement l’utilité.
q
Tableaux
Pour réaliser des tableaux très simples dans SPIP,
il suffit de faire des lignes dont les « cases » sont séparées par le
symbole « | » (pipe, un trait vertical), lignes commençant et
se terminant par des traits verticaux. Il est impératif de laisser des lignes
vides avant et après ce tableau.
Par exemple, le tableau :
Nom |
Prénom |
Age |
Marso |
Ben |
23 ans |
Capitaine |
|
non connu |
Philant |
Philippe |
46 ans |
Cadoc |
Bébé |
4 mois |
se code ainsi :
|
{{Nom}} | {{Prénom}} | {{Age}} | |
Marso | Ben | 23 ans | |
Capitaine | | non connu | |
Philant | Philippe | 46 ans | |
Cadoc | Bébé | 4 mois | |
Remarquez que toutes les entrées de la première
ligne sont placées en gras. SPIP identifie ainsi qu’il s’agit d’une page
d’entête, et lui attribue une présentation différente des autres lignes (fond
de couleur différente). La présence d’une telle ligne n’est pas obligatoire.
q Gestion affinée des listes et des énumérations
Un simple retour à la ligne s’obtient en tapant _ (le trait de soulignement ou underscore) au
début de la ligne, suivi d’une espace.
N.B.
En typographie classique, le simple retour à la ligne est très rare (limité
essentiellement à la poésie). On le confond souvent avec le changement de
paragraphe tel qu’il est affiché sur les documents imprimés (sans espacement
vertical entre les paragraphes), alors que, par défaut, les butineurs Web
insèrent un espacement entre les paragraphes. Beaucoup d’utilisateurs cherchent
à reproduire cette caractéristique de l’imprimé (pas d’espacement vertical) en
insérant de simples retours à la ligne entre ce qu’ils considèrent être des
paragraphes ; cela est un erreur qui risque de nuire à la facilité de
maintenance et d’évolution de leur site. La solution consiste à définir, dans
les squelettes, une feuille de style (CSS) décrivant le comportement des
paragraphes (c’est-à-dire, selon les choix, pas d’espacement vertical entre les
paragraphes, indentation de la première ligne...).
q On peut faire des énumérations imbriquées en
ajoutant des étoiles après le tiret d’énumération.
Ainsi :
-* Ton cheval est: -** alezan; -** bai; -** noir; -* mais mon lapin est -** blanc: -*** angora -*** ou à poil ras. |
donne :
· Ton cheval est :
o alezan ;
o bai ;
o noir ;
· mais mon lapin est
o blanc :
§ angora
§ ou à poil ras.
q Enfin, on peut faire des listes numérotées en
utilisant le # à la
place de l’étoile :
-# premier -# deuxieme -# troisieme |
donnera :
1.
premier
2.
deuxième
3.
troisième
q
Les
liens hypertextes vers un glossaire externe
Vous pouvez en outre créer très rapidement un lien
hypertexte vers la définition d’un terme dans un glossaire externe ; pour
un terme donné, il suffit d’insérer au sein de votre texte le raccourci [?terme].
Ainsi le code suivant : « {À
la recherche du temps perdu} est l'œuvre majeure de
[?Marcel Proust] » donnera
à l’affichage : « À la recherche du temps perdu est l’œuvre
majeure de Marcel
Proust ». Pensez à cliquer sur le lien pour vérifier que le terme
entré (nom propre ou nom commun) est correctement orthographié, et qu’il pointe
sur une destination valide.
Le glossaire externe prédéfini est Wikipedia. Il s’agit d’une
encyclopédie multilingue écrite sur un mode coopératif,
ouverte à tous les contributeurs via Internet. Prenez le temps de la connaître,
de la respecter et d’y contribuer afin d’enrichir ce fonds de savoir partagé.
q
Des
notes non automatiques
Dans la plupart des cas, le système de notes
automatiques indiqué ci-dessus suffit amplement. Cependant, vous pouvez gérer
les notes d’une manière non automatique en « forçant » le choix du
numéro ou de la mention affichée pour réaliser le lien.
Le principe général consiste à indiquer votre choix
de la mention utilisée entre chevrons au début de la note :
Une note «forcée»[[<xxx> Le
texte de la note.]] |
Sur ce principe :
vous pouvez utiliser les notes
numérotées automatiques[[En plaçant le texte de la note entre crochets.]], - mais aussi forcer la numérotation
de la note[[<23> En indiquant le numéro de la note entre les symboles
«<» et «>».]], - utiliser des notes sous forme
d'astérisques [[<*> En plaçant simplement une astérisque entre les
symboles «<» et «>».]], - fabriquer des notes sans références
(non numérotées); attention, de telles notes ne présentent plus de lien entre
la note et l'appel de note[[<> En n'indiquant rien entre les symboles
«<» et «>».]], - donner un nom (en toutes lettres) à
une note; cet usage est très répandu pour les références
bibliographiques[[<Rab> François Rabelais.]]; - rappeler une note déjà
existante[[<23>]] en indiquant le numéro de cette note entre les symboles
«<» et «>». et en laissant vide le reste de la note. |
donne :
Ø
vous pouvez utiliser
les notes numérotées automatiques [2],
Ø
mais aussi forcer la
numérotation de la note [23],
Ø
utiliser des notes
sous forme d’astérisques [*],
Ø
fabriquer des notes
sans références (non numérotées) ; attention, de telles notes ne
présentent plus de lien entre la note et l’appel de note,
Ø
donner un nom (en
toutes lettres) à une note ; cet usage est très répandu pour les
références bibliographiques [Rab];
Ø
rappeler une note
déjà existante [23],en indiquant le numéro de cette note entre les
symboles « < » et « > ». et en laissant vide le reste
de la note.
q Court-circuiter les raccourcis SPIP
Dans certains cas, il peut être utile d’indiquer à
SPIP que certaines parties d’un document ne doivent pas être
« traitées » par le filtre des raccourcis typographiques : vous
ne voulez pas corriger la typographie, vous devez afficher du code source (par
exemple en PHP, JavaScript...)...
Le code de ce raccourci
est :
«
<HTML>texte à
ne
pas transformer;
attention!</HTML>
»,
ce qui donne : « texte à ne pas transformer; attention! (ici, notez l’absence d’espaces avant le point-virgule et le point d’exclamation).
q Afficher du code informatique
Certains utilisateurs de SPIP veulent parfois
afficher du code informatique dans leurs pages. Le raccourci ...
est là pour ça.
Exemple : <?php // ceci est du langage
php echo "bonjour"; ?>
donne bonjour
Il existe un autre raccourci pour publier des
extraits de code informatique de plusieurs lignes : .... Cela place le code dans un
« formulaire » (ceci est souvent utilisé sur la présente page).
L’avantage de cette méthode est de faciliter grandement le copier-coller à
partir de votre page Web : il suffit de placer le curseur à l’intérieur du
code, de faire « tout sélectionner » (alt-A) pour pouvoir copier
directement le code. De plus sur de nombreux butineurs, ce cadre permet de bien
restituer les tabulations en début de ligne.
Voici un exemple :
class Texte { var type =
'texte'; var
texte; } class Champ { var
type = 'champ'; var
nom_champ, id_champ; var
cond_avant, cond_apres; // tableaux d'objets var
fonctions; } |
Le titre est obligatoire.
q Le surtitre et le soustitre sont totalement
optionnels. Si vous n’en avez pas besoin, laissez-les vides, la présentation du
site s’adaptera automatiquement à leur présence ou absence.
Les administrateurs du site peuvent, s’ils le
désirent, totalement supprimer l’utilisation du surtitre et/ou du soustitre,
via la page « Configuration
précise ».
Le menu indique toute la hiérarchie
des rubriques (telles qu’elles ont été créées par les administrateurs du
site) : sélectionnez celle dans laquelle vous voulez placer l’article.
Beaucoup d’utilisateurs débutants semblent ignorer
complètement cette fonction pourtant simple, et laissent leur article
« n’importe où » dans la structure du site. Il est donc conseillé aux
administrateurs, avant validation d’un article, de toujours vérifier que
celui-ci se trouve dans la bonne rubrique.
Le descriptif rapide est utilisé pour la
navigation à l’intérieur du site : il permet d’indiquer brièvement, dans
les sommaires par exemple, le thème de l’article.
Ce descriptif est optionnel ; de même, on peut
le rédiger de la longueur que l’on veut. Cependant, il a été prévu à l’origine
pour des textes très courts (une ou deux phrases), qui figureront dans les
listes d’articles (sommaires, listes des articles de tel auteur, tri d’articles
par mot-clé, réponses du moteur de recherche, etc.).
Les administrateurs du site peuvent, via
l’interface de « Configuration
précise », désactiver totalement l’affichage du descriptif.
Le chapeau, dans le jargon de la presse,
désigne le court texte qui « chapeaute » l’article. Son utilisation
est optionnelle.
Les administrateurs peuvent, via l’interface de
« Configuration précise », désactiver totalement
l’utilisation du chapeau.
Cette option permet de créer un « article
virtuel » : il s’agit d’un article dont le titre, la date et les
auteurs sont enregistrés dans votre site sous SPIP, mais qui pointe vers une
autre adresse.
Cette fonctionnalité vous permet de référencer dans
votre système SPIP des articles qui ne sont pas réalisés avec SPIP (par exemple
pour intégrer à la navigation de votre site sous SPIP des pages réalisées
antérieurement à l’installation de SPIP).
Pour indiquer que votre article est un
« article virtuel », il suffit d’indiquer l’URL de l’article-cible
dans la case correspondante.
Pour supprimer la redirection, il suffit de
« vider » la case de redirection (effacer l’adresse de l’article-cible).
Rien de bien compliqué : il s’agit du texte
de votre article, comme son nom l’indique.
q Il y a cependant un point qui peut parfois poser
problème : la longueur des textes. Pour certains textes très longs (dans
notre expérience, à partir de 32 ko), il arrive que ce texte soit tronqué
ou carrément refusé lors du transfert dans SPIP. Ce problème n’est pas dû à
SPIP, mais aux navigateur Web que vous utilisez. Lorsque vous êtes confronté à
un texte « trop long » pour un navigateur, essayez avec un autre
logiciel.
q Le texte de l’article se prête particulièrement
bien à l’utilisation des raccourcis typographiques de SPIP.
La date de l’article correspond, en général,
à la date de sa mise en ligne (ou publication sur le site Web).
q Cette date est fixée automatiquement au moment où
l’article est validé par un administrateur (donc au moment où il
apparaît sur le site public).
q Après validation, toutefois, l’admin peut modifier
cette date.
Cette fonction a été ajoutée pour des cas très
spécifiques, lorsque SPIP est utilisé pour installer des archives et que
ces archives doivent avoir une date de publication différente de la date de
mise en ligne.
Il s’agit de pouvoir indiquer qu’un document a déjà
fait l’objet d’une publication antérieure : article de journal, livre...
q Par défaut, cette date ne s’affiche pas : le
bouton « Ne pas afficher de date de publication antérieure » est
sélectionné lors de la création de l’article.
q Si l’on veut indiquer une telle date, il faut à la
fois sélectionner l’option « Afficher la date » et utiliser les menus
déroulants pour la fixer.
Cette date, contrairement à la « date de
publication » de l’article, n’est pas calculée automatiquement lors de la
validation de l’article. C’est pourquoi elle peut être modifiée à tout moment.
Les administrateurs peuvent, via l’interface de
« Configuration précise », désactiver l’utilisation de la
date de publication antérieure.
Lorsqu’un administrateur ou un rédacteur crée un
article, il est considéré automatiquement comme l’auteur de cet article. Dans
bien des cas il faudra changer les auteurs (quand on intègre au site le texte
d’une autre personne, quand un texte ne doit pas être signé, ou encore quand on
l’édite à plusieurs...)
q Ajouter un auteur
Un menu déroulant proposant la liste de tous les
rédacteurs du site permet de sélectionner et d’ajouter un nouvel auteur.
Si plus de 50 rédacteurs participent au site, il
est difficile de les présenter sous forme de menu déroulant (temps de
chargement interminable) ; dans ce cas, le menu déroulant est remplacé par
une case de recherche : indiquez le nom de l’auteur que vous voulez
ajouter, et cliquez sur « Chercher ». Si plusieurs rédacteurs
correspondent à cette recherche, le système vous proposera de sélectionner celui
qui vous convient.
q Retirer un auteur
A la suite de chaque auteur de l’article, un lien
« Retirer l’auteur » permet de simplement effacer cet auteur.
C’est uniquement en tant qu’auteur de cet article
précis que le rédacteur est supprimé ; il reste bien entendu présent dans
la liste des rédacteurs du site.
q Remplacer un auteur par un autre
Cela se fait en deux étapes : il faut
simplement ajouter le nouvel auteur, et retirer le précédent (voir ci-dessus).
q Notez finalement que les administrateurs ont beaucoup
plus de possibilités sur cette liste d’auteurs que les rédacteurs. Les
rédacteurs ne peuvent pas, en particulier, se retirer eux-mêmes d’un article.
Si un rédacteur veut publier un article anonyme (sans auteur), il doit demander
à un administrateur d’effectuer cette opération.
SPIP vous permet d’installer un logo correspondant
à l’article. De cette façon, dans l’interface de navigation du site public, il
sera possible d’afficher un bouton graphique menant à l’article.
Pour un article, il est possible :
q de ne pas utiliser de logo ;
q d’installer un logo graphique simple ;
q d’utiliser un logo animé gérant le
« survol » (logo « 2 positions » : le logo change
lorsque que la souris le survole).
¬
Formats
d’images
Lorsque vous créez vos images (avec votre logiciel
habituel), vous devez les créer à l’un des formats suivants :
q GIF (le fichier GIF peut être un « GIF
animé ») ;
q JPEG ;
q PNG (déconseillé, de nombreux butineurs ne
permettant pas de les afficher correctement).
Afin d’éviter les erreurs graves de manipulation,
SPIP rejette les fichiers-image d’une taille supérieure à 256 ko. Conseil : puisque ces « boutons »
sont des éléments de l’interface graphique, veillez à ce que leur poids
(nombre de kilo-octets) ne soit pas trop élevé (en général, moins de
10 ko) si vous voulez que la navigation sur votre site reste fluide.
Veillez particulièrement à ce que le nom de vos
fichiers ait une terminaison indiquant leur format : .gif,
.jpg ou .png. Le nom du fichier n’a aucune
importance, à condition de ne pas oublier cette terminaison.
Si vous créez un bouton gérant le
« survol », créez deux fichiers graphiques différents (un pour le
bouton « normal », et un autre fichier s’affichant lorsque le bouton
est survolé par la souris) : il convient alors que ces deux fichiers aient
exactement la même taille (en pixels).
¬
Logo simple (pas de survol)
Pour
ajouter un bouton, une interface est disponible dans la colonne de gauche de
l’article, sous la mention « LOGO DE L’ARTICLE ».
Selon la version de votre navigateur, cliquez sur
le bouton « Browse », « Sélectionner », « File »,
« Fichier »... ce qui déclenche l’ouverture d’une interface
permettant de sélectionner, sur votre disque dur, le fichier graphique correspondant
à votre bouton.
Une fois ce fichier sélectionné, cliquez sur le
bouton « Télécharger ». Votre logo s’affiche alors. Il est suivi d’un
bouton « Supprimer le logo », qui vous permet, simplement, de
supprimer ce logo.
Si vous ne comptez pas obtenir un logo gérant le
survol, aucune autre opération n’est nécessaire.
¬
Remplacer
le logo
Il peut arriver que vous vouliez remplacer le logo
par un autre fichier. Cela se fait en deux étapes :
q commencez par « Supprimer le
logo » : l’interface précédente, dotée du bouton
« Télécharger », apparaît à nouveau ;
q téléchargez le nouveau fichier, selon la procédure
déjà décrite.
Du fait du fonctionnement des butineurs, l’image
qui s’affiche alors est erronée, puisqu’il s’agit encore de la version
précédente (l’image est « en cache » de votre navigateur). Cliquez
sur cette image (avec le bouton droit de votre souris, ou en maintenant la
touche « ctrl » sur Macintosh) afin de faire apparaître un menu
déroulant local : sélectionnez l’option « Recharger cette
image » (ou, en anglais, « Reload image »). La nouvelle version
de votre logo devrait alors s’afficher.
¬
Logo
pour le survol
Après
l’installation du premier fichier (logo simple), l’interface affiche non
seulement le logo que vous avez installé sur le serveur, mais ajoute une
seconde interface, sous le titre « LOGO POUR LE SURVOL ».
C’est par cette interface que vous pouvez indiquer
le second fichier nécessaire à la gestion du survol.
Si, lorsque vous avez installé les deux fichiers,
vous supprimez le premier (le bouton « simple »), l’interface du
second logo ne s’affiche plus. En effet, en l’absence du premier logo, il n’y a
plus de raison de gérer un quelconque « survol » !
Aucune intervention dans le « texte » de
votre article n’est nécessaire. Lors de l’affichage sur le site public, la
gestion des logos des rubriques est entièrement automatique. Le code HTML sera
généré en fonction de la taille du logo, et la fonction de survol en JavaScript
sera également créée automatiquement.
Le statut de l’article correspond à sa
situation éditoriale sur le site. L’article peut être :
q en cours de rédaction ;
q proposé à l’évaluation ;
q publié en ligne ;
q à la poubelle ;
q refusé.
Ces étapes, que seuls les administrateurs peuvent
modifier, permettent la gestion du site.
N.B.
Le statut des articles est symbolisé par des puces colorées.
Article en cours de rédaction
Lorsqu’il est créé, un article est naturellement
considéré comme étant « en cours de rédaction » : ses auteurs
sont en train de le rédiger, de le modifier...
L’article « en cours de rédaction » n’est
visible que par les auteurs de l’article et par les administrateurs. Les autres
rédacteurs du site n’y ont pas accès.
Article proposé à l’évaluation
Lorsque l’auteur juge que son article est prêt, il
le « propose » aux autres participants, afin qu’il soit
éventuellement discuté collectivement, avant d’être validé (publié en ligne) ou
refusé.
Lorsque l’article est « proposé à
l’évaluation », il est indiqué sur la page « à suivre » de tous
les utilisateurs de l’espace privé, qui sont ainsi invités à venir le discuter
par l’intermédiaire du forum de discussion interne placé à la suite de
l’article.
Un tel article est alors visible par tous les
rédacteurs. En revanche, il ne peut être modifié que par son auteur ou un
administrateur.
Article publié en ligne
Après avoir été éventuellement discuté par les
rédacteurs (pendant la phase de « proposition »), un article peut
être « validé », c’est-à-dire publié en ligne par un administrateur.
Dès lors, tous les visiteurs du site public y ont accès.
Lorsqu’un article est publié en ligne, seuls les
administrateurs peuvent le modifier. Son auteur doit donc demander à un
administrateur s’il veut y porter des corrections.
Article refusé
Un article « proposé » qui ne
conviendrait pas à la ligne éditoriale du site peut être « refusé »
si les administrateurs refusent de le publier en ligne.
Un article « refusé » n’est plus visible
que par son auteur et par les administrateurs.
Un article « refusé » ne peut cependant
plus être modifié par son auteur, qui ne pourra donc pas non plus le reproposer
à la publication. Dans le cas d’un article qui demanderait des retouches, on
préférera donc repasser l’article « en cours de rédaction » au lieu
de le « refuser » purement et simplement, afin que son auteur puisse
le modifier et le représenter ultérieurement.
Article à la poubelle
Un article peut être mis à la poubelle, uniquement
par un administrateur.
Un article « à la poubelle » n’est plus
visible dans l’espace privé, même par les administrateurs. Attention donc,
cette option est « violente » : l’article disparaît
complètement.
En réalité, l’article est toujours stocké dans la
base de données, mais devient très difficilement accessible avec les outils de
SPIP.
Cette option est donc réservée aux articles créés
par erreur, que l’on veut totalement détruire. On préférera, le plus souvent,
l’option « Article refusé », qui est moins définitive.
q Notez enfin que les administrateurs peuvent à tout
moment modifier le statut d’un article. Un article publié peut ainsi
être repassé en « rédaction ». Cependant, une fois un article publié
en ligne, n’abusez pas de ces changements de statut : vous obtiendriez en
effet un site « à trou », avec des pages qui apparaissent et
disparaissent, ce qui est très pénalisant pour le visiteur.
Lorsque l’article est « en cours de
rédaction » (voir la rubrique « Le statut de
l’article »), il est suivi d’un bouton « Demander la publication
de cet article ».
Seul l’auteur de l’article peut effectuer cette
opération.
Cela signifie que l’article est alors
« Proposé à l’évaluation », c’est-à-dire présenté à tous les autres
rédacteurs, qui seront invités à le commenter, dans l’attente d’une validation
(publication) ou d’un refus de la part des administrateurs.
Attention : une fois l’article « proposé
à l’évaluation », il n’est plus possible à l’auteur de revenir sur sa
décision et de repasser le texte « en cours de rédaction ». Donc
l’opération « Demander la publication de cet article » ne doit être
effectuée par l’auteur qu’une fois qu’il considère son texte comme complet et
définitif. Seul un administrateur peut alors remettre le texte « en cours
de rédaction ».
Lorsqu’un rédacteur intervient sur un article pour
le modifier, les autres participants au site qui se rendent sur la page de cet
article sont prévenus et il leur est déconseillé d’intervenir à leur tour sur
l’article.
En effet, si deux rédacteurs interviennent en même
temps sur le même article, les modifications de l’un risquent
d’« écraser » les modifications de l’autre.
Si vous voyez la mention « Attention, un
rédacteur est intervenu sur cet article », il est donc fortement
déconseillé de le modifier à ce moment. Revenez plus tard sur cet article, pour
intervenir lorsque l’autre rédacteur aura effectué et enregistré ses
modifications.
À l’inverse, lorsque vous-mêmes intervenez pour modifier un
article, les autres participants au site qui visiteraient cette page seraient
prévenus de votre intervention. Tant que vous modifiez l’article, et pendant
une durée d’une heure, les autres rédacteurs sont invités à ne
pas intervenir sur ce texte. Lorsque vous considérez que vous avez terminé de
travailler sur cet article, et que d’autres peuvent à leur tour intervenir
dessus, vous pouvez « libérer » cet article. L’avertissement aux
autres participants disparaîtra, et ils pourront si nécessaire effectuer leurs
propres modifications.
La structure des rubriques constitue l’ossature de
votre site ; c’est elle qui va déterminer son interface, le mode de
navigation, les relations entre articles et entre brèves...
Dans SPIP, cette structure est de type hiérarchique :
une rubrique peut contenir des sous-rubriques qui, elles-mêmes, contiennent des
sous-rubriques, etc.
Dans l’exemple ci-dessus, on comprend bien que la
rubrique 222 dépend de la rubrique 22, qui elle-même dépend de la
rubrique 2, laquelle ne dépend d’aucune autre rubrique (dans ce cas, on
considérera que la rubrique 2 se trouve à la racine du site).
Par structure hiérarchisée, on entend le fait
qu’une rubrique ne dépend que d’une seule autre rubrique (et non de plusieurs),
et qu’une rubrique ne peut dépendre d’une de ses propres sous-rubriques
(c’est-à-dire : SPIP n’autorise pas les structures circulaires). Cette
structure, très classique, a été retenue en raison de sa simplicité
d’utilisation.
Seuls les administrateurs peuvent créer, modifier
ou supprimer des rubriques.
Le fonctionnement de ce menu déroulant est très
simple : le menu indique toute la hiérarchie des rubriques (telles
qu’elles sont créées par les administrateurs du site), il suffit de
sélectionner celle dans laquelle on veut placer la sous-rubrique.
q
Déplacer
une rubrique
Vous pouvez, par l’intermédiaire de ce menu
déroulant, faire dépendre la présente rubrique d’une autre rubrique. Dans ce
cas, il faut comprendre que l’ensemble des sous-rubriques contenues dans la
présente rubrique se « déplacent » avec elle dans la hiérarchie du
site. De la même façon, les articles contenus dans cette rubrique et ses
sous-rubriques se déplacent avec elle.
Vous pouvez installer sur votre site un logo pour
chaque rubrique. Ce logo peut être soit un logo unique (image fixe), soit un
logo à deux positions gérant le survol de la souris.
L’installation d’images pour ce logo de rubrique se
déroule exactement de la même façon que pour le logo
d’un article.
N.B.
Les logos des rubriques ont un fonctionnement récursif : en
l’absence d’un logo pour une rubrique donnée, SPIP va tenter de lui substituer
le logo d’une rubrique dont elle dépend :
Dans la hiérarchie ci-dessus, en l’absence d’un
logo pour la rubrique 221, SPIP lui substituera (uniquement pour la visite
du site public) le logo de la rubrique 22 ou encore, s’il n’y a pas de
logo pour cette rubrique, celui de la rubrique 2. Sinon, SPIP affichera le
logo installé à la racine du site.
Notez encore que, si le webmestre l’a programmé
ainsi, le logo d’une rubrique pourra être utilisé comme logo de substitution
pour les articles qu’elle contient.
Les brèves constituent une méthode simple et rapide
de publication dans SPIP. Contrairement aux articles, les brèves sont
constituées d’un nombre très réduit d’informations : un titre, un texte et
un lien hypertexte. Ainsi, le système de brève est-il idéal pour un suivi de
l’actualité, une revue de presse en ligne, etc.
Afin de simplifier leur utilisation (et pour éviter
que les brèves ne fassent double-emploi avec les articles), l’intégration des
brèves dans la hiérarchie des rubriques est réduite au strict minimum :
les brèves dépendent uniquement des rubriques situées à la racine du site.
Dans notre exemple, on pourra placer des brèves
dans les rubriques 1 et 2, mais pas dans leurs sous-rubriques (contrairement
aux articles, que l’on peut placer n’importe où). De ce fait, la présentation
de la page des brèves se fait directement en fonction de ces grandes rubriques,
et le menu déroulant permettant d’indiquer la position des brèves est très
court.
Afin de faciliter l’utilisation des brèves dans le
cadre d’une revue de presse en ligne, chaque brève peut recevoir l’indication
d’un lien hypertexte. Il suffit d’indiquer le titre du site ou de l’article
référencé, et son adresse (URL).
Ces informations sont bien entendu optionnelles.
N. B.
Ce système de lien n’empêche pas d’intégrer des liens hypertextes dans le corps
du texte de la brève, mais le lien hypertexte séparé permet au webmestre
du site de lui appliquer un traitement graphique spécifique.
La gestion d’une brève est plus simple que celle
d’un article. Une brève n’a pas d’auteur. Son statut est soit
« Proposée », « Validée » ou « Refusée ». Seuls
les administrateurs peuvent en modifier le statut.
q Brève proposée
Les brèves « proposées » sont signalées
sur la page « A suivre » : tous les rédacteurs peuvent les
consulter et les modifier. Les administrateurs se voient proposer deux boutons
- permettant de les valider ou de les refuser.
q Brève validée
Les brèves « validées » sont celles qui
apparaissent sur le site public. Seuls les administrateurs peuvent dès lors les
modifier.
q Brève refusée
Une brève « refusée » n’est pas publiée
sur le site public, et seuls les administrateurs peuvent y accéder dans le site
privé.
Vous pouvez installer sur votre site un logo pour
chaque brève. Ce logo peut être soit un logo unique (image fixe), soit un logo
à deux positions gérant le survol de la souris.
L’installation d’images pour ce logo de brève se
déroule exactement de la même façon que pour le logo
d’un article.
SPIP vous offre la possibilité d’illustrer vos
articles et vos brèves avec des images. Cela s’effectue en plusieurs
étapes : vous devez envoyer le fichier de votre image vers le site, puis
insérer l’image à l’intérieur du texte.
Lorsque vous créez vos images (avec votre logiciel
habituel), vous devez les créer à l’un des formats suivants :
GIF (extension .gif),
JPEG (extension .jpg),
PNG (extension .png)
Veillez particulièrement à ce que le nom de vos
fichiers ait une terminaison indiquant leur format : .gif,
.jpg ou .png. Si vous installez un fichier
dont le nom ne contient pas cette extension, le système ne saura pas utiliser l’image.
Avant de pouvoir insérer vos images à l’intérieur
du texte, il faut bien entendu installer ces images sur le serveur. Cela se fait,
dans SPIP, par l’interface graphique.
Lorsque vous « modifiez » un article ou
une brève, la colonne de gauche vous propose une interface intitulée :
« Ajouter une image ». Cela se présente sous la forme d’un champ
suivi d’un bouton nommé, suivant les navigateurs, « parcourir »,
« Browse », « Sélectionner », « File »,
« Fichier »...
Lorsque vous cliquez sur ce bouton, une interface
s’ouvre, vous permettant de visiter votre disque dur et d’indiquer quel fichier
graphique vous voulez sélectionner.
Cela fait, cliquez sur le bouton intitulé
« Télécharger ».
Si l’opération a réussi, votre image apparaît dans
la colonne de gauche, complétée de plusieurs indications...
Une fois votre image envoyée au serveur, une case
apparaît sur la gauche de l’écran. Il y a là toutes les informations
nécessaires qui la concernent. (Une partie de ces informations apparaît
masquée, cliquer sur le triangle pour « déplier » la boîte
d’information.)
q Affichage sous forme de vignette. Une prévisualisation de votre image apparaît. Si
l’image est de grande taille (plus de 200 pixels de large), c’est une version
de taille réduite qui est affichée.
q Raccourcis SPIP. Voir ci-après : SPIP vous rappelle les 3
« raccourcis » qui vous permettent d’insérer cette image à
l’intérieur de votre texte. Notez que chaque image est « numérotée »
ainsi : « IMG1 », « IMG2 »... Ces
« raccourcis » sont utilisés dans la troisième étape.
q Taille de l’image. Juste au-dessus de l’image, la largeur et la hauteur
de votre image (en pixels - ou « points ») sont rappelées.
q Titre et description de l’image. Vous pouvez, si vous le désirez, indiquer un nom
et une description pour chaque image. Par exemple une explication, ou une
mention du copyright du photographe...
q Supprimer cette image. Comme son nom l’indique, le bouton
« Supprimer cette image » permet d’effacer ce fichier, si vous avez
fait une erreur de manipulation, ou si vous décidez finalement de ne pas
utiliser l’image dans ce texte. Il est conseillé d’effacer les images
inutilisées, afin d’éviter d’encombrer votre serveur avec des fichiers
inutiles.
Vous pouvez recommencer l’opération avec autant
d’images que vous le désirez (un article ou une brève peuvent contenir autant
d’images que nécessaire).
A ce stade, les fichiers graphiques sont bien
présents sur le serveur, mais il reste à indiquer à quel endroit de votre texte
vous voulez les insérer. Pour cela, inutile de faire du HTML, SPIP vous propose
un « raccourci » permettant d’insérer votre image simplement.
Images sans commentaire
Pour chaque image, voyez la mention des 3
raccourcis :
<img1|left>
<img1|center>
<img1|right>
Recopiez l’un de ces raccourcis (le nombre
correspond au numéro de l’image, il change donc pour chaque fichier), et
recopiez-le à l’intérieur de la case « Texte », là vous désirez le
situer dans votre article. « left » aligne l’image à gauche,
« right » à droite, et « center » place votre image au
centre du texte.
Lors de l’affichage à l’écran, SPIP remplacera ces
raccourcis par le code HTML correspondant, en calculant automatiquement la
taille des images.
Images avec titre et description
Si vous avez indiqué un titre et/ou une
description, les mentions sont remplacées par :
<doc1|left>
<doc1|center>
<doc1|right>
Elles s’utilisent de la même façon que
ci-dessus ; cependant, lorsque vous insérez un « raccourci » de
ce type, SPIP insère dans votre texte non seulement l’image, mais le titre et
la description que vous lui avez donnée. Votre image apparaît ainsi avec,
éventuellement, une explication et des mentions de copyright, le nom de
l’artiste, etc.
L’interface de SPIP vous permet de proposer sur
votre site des fichiers multimédia (son, vidéo, textes...).
Les rédacteurs peuvent joindre des documents aux
articles. Ces documents peuvent être soit présentés à la suite du texte (à la
façon de « pièces jointes »), soit présentés à l’intérieur du texte
sous la forme d’une vignette de prévisualisation.
Les administrateurs du site peuvent, de plus,
installer des documents directement dans les rubriques.
Notez bien la différence importante entre ces deux
utilisations : joints aux articles, les documents sont des « pièces
jointes », qui n’ont pas d’intérêt sans l’article auquel ils sont associés
(dans la navigation dans le site, on peut consulter de tels fichiers à partir
des articles) ; lorsqu’ils sont installés directement dans les rubriques,
les documents deviennent des éléments du site comparables aux articles et aux
brèves, et non plus des compléments d’information.
L’installation des fichiers sur le serveur se fait
au travers de l’interface « Joindre un document » pour les articles,
et « Publier un document dans cette rubrique » pour les rubriques.
Vous remarquerez que, pour les articles, cette
interface apparaît à deux endroits différents : en bas de la page de
chaque article, et dans la colonne de gauche (sous les images) lorsque vous
modifiez un article. Ces interfaces ont exactement la même fonction, mais vous
utiliserez l’une ou l’autre en fonction de vos besoins. Pour les rubriques,
l’installation des documents se fait sur la page de la rubrique concernée.
Avant d’installer vos fichiers, vous devez les
créer sur votre ordinateur. L’interface d’envoi des documents vous rappelle la
liste des formats autorisés sur ce système. Veillez absolument à nommer vos
fichiers avec la terminaison correcte (par exemple, « xxxxxx.mp3 »
pour un fichier au format MP3.
L’interface est la même que pour les images :
le bouton « Fichier », ou « File », ou
« Parcourir », « Browse » (selon les navigateurs) ouvre une
fenêtre qui vous permet de sélectionner le fichier sur votre disque dur. Une
fois ce fichier sélectionné, cliquez sur « Télécharger » pour envoyer
le fichier. Attention : selon la taille de votre fichier, cette
opération peut prendre du temps. Notez aussi que, selon les réglages de
l’hébergeur de votre site, les fichiers trop gros pourront être refusés ;
dans ce cas, vous pourrez contourner cette limitation en installant vos fichiers par FTP.
Une fois le fichier transféré sur le serveur, une
boîte d’information apparaît. Plusieurs opérations peuvent y être réalisées.
Vignette de prévisualisation
Cette notion est très importante :
contrairement aux images, que l’on insère dans le corps du texte, les documents
n’apparaissent pas directement. Une vignette de prévisualisation est présentée
au visiteur, sur laquelle il pourra cliquer pour obtenir le document
correspondant.
La partie supérieure de la boîte d’information vous
permet de choisir la vignette de prévisualisation. Vous pouvez opter pour une vignette
par défaut, ou installer un logo personnalisé.
La vignette par défaut est installée
automatiquement par le système, en fonction du format du document. L’avantage
de laisser une telle vignette est que la présentation des documents d’un même
type sur l’ensemble de votre site sera uniforme.
Si vous préférez, vous pouvez installer un logo (de
taille réduite de préférence, et au format GIF, JPG ou PNG), qui apparaîtra à
la place de la vignette par défaut. Une fois un tel logo installé, un lien
« Supprimer la vignette personnalisée » vous permettra de revenir à
la vignette par défaut si nécessaire.
Dans la page de modification des articles, les
« raccourcis » vous permettant d’insérer le document dans le corps du
texte sont présentés, identiques à ceux des images.
La partie inférieure vous permet de donner
un titre et de fournir un descriptif pour votre document. Inutile d’indiquer
ici le format et le poids du fichier multimédia, cette information sera fournie
automatiquement par le système de publication.
Enfin, le bouton « Supprimer ce
document » permet d’effacer les documents inutiles. Notez bien :
il est impératif de supprimer les documents non désirés, faute de quoi ils
apparaîtront sur le site public.
Dans le cas des documents installés
dans les rubriques, vous pouvez de plus modifier la date de mise en
ligne du document (sur le même principe que vous modifiez la date de
publication d’un article ou d’une brève). Une fois ces réglages effectués, les
documents des rubriques sont immédiatement disponibles sur le site public (il
n’est pas nécessaire de les « valider » comme les brèves ou les
articles).
Pour les documents associés aux articles, vous
pouvez vous contenter de les installer et de préciser les informations (étapes
1 et 2 ci-dessus). Lorsque vous publierez l’article, ces documents apparaîtront
à la suite du texte sous la forme d’une liste de documents joints.
Cependant, vous pouvez également décider d’insérer
les vignettes de prévisualisation à l’intérieur du texte. Vous obtiendrez ainsi
des images cliquables à l’intérieur de l’article.
Ici, la procédure est exactement la même que pour
les images, à la différence près que les vignettes seront des éléments
cliquables. Insérez un raccourci de la forme <imgxx|yy> ou
<docxx|yy> selon que vous voulez afficher uniquement la vignette, ou bien
le titre et le descriptif.
Notez bien : les documents que vous aurez installé à l’intérieur du texte
n’appaîtront plus sous l’article. Pour les articles, il y a donc deux
emplacements où apparaissent les documents : à l’intérieur du texte
(vignette cliquable), ou à la suite de l’article sous la mention
« Document joint ».
Certains formats de fichiers multimédia sont conçus
pour être affichés directement dans une page Web (par exemple une vidéo insérée
directement dans l’article).
Pour pouvoir insérer de tels documents dans le
corps de l’article, non plus sous forme de vignette cliquable, mais en tant
qu’animation multimédia, vous devez indiquer ses dimensions : largeur et
hauteur absolument supérieures à zéro (pour les fichiers audio, on choisira
pour largeur la dimension que l’on souhaite attribuer au curseur de défilement,
et une hauteur réduite, par exemple 25 pixels).
Notez bien : les cases vous permettant d’indiquer les dimensions n’apparaissent
que pour les documents dont le fichier correspond à certains formats acceptés
par SPIP pour l’intégration à l’intérieur des articles (notamment : avi,
quicktime, real, flash).
Une fois ces dimensions fixées, un
raccourci SPIP supplémentaire vous sera proposé, de la forme <embxx|yy> (pour mémoire : « embed »).
Si vous connaissez bien le fonctionnement de ces
types d’inclusion, sachez que vous pouvez ajouter des paramètres
supplémentaires, par exemple :
<emb54|center|autostart=true|quality=hight> |
Certains serveurs interdisent l’envoi de fichiers
au travers d’une interface Web. Surtout, il peut être pénible d’envoyer des
fichiers lourds de cette façon. SPIP permet de contourner ces limitations en
installant directement les fichiers que vous souhaitez utiliser comme images ou
comme documents par FTP.
Cette opération est donc évidemment réservée aux
personnes qui possèdent les codes de connexion au serveur par FTP.
Il suffit, avec votre logiciel de FTP habituel,
d’installer vos fichiers (images, documents multimédia) dans le dossier
/ecrire/upload de votre site SPIP.
Cela fait, un menu déroulant apparaîtra
automatiquement après l’interface de téléchargement des fichiers par le Web,
vous proposant la liste des fichiers contenus dans ce dossier. Il vous suffit
de sélectionner le fichier qui vous intéresse, et de valider votre choix.
Si l’opération est réussie, pensez à supprimer ce
fichier du dossier /ecrire/upload (le système en a créé une copie à un autre
endroit du serveur, votre fichier d’origine n’est donc plus utile), afin de ne
pas allonger indéfiniment la liste du menu déroulant.
Si vous installez plusieurs fichiers à la fois dans
le dossier /ecrire/upload, une fonctionnalité supplémentaire vous est proposée
dans l’interface du site : vous pourrez installer tous ces fichiers en une
seule opération. Cela peut se révéler pratique pour créer rapidement des
portfolios.
L’une des limitations importantes de SPIP est sa
structure hiérarchique : chaque article ne peut se trouver que dans une
seule rubrique, ce qui pose parfois des difficultés de classement.
Les mots-clés offrent un moyen de navigation
transversal à l’intérieur du site. En associant un ou plusieurs mots-clés à un
article, on dispose en effet d’un moyen de créer des liens avec d’autres
articles aux thèmes similaires, mais situés dans d’autres rubriques.
Les mots-clés n’ont réellement d’intérêt que si
chaque mot est associé à plusieurs articles, afin de pouvoir relier ces
différents articles entre eux.
Seuls les administrateurs peuvent créer et modifier
les mots-clés.
Fréquemment, la structure des rubriques, si elle
est bien conçue, permet de se passer des mots-clés : les articles de
thèmes similaires se trouvent simplement dans les mêmes rubriques, il est alors
inutile d’ajouter des mots-clés pour indiquer le thème de chacun. Les
administrateurs peuvent donc, dans la page de Configuration précise,
désactiver totalement l’utilisation des mots-clés.
Afin de diversifier la navigation dans le site, il
est possible d’associer des mots-clés
aux articles, aux brèves et aux sites référencés. Ainsi le visiteur du site
pourra non seulement naviguer de rubrique en rubrique, mais également d’un
article traitant d’un thème (indiqué par un mot clé) à un autre article associé
au même mot-clé.
Il est possible d’indiquer, pour chaque article,
brève ou site, autant de mots-clés que nécessaire.
Un menu déroulant indique la totalité des mots-clés
du site. Son utilisation est très simple. Attention : lorsqu’il existe
plus de 50 mots-clés, ce menu déroulant est remplacé par un moteur de recherche : indiquez le mot désiré, et cliquez sur
« Recherche ».
N. B.
Seuls les administrateurs peuvent créer des mots-clés, à partir de la page qui
est consacrée à leur gestion (bouton « Les mots-clés » dans
l’interface de navigation supérieure).
Les administrateurs peuvent désactiver
l’utilisation des mots-clés pour l’ensemble du site, via l’interface
« Configuration précise ».
Lorsque l’on utilise beaucoup de mots-clés, il peut
devenir difficile de les manipuler rapidement. C’est pourquoi on peut créer des
groupes réunissant ces mots. L’interface devient alors plus claire (par
exemple, un groupe « Pays » regroupera « Namibie »,
« Allemagne », « Pérou », tandis qu’un groupe
« Thèmes » regroupera « Chômage », « Poésie »,
« Animaux »...).
SPIP propose un système complet permettant de gérer
des listes de liens vers d’autres sites. Ce système est très complet et permet
notamment :
q de regrouper ces listes dans des rubriques (dans
les mêmes rubriques que des articles, ou des rubriques spécifiques dédiées à
cet usage, à la façon d’un annuaire de liens) ;
q d’attribuer un logo à chaque site ;
q d’attribuer des mots-clés pour chaque site
référencé ;
q d’ajouter un descriptif personnalisé pour chaque
site.
On peut de plus, pour les sites qui l’autorisent,
récupérer automatiquement les derniers articles publiés (voir « Les
sites syndiqués »).
Un bouton « référencer un nouveau site »
dans la page de chaque rubrique de votre site vous permet d’indiquer un nouveau
site.
La méthode « traditionnelle » consiste à
indiquer le nom du site, l’URL de cette page, puis d’insérer une description.
Il est également possible de choisir la rubrique dans laquelle ce référencement
sera inséré dans votre propre site.
Un cadre en bas de page vous permet de gérer,
éventuellement, la syndication de contenu.
Pour plus de précisions sur ce sujet, voyez l’explication sur les sites
syndiqués. Pour un référencement simple, il suffit de laisser l’option
« Pas de syndication ».
Lors de la création d’un nouveau référencement de
site, un cadre apparaît en haut de page vous permettant de référencer
rapidement un site, sans indiquer vous-même son titre et son descriptif. Pour
cela, il vous suffit d’indiquer l’URL de la page à référencer et de valider.
Dans la mesure du possible, SPIP va récupérer automatiquement à cette adresse
le titre de la page et un descriptif. Vous pourrez ultérieurement modifier ces
informations.
Dans la page de « Configuration précise du
site », les administrateurs peuvent indiquer que seuls les administrateurs
peuvent proposer des sites, ou les rédacteurs, ou même les visiteurs du site
(dans ce cas, un formulaire sur le site public permettra aux visiteurs de
proposer des sites).
Dans tous les cas, seuls les administrateurs
pourront valider ces propositions de référencement. Lorsqu’un référencement de
site est proposé, tous les participants à l’espace privé peuvent discuter dans
un forum lié à chaque site de la pertinence du référencement.
Les sites fabriqués à l’aide d’un système de
publication automatique (tel SPIP ou phpNuke) peuvent facilement créer un
fichier indiquant en permanence la liste de leurs dernières publications. Il
existe en particulier un format standardisé pour un tel fichier, intitulé « fichier
backend ».
Ce fichier peut être facilement analysé de manière
automatique, afin de récupérer en permanence la liste des nouveautés de tels
sites. De cette manière, SPIP vous permet d’afficher sur votre propre site la
liste des derniers articles publiés sur d’autres sites.
Pour chaque site référencé dans vos propres
rubriques, vous avez la possibilité d’indiquer qu’il faut récupérer la liste
des derniers articles publiés sur ce site. Cela, évidemment, si le site
référencé propose un fichier backend.
Pour les sites gérés sous SPIP ou phpNuke, ces
fichiers backend sont faciles à localiser : il s’agit tout
simplement du fichier situé à la racine du site, et portant le nom « backend.php3 » (éventuellement, « backend.php »). Par exemple, pour uZine (http://www.minirezo.net/), l’adresse du fichier backend est :
· http://www.minirezo.net/backend.php3
Autres exemples de fichiers de
backend :
· http://www.davduf.net/backend.php
· http://www.vacarme.eu.org/backend.php3
· http://www.vakooler.com/backend.php3
Notez enfin que L’autre portail fournit de tels fichiers pour les sites
qu’il référence, même si ces sites ne comportent pas leur propre système de
backend. Vous trouverez sur cette page une trentaine de fichiers backend pour
les sites référencés par L’autre portail, ainsi qu’une poignée de
fichiers thématiques.
Lorsque vous référencez
un site dans une de vos rubriques, en plus d’indiquer le nom du site, l’URL de
sa page d’accueil et une description, vous pouvez choisir de le syndiquer (un
site syndiqué est donc avant tout un site référencé, pour lequel on demande à
SPIP de récupérer la liste des dernières publications).
Pour cela, sélectionnez
l’option « Syndication » et indiquez l’adresse du fichier backend
du site désiré. Après validation, un message vous indiquera immédiatement si la
syndication a
fonctionné correctement.
Si la syndication a
échoué :
q
vérifiez l’URL que vous avez indiquée pour ce site ;
q
vérifiez que le site que vous souhaitez syndiquer est actuellement
accessible en ligne.
La fonction de référencement rapide d’un site
(indiquer directement l’URL d’un site, SPIP se chargeant de récupérer
automatiquement les informations nécessaires) est particulièrement adaptée aux
sites syndiqués. En effet, au lieu d’indiquer lors du référencement rapide
l’URL de la page d’accueil, préférez alors indiquer l’URL du fichier backend
de ce site : SPIP récupérera automatiquement un grand nombre
d’informations et procédera directement à la syndication.
Lorsque la syndication fonctionne,
SPIP affiche la liste des derniers articles publiés par ce site. Voyez la page
de l’aide consacrée à la gestion de ces
liens.
SPIP fabrique automatiquement le fichier backend de
votre propre site. Cependant, n’oubliez pas de paramétrer le nom et l’adresse
de votre site sur la page de configuration
précise.
Lorsque vous réclamez la syndication d’un site, SPIP affiche la liste des derniers articles publiés
sur ce site, sous la mention « Articles syndiqués tirés de ce site ».
Pour chaque article, SPIP indique :
q le titre de l’article (il suffit de cliquer sur ce
titre pour accéder à l’article sur son site d’origine) ;
q éventuellement les auteurs des articles ;
q éventuellement un descriptif de l’article.
Ces informations, tirées automatiquement du site
référencé, ne peuvent pas être modifiées.
De plus, pour chaque article, un bouton
« bloquer ce lien » vous permet d’en bloquer l’affichage sur votre
propre site (parce qu’un article ne vous convient pas, parce qu’une erreur rend
ce lien inopérant...). Vous pourrez à tout moment rétablir l’affichage de cet
article sur votre site.
Il est possible de demander que chacun des futurs
liens en provenance du site soit a priori bloqué. Les articles ainsi récupérés
ne s’afficheront qu’une fois que vous les aurez, un par un, validés « à la
main ».
Si votre site se situe derrière un pare-feu (firewall),
il peut être nécessaire de configurer un proxy HTTP pour aller chercher sur
Internet les nouveautés de sites syndiqués.
Ce proxy doit autoriser les requêtes vers l’extérieur
sans authentification aucune.
Indiquez, dans la configuration de votre site
(section « fonctionnalités de SPIP »), le proxy au format
suivant :
http://nomproxy:port/
où nomproxy est le nom du serveur faisant
office de proxy, et port le numéro de port TCP (le plus souvent 3128,
8080, voire 80) sur lequel envoyer les requêtes.
Attention : ce réglage est global : SPIP
ira chercher tous les sites syndiqués à travers ce proxy. Si vous avez besoin
de réglages plus fins, il faudra impérativement vous tourner vers
l’administrateur de votre réseau.
SPIP facilite l’envoi de messages entre
utilisateurs du site, sans passer par l’échange d’emails.
Lorsqu’un message est « envoyé » par un
utilisateur à un ou plusieurs autres utilisateurs, il devient un forum de
discussion privé. Ainsi, une fois un message envoyé, une discussion peut avoir
lieu, sous la forme d’un forum placé sous le texte de ce message. Dans SPIP, on
peut donc considérer qu’un message est également un forum privé (c’est-à-dire
qu’il est inutile de s’envoyer une multitude de messages pour discuter, il
suffit de « rester » dans un même message avec son correspondant pour
« discuter » grâce au forum privé qui lui est associé).
Note : Les messages entre utilisateurs et les forums qui y sont associés
sont privés, c’est-à-dire que SPIP n’offre pas d’interface permettant aux
administrateurs du site de voir ces messages. Cependant, nous attirons votre
attention sur le caractère très relatif de cette confidentialité : un
administrateur du site, doté d’un outil d’accès direct à la base de données,
pourra toujours consulter ces messages.
La méthode la plus simple pour envoyer un message
consiste à cliquer sur le logo vert (un petit « M » complété d’un
triangle) qui est affiché à côté du nom de votre destinataire. Cela ouvre
immédiatement un nouveau message.
La seconde méthode consiste à utiliser le bouton
« Nouveau message » présent sur chaque page de SPIP. Cela créé un
nouveau message sans destinataire. Avant de pouvoir envoyer ce message, vous
devrez évidemment indiquer à qui il est destiné.
L’interface de rédaction de ces messages est très
simple.
La seule erreur courante consiste à oublier
d’« envoyer » ce message : tant que le message est indiqué
« en cours de rédaction », seul son auteur peut y accéder. Il faut
donc l’envoyer pour qu’il soit présenté à ses destinataires (attention :
une fois un message envoyé, il ne peut plus être modifié).
À tout moment il est possible d’ajouter un
destinataire : soit pendant la rédaction du message, soit lorsqu’il est
déjà envoyé (par exemple pour inscrire un nouveau participant à une discussion
dans un forum qui l’intéresse).
De la même façon, on peut retirer un participant à
tout moment. Un bouton « Ne plus participer à cette discussion »
permet d’ailleurs à l’un des participants de s’exclure de lui-même d’une
discussion.
N’importe quel message peut être transformé en
rendez-vous : c’est-à-dire qu’il est lié à une date et affiché dans le
calendrier de SPIP.
Certains rédacteurs ne peuvent pas être joints (ils
n’apparaissent pas dans la liste « Ajouter un participant », et leur
nom n’est pas accompagné d’un logo de messagerie) :
q les rédacteurs qui ont décidé individuellement de
ne pas utiliser la messagerie interne ;
q les rédacteurs qui ne se sont pas connectés à
l’espace privé du site depuis plus de 15 jours ne sont pas joignables (pour ces
utilisateurs qui se connectent peu souvent, il est préférable d’utiliser un
email classique).
Un pense-bête est, dans sa forme, similaire à un
message : mais il ne comporte aucun destinataire. Il est uniquement
accessible à son auteur.
Comme son nom l’indique, le pense-bête est destiné
à noter des éléments que l’on souhaite conserver.
Placer un pense-bête dans le calendrier
L’utilisation la plus pratique du pense-bête
consiste à lui fixer une date. De cette façon, le pense-bête est rappelé à son
auteur jusqu’à cette date (et pendant les 24 heures qui
suivent), et il apparaît dans le calendrier de SPIP.
Note : Comme pour les messages entre utilisateurs, nous attirons votre
attention sur la confidentialité toute relative de ces pense-bête. SPIP n’offre
aucune possibilité aux administrateurs du site de voir vos messages ;
cependant, d’autres outils d’accès direct à la base de données le permettent.
Le calendrier de SPIP présente deux sortes d’informations :
Il s’agit des articles et des brèves publiés - de
cette façon le calendrier permet de retrouver des articles en fonction de leur
date de mise en ligne.
Il s’agit des messages entre utilisateurs et des
pense-bête dotés d’une date de « rendez-vous ». Ce calendrier permet
ainsi de rappeler et de noter des rendez-vous.
Notez que chaque jour du
calendrier est accompagné d’un petit logo bleu : ce logo permet de créer
un pense-bête directement associé à cette date (on pourra régler plus
précisément l’heure d’un rendez-vous grâce à l’interface d’édition de ce
pense-bête).
Chaque utilisateur du site peut configurer
individuellement l’utilisation qu’il souhaite faire de la messagerie interne.
Notez bien : Les administrateurs du site peuvent décider de ne pas utiliser la
messagerie sur leur site.
Si la messagerie interne est disponible pour
l’ensemble du site (option réservée aux administrateurs), chaque utilisateur
peut décider individuellement de ne pas l’utiliser (c’est-à-dire qu’il ne
souhaite tout simplement pas échanger de messages avec d’autres utilisateurs
par ce biais).
Lorsque cette fonction est disponible (choix des
administrateurs), et lorsqu’il utilise la messagerie interne, un rédacteur peut
décider de ne pas participer à la « liste des rédacteurs connectés ».
Cette fonction affiche en permanence la liste des
rédacteurs connectés en direct, facilitant ainsi les dicussions rapides entre
utilisateurs. Certains utilisateurs trouvent que cette fonction est intrusive
et/ou ne veulent pas être « dérangés » lorsqu’ils se connectent. Il
leur suffit alors de désactiver cette option : ils n’apparaîtront plus
dans la liste des rédacteurs connectés, et cette liste ne s’affichera plus sur
leurs pages.
Note : Lorsqu’un administrateur indique qu’il ne souhaite pas apparaître
dans la liste des rédacteurs connectés, la liste est cependant toujours
affichée : il « voit » les autres, mais les autres ne le
« voient » pas.
La page de suivi des forums est un élément
important de votre site, si vous autorisez l’utilisation des forums publics (à
ce sujet, voir la documentation sur la configuration des forums publics).
C’est là, en effet, que se déroule la modération de ces forums.
Les messages ne sont pas ici présentés selon leur
structure hiérarchique (par thread), mais les uns à la suite des autres,
dans l’ordre chronologique inversé (les plus récents en haut). En revanche,
chaque message est accompagné du nom de l’article auquel il se réfère.
La principale possibilité consiste à supprimer
les contributions.
Attention : cette opération est irréversible. Un message
supprimé ne peut plus être remis en ligne. Un message supprimé n’est cependant
pas effacé de la base de données : il apparaît sur cette page encadré de rouge,
avec l’indication de la date d’envoi du message et l’adresse IP de
l’expéditeur.
Si vous avez configuré les forums publics pour
fonctionner avec une modération a priori, les messages en attente sont encadrés
de jaune, et vous proposent deux boutons : Supprimer ce message et Valider
ce message.
Le nom et l’adresse (URL) de votre site sont, en
particulier, utilisés pour la génération du fichier « backend.php3 » qui permet la syndication de votre
site (c’est-à-dire l’affichage sur un site extérieur des 10 derniers articles
publiés sur votre site).
L’adresse de votre site doit être celle du dossier
de la page d’accueil, et non celle du fichier HTML correspondant ; elle
doit donc se terminer par le caractère « / ». Si l’adresse de votre
page d’accueil est :
http://www.monsite.net/index.html
l’URL de votre site doit être indiquée, ici, de la
manière suivante :
http://www.monsite.net/
Les articles sont constitués d’un certain nombre
d’éléments : le titre, le surtitre, le soustitre, le descriptif, le
chapeau, un post-scriptum... Certains sites, cependant, n’ont pas besoin de
tous ces éléments : les rédacteurs n’en ont aucun usage, ou l’interface
graphique du site public ne les intègre pas.
Afin d’alléger l’interface de gestion du site et/ou
d’empêcher purement et simplement les rédacteurs d’utiliser certains éléments
que le webmestre ne souhaite pas intégrer, la page de « Configuration
précise » permet de désactiver totalement l’utilisation de ces éléments.
N. B.
Il est important de comprendre que, par rapport au choix interface
simplifiée / interface complète, qui n’influe que sur l’interface de chaque
utilisateur, le choix des options de la « configuration précise »
influe sur l’ensemble des utilisateurs. Ainsi, si vous décidez de désactiver
l’utilisation du surtitre, plus aucun rédacteur ni aucun administrateur ne
pourra utiliser de surtitre dans ses articles.
L’interface s’adapte à la présence ou l’absence de
ces éléments. Si vous désactivez l’utilisation des mots-clés, le bouton
correspondant dans la barre de navigation supérieure disparaît carrément.
Les administrateurs ont la possibilité de modifier
la date de publication en ligne d’un article (lorsque celui-ci
est déclaré « publié en ligne ».
Comment SPIP doit-il se comporter lorsque l’on fixe
cette date de publication en ligne à une date future ? SPIP doit-il
publier tous les articles, quelque soit la date de publication fixée (au risque
d’un affichage farfelu, un article indiquant « 31 mai 2001 » alors
qu’on n’est encore que le 21 mai), ou doit-il attendre l’échéance fixée
(ici le 31 mai) avant d’afficher cet article sur le site public ?
L’intérêt principal de cette manœuvre est de
pouvoir échelonner à l’avance la publication d’une série d’articles. Cas
pratique : le webmestre part en vacances pendant un mois ; s’il a déjà rédigé quelques articles, il
peut les passer, dans l’espace privé, dans l’état « publié en
ligne », mais leur fixer des dates de publication réparties pendant le
mois de son absence. De cette façon, plutôt que de mettre en ligne un paquet
d’articles d’un seul coup, puis plus aucun pendant un mois, le site publie
régulièrement de « nouveaux » articles, malgré l’absence de leur
auteur.
Un site de science-fiction qui publierait
des chroniques martiennes aurait, pour sa part, intérêt à désactiver
cette fonction, sauf à vouloir attendre l’année 2030. Même remarque pour un
mensuel dont le numéro d’avril est publié le 20 mars.
La façon de gérer les forums publics d’un site
varie énormément d’un webmestre à l’autre, en fonction notamment des besoins
réels du site. Certains webmestres ne veulent pas de forums, d’autres veulent
des forums d’accès libre, d’autres encore préfèrent modérer les forums à
priori, ne publiant les messages qu’une fois qu’ils ont été validés par un
administrateur.
SPIP vous permet de déterminer le fonctionnement de
vos forums publics (les forums internes à la gestion du site sont toujours
gérés comme des forums ouverts à tous les rédacteurs, et modérés a
posteriori).
Lorsque les forums sont désactivés, l’interface
d’envoi de contributions disparaît, et les anciennes contributions ne sont plus
affichées (elles ne sont pas effacées de la base, mais leur affichage est
interrompu). Cette option suspend le fonctionnement des forums, même si
l’affichage des forums est prévu dans la mise en page (squelettes) du site.
Vous pouvez l’utiliser en permanence (le site
n’offre jamais de forums de discussion), ou temporairement (suspendre
l’activité des forums, le temps de calmer un spammeur fou ou de partir en
vacances à la chasse au troll... ou encore lors d’un éventuel transfert de
votre site sur un nouveau serveur).
Lorsque les forums sont modérés a posteriori,
les contributions s’affichent dès qu’elles sont postées par les utilisateurs.
Libre à vous, ensuite, d’utiliser la page de suivi des forums de SPIP pour
modérer plus ou moins sévèrement ces messages. La modération a posteriori
est le mode par défaut
de SPIP.
Dans les forums modérés a priori, les
contributions des utilisateurs sont stockées, mais pas affichées. Les
administrateurs doivent utiliser la page de suivi des forums de SPIP pour
valider (ou refuser) chaque message.
Si les forums sont accessibles sur abonnement,
les utilisateurs désirant participer doivent s’inscrire en fournissant leur
adresse email. Ils reçoivent alors leur identifiant par email. Pour les
rédacteurs qui ont déjà accès au site privé, cet identifiant correspond à leur
login habituel.
Ce mode est un
compromis entre le besoin de responsabilisation (les participants doivent
fournir une adresse email valide), et l’absence de modération a priori (une
fois inscrits, ces utilisateurs peuvent poster leurs contributions
directement).
Ce mode permet de
plus d’exclure les utilisateurs qui abuseraient des forums (black-list).
En effet, lorsque vous supprimez (via la page « Suivre les forums »)
une contribution postée dans le mode « sur abonnement », vous avez
accès à la « fiche » (extrêmement réduite) de l’auteur de cette
contribution. Vous pouvez alors simplement placer cet auteur « à la
poubelle » : son identifiant ne « fonctionnera » plus, et
il ne pourra en obtenir d’autre avec cette adresse email.
Attention : le mode « forum sur abonnement » suppose que votre hébergeur
supporte la fonction d’envoi de mail automatique. Si ce n’est pas le cas,
changez d’hébergeur ;)
Certains sites n’utilisent pas les brèves,
ces courts articles sans auteur. Il se peut notamment que le webmestre du site
ne les ait pas incluses dans l’interface de navigation du site public.
Dans ce cas, vous pouvez purement et simplement
décider de les désactiver. Les rédacteurs ne pourront pas plus en créer.
L’interface s’en trouvera d’autant allégée.
SPIP propose un système de messagerie interne (une
rubrique de la présente documentation est consacrée aux messages entre
utilisateurs, aux pense-bête et au calendrier).
Vous pouvez décider d’utiliser tout ou partie de ce
système.
Une raison pour décider de ne pas utiliser la
messagerie interne est la place que les messages occupent dans la base de
données : ces messages (comme par exemple les messages des forums liés à
vos articles) sont conservés dans la base de données, et ainsi occupent de
l’espace chez votre hébergeur. De plus, les fonctions de messagerie interne
provoquent un travail supplémentaire sur la machine qui vous héberge
(interrogations de la base de données) : sur une machine peu puissante
(et/ou très lente), vous pouvez préférer alléger le travail de la machine en
désactivant la messagerie.
Si vous activez cette fonctionnalité, la liste des
utilisateurs connectés à l’espace privé de votre site apparaît en permanence.
Cela facilite notamment l’échange de messages instantanés entre utilisateurs.
Cette fonction provoque des appels supplémentaires
à la base de données ; sur une machine peu puissante, vous pouvez préférer
la désactiver. Notez également que certains utilisateurs trouvent cette
fonctionnalité intrusive.
Notez bien : Lorsque vous activez pour l’ensemble du site les fonctionnalités
ci-dessus, il reste possible, pour chaque utilisateur, de désactiver ces
fonctions pour lui-même. De cette façon, si un utilisateur trouve inutiles
ou intrusives les fonctionnalités de la messagerie interne, il peut simplement
désactiver cette fonction pour son usage propre.
SPIP intègre un système simple vous permettant de
compter et suivre le nombre de visites pour le site et pour chaque article. Il
permet aussi de connaître quels sont les autres sites qui ont mené des
visiteurs vers votre site et vers chaque article.
SPIP identifie chaque jour les
« visiteurs uniques » de votre site en fonction de leur adresse IP. Le système est rapide et relativement
fiable (il s’agit d’une estimation relativement correcte du nombre de
visiteurs du site, et non des simples « hits » ou des « pages
vues » ; un visiteur qui visite plusieurs fois la même page est bien
compté pour un unique « visiteur unique »).
On nomme « entrée directe » une arrivée
sur le site ou sur la page d’un article depuis un autre site Web qui affiche un
lien hypertexte vers votre propre site (ce site étant lui-même considéré comme
un « referer »).
Pour l’intégralité du site et pour chaque article,
SPIP affiche la liste des principaux « referers » (les pages qui
affichent un lien hypertexte vers votre site), accompagnés du nombre
d’« entrées directes » (le nombre de visiteurs qui ont suivi ce
lien).
Un système complet d’analyse du trafic d’un site
est un logiciel très gourmand en puissance et en mémoire ; le système de
SPIP est donc très simplifié, afin d’être le plus rapide possible, et d’occuper
peu d’espace disque sur le serveur. De plus, le comptage des « visiteurs
uniques » se base sur l’adresse IP des
visiteurs chaque jour, ce qui ne constitue pas la méthode la plus
précise dans l’absolue ; on considère cependant que cela fournit une
information relativement fiable.
Pour une information absolument complète sur le
trafic du site, on pourra donc préférer se tourner vers un système d’analyse
des statistiques plus spécialisé.
Le système de suivi du trafic intégré à SPIP
effectue un calcul du nombre de visiteurs et des referers chaque jour (et non en
temps réel). Certaines informations pourront ainsi vous sembler parfois
incohérentes, car elles ne prennent pas en compte les visites de la journée en
cours ; en cas de doute, la page spécifique affichant les statistiques est
la plus fiable et la plus détaillée. Dans cette logique, la page des
statistiques d’un article n’est disponible qu’après le premier jour de parution
d’un article (les chiffres ne sont pas connus auparavant, car SPIP ne les a pas
encore analysés).
Le comptage du nombre de visiteurs uniques ne
devrait pas occuper beaucoup de place, ni utiliser beaucoup de puissance
machine. Il n’y a donc d’intérêt à le désactiver que pour des serveurs très
lents.
Le système de comptage des referers et des entrées
directes est, lui, nettement plus gourmand. Il est donc désactivé par défaut.
Il est conseillé de ne l’activer que sur les serveurs ne posant aucun problème
de puissance de calcul (les serveurs qui ont déjà du mal à calculer les
articles très longs ne pourront certainement pas, en plus, calculer les
referers).
N.B.
L’espace disque occupé et le temps de calcul utilisé pour le suivi des visites
et des referers augmentent avec le trafic de votre site. Plus un site est
visité, plus les besoins techniques pour effectuer ces tâches augmentent.
Les rédacteurs et les administrateurs ne passent
pas forcément leur vie dans l’espace de gestion de leur site. Afin de faciliter
le travail coopératif et le suivi de la vie du site, le système peut vous
prévenir par email de certains événements du site...
Attention : certains hébergeurs
désactivent la fonction qui permet l’envoi automatique de mails. Si vous êtes
dans cette situation, les options suivantes ne pourront pas être activées.
Afin de permettre aux auteurs de suivre les
discussions provoquées par leurs articles, cette option permet de faire suivre
automatiquement, à l’auteur d’un article, chaque message posté à la suite de
son article.
Si cette option est activée, lorsqu’un message est
posté dans le site public à la suite d’un article, le (ou les) auteur(s) de
l’article reçoivent par mail le texte de la contribution, et le rappel de
l’adresse (URL) de cet article ; d’un clic il(s) peut (peuvent) donc se
rendre sur la page de l’article et éventuellement répondre aux commentaires.
Lorsqu’un article est proposé pour la validation ou
publié, vous pouvez demander à SPIP de le signaler par mail. De cette façon,
les participants à la vie du site sont informés en temps réel des évolutions
importantes du site.
Pour un site coopératif (plusieurs rédacteurs),
nous vous conseillons de créer une liste de diffusion des rédacteurs (la
fonction de liste de diffusion n’est pas fournie par SPIP), vers laquelle
envoyer de tels messages.
Cette fonctionnalité de SPIP permet de créer des
emails du type « Quoi de neuf ? » : si vous l’activez, et
après avoir fixé l’intervalle de temps entre les différentes annonces, un mail
est envoyé régulièrement à l’adresse indiquée, récapitulant les derniers
articles et brèves publiés.
Le fonctionnement est très simple : si vous activez
cette option en indiquant un intervalle de 7 jours, SPIP enverra à l’adresse
désirée, tous les 7 jours, la liste des articles et brèves publiés depuis 7
jours.
Un bouton « Envoyer maintenant » provoque
l’envoi immédiat de ce mail récapitulatif (et relance un nouveau délai avant
l’envoi du prochain mail).
Vous pouvez envoyer ce mail d’annonce des
nouveautés vers l’adresse du webmestre principal (qui fera suivre), ou, si vous
aimez les sites qui se gèrent entièrement tous seuls, directement à la liste de
vos abonnés (la fonction de liste de diffusion n’est pas fournie par SPIP).
SPIP intègre un moteur de recherche. Lorsque celui-ci est activé, un système
d’indexation des articles analyse le contenu de tous les articles. Cette
opération, si elle permet ensuite des recherches extrêmement rapides, nécessite
beaucoup de travail de la part du serveur qui héberge le site. Dans le cas d’un
hébergeur lent, cela peut poser quelques difficultés.
Pour cette raison, vous pouvez activer ou
désactiver le système d’indexation.
Les données générées par le moteur de recherche intégré à
SPIP triplent environ l’espace disque occupé par la base de
données. D’autre part, sur des systèmes lents ou chargés, l’indexation risque
de donner lieu à une légère dégradation des performances, voire des erreurs
d’exécution (cas extrême).
D’une manière générale, si votre site est très
gros, nous vous conseillons de ne pas utiliser le moteur de recherche intégré à
SPIP, et de vous orienter vers des produits spécialisés, tels que ht://Dig.
Notez aussi que le moteur de recherche n’indexe
pas toutes les pages d’un coup. Si vous l’activez alors que votre site contient
déjà un grand nombre d’articles, il faudra attendre que votre site enregistre
un nombre de connexions grosso modo égal au nombre de textes à indexer
pour que le moteur soit à jour.
Chaque utilisateur de SPIP peut modifier son propre
affichage (sans influer, à l’inverse de la page
de « Configuration précise », sur l’affichage pour les autres
utilisateurs.)
De nombreuses fonctions de SPIP sont rarement (ou
pas du tout) utilisées par certains rédacteurs. Passer en mode « interface simplifiée » permet donc d’alléger
l’interface et de faciliter sa compréhension. Dans ce mode, seuls les éléments
réellement indispensables à la gestion du site sont affichés. Par exemple, peu
d’utilisateurs faisant appel à la « date de rédaction antérieure »,
celle-ci n’apparaît donc pas en « affichage simplifié ».
N.B.
Les différences d’affichage sont beaucoup plus évidentes pour les
administrateurs, ceux-ci ayant en effet à leur disposition beaucoup plus de
fonctions que les rédacteurs du site.
Pour que ces modifications soient appliquées, vous
devez accepter l’utilisation des cookies.
Les administrateurs peuvent activer un cookie qui
provoquera l’affichage d’informations supplémentaires lors de la visite du site
public. Ces informations facilitent la gestion du site.
Sur toutes les pages du site public apparaît un
bouton « Recalculer cette page ». SPIP intégrant un système de cache,
certaines modifications peuvent ne pas apparaître immédiatement en ligne. (Les
pages affichées sur le site public ne sont pas directement tirées de la base de
données : elles sont calculées à intervalle régulier et stockées dans le
cache.)
En recalculant une page, l’administrateur
provoque l’affichage de la page en fonction des éléments contenus dans la base
de données, sans attendre la prochaine mise à jour du cache.
Les pages des articles, des rubriques et des brèves
contiennent un bouton « Modifier cet article » (ou
« rubrique »...). Ce bouton mène directement du site public à la page
de l’espace privé correspondant à cet article (ou rubrique...). Ce bouton
facilite donc la correction des erreurs repérées en ligne, ou la mise à jour de tout
élément du site.
Si le système de statistiques intégré à SPIP est
activé, les pages des articles sont complétées de l’information suivante :
nombre de visites (estimation) et nombre de referers différents.
Les referers sont les liens vers cet article précis
depuis l’extérieur du site (c’est-à-dire : lorsqu’un autre site a fait un
lien directement vers cet article, ou lorsque l’adresse de cet article a été
communiqué par email).
Le cookie d’admin permet aussi à SPIP de
reconnaître votre navigateur lorsque vous vous reconnectez : vous n’avez
donc qu’à entrer votre mot de passe pour entrer dans l’espace privé.
(NB : Si la connexion se fait par cookie -
c’est le cas le plus courant -, ce cookie est posé dès votre arrivée dans
l’espace privé.)
Le bouton « Se déconnecter » sert à
annuler votre identification à l’espace privé. Lorsque vous effectuez cette
opération, les informations d’identification que vous aviez indiquées pour
accéder à l’espace privé du site sont « oubliées » par le
système ; SPIP vous propose d’entrer à nouveau ces informations, ou de
revenir à l’espace public du site.
L’intérêt principal de cette fonction est
d’interdire qu’une autre personne, utilisant la même machine que vous, puisse
accéder à l’espace privé du site en exploitant vos propres informations
d’identification.
Dans ce cas, le fait de vous déconnecter avec cette
fonction lorsque vous avez fini de travailler sur l’espace privé du site peut
sembler une opération superflue. L’opération de déconnexion est évidemment
conseillée, mais si vous oubliez de l’effectuer, ça n’est pas très grave.
Dans ce cas, il est vivement conseillé de vous
déconnecter systématiquement en utilisant cette fonction lorsque vous avez
terminé d’utiliser l’ordinateur. Cela interdit totalement à toute personne qui
utiliserait cette machine après vous de pouvoir accéder à l’espace privé en se
faisant passer pour vous.
Certains utilisateurs peuvent avoir besoin de se
connecter à l’espace privé sous plusieurs identités. Dans ce cas, en utilisant
cette fonction de déconnexion, ils peuvent se reconnecter immédiatement au site
avec de nouvelles informations d’identification.
Licence et
conditions d’utilisation
SPIP, Système de publication pour l’internet
Copyright © 2001-2005, Arnaud Martin, Antoine
Pitrou, Philippe Rivière et Emmanuel Saint-James.
Ce programme est un logiciel libre ; vous
pouvez le redistribuer et/ou le modifier conformément aux dispositions de la
Licence Publique Générale GNU, telle que publiée par la Free Software
Foundation ; version 2 de la licence, ou encore (à votre choix) toute
version ultérieure.
Ce programme est distribué dans l’espoir qu’il sera
utile, mais SANS AUCUNE GARANTIE ; sans même la garantie implicite de
COMMERCIALISATION ou D’ADAPTATION A UN OBJET PARTICULIER. Pour plus de détails,
voir la Licence Publique Générale GNU.
Un exemplaire de la Licence Publique Générale GNU
doit être fourni avec ce programme ; si ce n’est pas le cas, écrivez à la
Free Software Foundation Inc., 675 Mass Ave, Cambridge, MA 02139, Etats-Unis.
Ce logiciel est téléchargeable à l’adresse http://www.spip.net/ ;
vous trouverez également, sur ce site, un mode d’emploi
complet et des informations supplémentaires.
En droit français, SPIP est régi par les
dispositions du code de la propriété intellectuelle (CPI). Le noyau de SPIP est
une oeuvre de collaboration entre ses auteurs, désignés ci-dessus (article
L 113-1 du CPI). L’ensemble du projet SPIP forme une oeuvre collective au
sens des articles L 113-2 et L 113-5 du CPI. Les auteurs mettent
l’œuvre à disposition de tous selon les droits et obligations définis par la
licence publique générale GNU.
Les icones de l’interface sont de Diala Aschkar et de Jakub « Jimmac »
Steiner.
Les traductions de l’interface sont le fruit du
travail réalisé par une équipe de traducteurs réunis sur le site
spip.net.
GNU General
Public License :
q version
texte ;
q version HTML ;
q version française, non officielle.
Tout le contenu d’un site
géré sous SPIP est installé dans une base de données mySQL. Pour présenter ces
informations aux visiteurs du site, il faut donc réaliser l’opération qui consiste
à lire les informations, à les organiser et à les mettre en page, afin
d’afficher une page HTML dans le navigateur Web.
Cette opération est
traditionnellement assez pénible :
q il faut connaître la
programmation PHP et MySQL, et écrire des « routines » relativement
complexes ;
q l’intégration de telles
routines dans une mise en page HTML élaborée est assez pénible ;
q il faut prendre en compte
des problèmes de performances : le recours systématique à du code mySQL et
PHP est gourmand en ressources, ralentit la visite et, dans des cas extrêmes,
provoque des plantages du serveur Web.
SPIP propose une solution
complète pour contourner ces difficultés :
q la mise en page du site
est effectuée au moyen de pages HTML nommées squelettes, contenant des
instructions simplifiées permettant d’indiquer où et comment se placent les
informations tirées de la base de données dans la page ;
q un système de cache
permet de stocker chaque page et ainsi d’éviter de provoquer des appels à la
base de données à chaque visite. Non seulement la charge sur le serveur est
réduite, la vitesse très largement accélérée, de plus un site sous SPIP reste
consultable même lorsque la base mySQL est plantée.
L’intérêt (et la limite)
d’un système de publication automatisé, c’est que l’on ne va pas redéfinir une
interface différente en HTML pour chaque page isolée. Par exemple, toutes les
articles bénéficieront de la même interface, simplement le système placera des
informations différentes dans ce graphisme (on verra plus loin que SPIP
autorise cependant une certaine souplesse).
L’avantage de cette
manière de procéder est évident : on définit un format-type (squelette)
pour, par exemple, tous les articles, et le système fabriquera chaque page
individuelle en plaçant automatiquement le titre, le texte, les liens de
navigation... de chaque article.
Pour chaque type de
document, SPIP vous demande deux fichiers : un fichier .php3 et un fichier .html. Lors de l’installation
de SPIP, vous trouverez ainsi les couples : « article.php3 / article.html », « rubrique.php3 /
rubrique.html »,
etc. Vous pouvez naturellement modifier ces couples, et en créer d’autres.
L’appel d’une page
spécifique se fait par l’intermédiaire du fichier .php3. Par exemple, pour
appeler l’article n°5, l’URL correspondante est :
q
http://monsite.net/article.php3?id_article=5
1. Le fichier appelé est
donc article.php3, avec en paramètre id_article=5.
2. Le fichier article.php3 est un fichier
PHP ; sa première tâche consiste à vérifier dans le dossier /CACHE sur votre serveur, s’il
existe déjà un fichier correspondant à cet article.
2bis. Si un tel fichier existe
dans /CACHE, article.php3 vérifie sa date de
création. Si ce fichier est suffisamment récent, il le retourne directement à
l’utilisateur. Le processus de consultation est alors terminé.
3. S’il n’existe pas un tel
fichier dans /CACHE (première visite sur cet article, par exemple), ou si son
âge est trop ancien, SPIP démarre le calcul de cette page.
4. C’est alors la page article.html qui est chargée et
analysée. Cette page contient la mise en page correspondant à ce type de
document. Il s’agit de HTML complété d’indications permettant de placer les
éléments tirés de la base de données. En fonction des éléments requis par article.html, SPIP va chercher les
informations nécessaires tirées de la base de données mySQL et les insérer aux
endroits prévus.
5. Un fichier est ainsi
fabriqué par article.php3, à partir de la description contenue dans article.html, avec les éléments tirés
de la base de données. Ce fichier est alors sauvegardé dans le dossier /CACHE et renvoyé au visiteur.
Lors d’une visite
suivante, si le délai entre les deux visites est suffisamment court, c’est donc
ce nouveau fichier stocké dans /CACHE qui est retourné, sans
avoir à faire un nouveau calcul à partir de la base de données. En cas de
plantage de la base de données, c’est forcément le fichier en cache qui est retourné,
même s’il est « trop âgé ».
Remarque. On voit ici que chaque page du site est mise en cache
individuellement, et chaque recalcul est provoqué par les visites du site. Il
n’y a pas, en particulier, un recalcul de toutes les pages du site d’un seul
coup à échéance régulière (ce genre de « grosse manoeuvre » ayant le
bon goût de surcharger le serveur et de le faire parfois planter).
Le fichier « .php3 » est très simple.
Par exemple, article.php3 contient uniquement :
<?php $fond = "article"; $delais = 24 * 3600; include ("inc-public.php3"); ?> |
Son seul but est donc de
fixer deux variables ($fond et $delais) et d’appeler le fichier
qui déclenche le fonctionnement de SPIP (inc-public.php3).
La variable $fond est le nom du fichier
qui contient la description de la mise en page (le squelette). Ici,
puisque $fond="article", le fichier de
description sera contenu dans article.html1. Notez bien que, dans la variable $fond, on n’indique pas la
terminaison « .html ».
Remarque. L’intérêt de choisir soi-même le nom du fichier de squelette (que l’on
aurait pu déduire automatiquement du nom du fichier .php3) est, si nécessaire, d’utiliser un autre
nom. Cela pour ne pas écraser, éventuellement, des fichiers HTML qui
subsisteraient d’une ancienne version du site que l’on ne souhaite pas
supprimer. S’il existe, d’une ancienne version du site, un fichier article.html que l’on ne souhaite pas effacer, on
utilisera par exemple un fichier squelette pour SPIP intitulé article-nouveau.html, et on fixera dans article.php3 :
$fond="article-nouveau".
La variable $delais est l’âge maximum pour
l’utilisation du fichier stocké en /CACHE. Ce délai est fixé en
secondes. Un délai de 3600 correspond donc à une heure ; un
délai de 24*3600 est donc de 24 heures.
On jouera sur cette
valeur en fonction de la fréquence des ajouts de contenu du site (nouveaux
articles, nouvelles brèves...). Un site actualisé plusieurs fois par jour pourra adopter un
délai d’une heure ; un site publiant quelques articles par semaine pourra
adopter un délai nettement plus long. De même, le contenu des pages est
important : si vous insérez la syndication du contenu de
sites fréquemment mis à jour, vous souhaiterez sans doute adapter votre propre
délais à celui des sites référencés.
Remarque. Certains webmestre succombent à la tentation de fixer des délais
dérisoires (quelques secondes), pour que le site corresponde très
exactement, à chaque instant, aux dernières modifications de la base de
données. Dans ce cas, vous perdez tous les avantages du système de cache :
les visites sont nettement ralenties et, à l’extrême, sur des sites très
fréquentés, vous pouvez provoquer des plantages de la base de données (ou vous
faire virer par votre hébergeur parce que vous monopolisez la puissance de sa
machine...).
Remarque. Une autre raison qui semble pousser les webmestres à fixer des délais
très courts est la présence des forums sur leur site. En effet, pour que les
contributions s’affichent dès qu’elles sont postées, ils pensent nécessaire de
réduire le délais de recalcul. C’est inutile : SPIP gère cet aspect
automatiquement ; lorsqu’une contribution à un forum est postée, la page
correspondante est effacée du cache, et recalculée immédiatement, quel que soit
le délai fixé pour cette page.
Dans SPIP, nous appelons
les fichiers .html les squelettes. Ce sont eux qui
décrivent l’interface graphique de vos pages.
Ces fichiers sont rédigés
directement en HTML, auquel on ajoute des instructions permettant d’indiquer à
SPIP où il devra placer les éléments tirés de la base de données (du
genre : « placer le titre ici », « indiquer à cet endroit
la liste des articles portant sur le même thème »...).
Les instructions de
placement des éléments sont rédigées dans un langage spécifique, qui fait
l’objet du présent manuel d’utilisation. Ce langage constitue par ailleurs la
seule difficulté de SPIP.
« Encore un
langage ? » Hé oui, il va vous falloir apprendre un nouveau langage.
Il n’est cependant pas très compliqué, et il permet de créer des interfaces
complexes très rapidement. Par rapport au couple PHP/mySQL, vous verrez qu’il
vous fait gagner un temps fou (surtout : il est beaucoup plus simple).
C’est un markup language, c’est-à-dire un langage utilisant des balises
similaires à celles du HTML.
Remarque. De la même façon que l’on apprend le HTML en s’inspirant du code
source des sites que l’on visite, vous pouvez vous inspirer des squelettes
utilisés sur d’autres sites fonctionnant sous SPIP. Il suffit d’aller chercher
le fichier « .html » correspondant. Par exemple, vous pouvez voir le squelette des articles d’uZine
(visualisez le code source pour obtenir le texte du squelette).
Tout d’abord, notez qu’il
est possible de créer des couples de fichiers pour le même élément logique
(articles, rubriques, ...). Par exemple, vous pouvez créer des fichiers pour
visiter un même article avec des interfaces différentes : article.php3/html pour le format normal, imprimer.php3/html pour le même article
dans un format adapté à l’impression, article-texte.php3/html pour l’article dans un
format texte (adapté aux mal-voyants par exemple), article-lourd.php/html avec une interface
lourdingue adaptée au haut-débit, etc.
q Une interface différente
selon les rubriques. Vous pouvez, pour un même type de document, créer des
squelettes différents selon les rubriques du site. Il s’agit de créer
simplement de nouveaux fichiers .html en fonction des
rubriques (inutile, ici, de modifier le fichier .php3, on se contente de jouer
sur les noms des fichiers squelettes).
Il suffit de compléter le
nom du fichier squelette de « -numéro » (un tiret
suivi d’un numéro de rubrique). Par exemple, si vous créez un fichier : article-60.html, tous articles contenus
dans la rubrique n°60 utiliseront ce squelette (et non plus le squelette par
défaut article.html). Notez bien : le
numéro indiqué est celui d’une rubrique. Si cette rubrique 60 contient
des sous-rubriques, les articles contenus dans ces sous-rubriques utiliseront
également le nouveau squelette article-60.html.
Remarque. Dans notre exemple, on aura certainement également intérêt à créer un rubrique-60.html, voire un breve-60.html, etc. pour accompagner le changement de mise en page de cette
rubrique.
q Une interface pour une
seule rubrique. (SPIP 1.3) On peut créer
une interface qui s’applique à une rubrique, mais pas à ses sous-rubriques.
Pour cela, il faut créer un fichier : article=60.html, qui s’appliquera
uniquement aux articles de la rubrique 60, mais pas à ses sous-rubriques.
Les fichiers .html sont essentiellement des
fichiers « texte », complétés d’instructions de placement des
éléments de la base de données.
SPIP analyse uniquement
les instructions de placement des éléments de la base de données (codées selon
le langage spécifique de SPIP) ; il se contrefiche de ce qui est placé
dans ce fichier et qui ne correspond pas à ces instructions.
Leur contenu essentiel
est donc du HTML. Vous déterminez la mise en page, la version du HTML désiré,
etc. Vous pouvez évidemment y inclure des feuilles de style (CSS), mais
également du JavaScript, du Flash... en gros : tout ce qu’on place
habituellement dans une page Web.
Mais vous pouvez
également (tout cela n’est jamais que du texte) créer du XML (par exemple,
« backend.php3/html » génère du XML).
Plus original :
toutes les pages retournées au visiteur sont tirées du /CACHE par une page écrite en
PHP. Vous pouvez donc inclure dans vos squelette des instructions en PHP, elles
seront exécutées lors de la visite. Utilisée de manière assez fine, cette
possibilité permet une grande souplesse à SPIP, que vous pouvez ainsi compléter
(par exemple ajouter un compteur, etc.), ou même faire évoluer certains
éléments de mise en page en fonction des informations tirées de la base de
données.
Tout ce qui suit concerne
désormais le langage de description de la mise en page des squelettes
dans SPIP ; si vous avez bien compris l’explication
précédente, vous savez que nous travaillons donc dans les fichiers « .html ».
La présente documentation
est volontairement technique (il s’agit ici de références techniques) ;
vous pouvez préférer commencer par notre guide Pas à
pas, plus didactique, et revenir ensuite ici pour une documentation plus
précise.
La notion de base du
langage de SPIP est la boucle.
La logique de la boucle
Une base de données,
classiquement, c’est une liste d’éléments : ici, une liste des articles,
une liste des rubriques, une liste des auteurs, etc. Pour
« fabriquer » le site, on va donc extraire de cette liste certains de
ses éléments :
q à la base, on veut
extraire un seul élément d’une liste ; par exemple, afficher
l’article désiré ;
q mais il est fréquent
d’extraire plusieurs éléments d’une liste ; par exemple, dans la
page d’une rubrique, on veut afficher tous les articles contenus dans
cette rubrique, ainsi que toutes les sous-rubriques contenues dans cette
rubrique ;
q plus subtil : il
arrive fréquemment qu’il n’y ait pas d’éléments satisfaisants à tel ou tel
endroit ; SPIP doit alors pouvoir gérer l’éventualité de l’absence de ces
éléments ; par exemple, le squelette de l’affichage des rubriques demande
l’affichage de toutes les sous-rubriques contenues dans une rubrique ; que
faire, alors, s’il n’y a pas sous-rubriques dans cette rubrique spécifique ?
Ces trois situations sont
traitées par la notion unique de boucle, qui permet à la fois de gérer
l’affichage d’un seul élément, de plusieurs éléments successifs, ou l’absence
d’éléments.
Le système de boucle
permet, dans un code unique :
q d’indiquer à quel endroit
du code HTML on a besoin de quel type d’élément (à tel endroit on veut
récupérer la liste des articles, à tel endroit on veut inclure la liste des
sous-rubriques...) ;
q de prévoir l’affichage
d’un élément unique ;
q d’indiquer comment est
affichée une liste de plusieurs éléments ;
q de déterminer ce qu’on
affiche lorsqu’il n’y a aucun élément correspondant.
Analogie avec la
programmation en PHP/mySQL
Ceux qui ont déjà
programmé des requêtes mySQL en PHP savent que le traitement se déroule en deux
temps :
q la construction de la
syntaxe de la requête (qui consiste à dire « je veux récupérer la liste
des articles contenus dans telle rubrique... ») ;
q l’analyse et l’affichage
des résultats au travers d’une boucle.
Ce
sont ces deux événements qui sont gérés, dans SPIP, au travers des boucles.
Grâce aux boucles, on a
donc récupéré des éléments uniques ou des listes d’éléments : par exemple
une liste d’articles ou une liste de rubriques...
Cependant, chaque élément
de telles listes est composé de plusieurs éléments précis : par exemple un
article se compose d’un titre, d’un surtitre, d’un sous-titre, d’un texte
d’introduction (chapeau), d’un texte principal, d’un post-scriptum, etc. Il
existe ainsi des balises spécifiques à SPIP, permettant d’indiquer précisément
à quel endroit on affiche des éléments : « placer le titre
ici », « placer le texte ici »...
Voici, au travers d’un
cas classique, le principe de fonctionnement général d’une boucle accompagnée
de ses balises (attention, ça n’est pas du langage SPIP, c’est une description
logique) :
BOUCLE : afficher
la liste des articles de cette rubrique
Fin de la BOUCLE
Cette boucle, analysée
par SPIP, peut donner trois résultats différents.
q Il n’y a aucun article
dans cette rubrique.
Dans ce cas, bien
évidemment, aucun des éléments « afficher ici... (titre,
sous-titre...) » n’est utilisé. En revanche, si on l’a prévu, on peut
afficher un message du genre « Il n’y a pas d’article ».
q Il y a un seul article
dans cette rubrique.
Dans ce cas, très
simplement, la page HTML est construite sur le modèle de la boucle :
q Il y a plusieurs articles
dans cette rubrique.
La description de la mise
en page (« placer ici... ») va alors être calculée successivement
pour chacun des articles. Ce qui donne simplement :
...
La suite de ce guide de
référence se construira donc de la manière suivante :
q syntaxe générale des boucles ;
q syntaxe générale des balises de
SPIP ;
q et, ensuite, une page
spécifique à chaque type de boucles, indiquant quelles balises on peut y
utiliser.
La syntaxe simplifiée d’une boucle est la
suivante :
<BOUCLEn(TYPE){critère1}{critère2}...{critèrex}>
Code HTML + balises SPIP
</BOUCLEn>
On a vu, dans l’explication
sur les boucles et les balises, que le Code HTML + balises SPIP se
répétait autant de fois que la boucle obtenait d’éléments tirés de la base de
données (c’est-à-dire une fois, plusieurs fois, ou zéro fois).
La ligne importante, ici, est :
<BOUCLEn(TYPE){critère1}{critère2}...{critèrex}>
q L’élément BOUCLE est l’ordre indiquant qu’il s’agit d’une boucle
SPIP ; on ne peut donc pas le modifier ; dit autrement, toutes les
boucles de SPIP commencent par l’instruction BOUCLE.
L’élément n est, au choix, le nom de la
boucle, ou le numéro de la boucle. Cet élément est choisi par le webmestre,
pour chaque boucle qu’il utilise. On verra plus loin qu’il est possible (c’est
même tout l’intérêt de la manoeuvre) d’utiliser plusieurs boucles dans un même
squelette : leur donner un nom est donc indispensable pour les identifier.
Si vous décidez de numéroter vos boucles, la
syntaxe devient par exemple (pour la boucle 5) :
<BOUCLE5...>
...
</BOUCLE5>
Si vous décidez de donner un nom à vos boucles
(c’est généralement plus pratique, votre code est plus lisible), il faut
impérativement faire précéder ce nom par le symbole « _ » (que l’on
appelle habituellement underscore). Par exemple :
<BOUCLE_sousrubriques...>
...
</BOUCLE_sousrubriques>
q L’élément (TYPE). Cet élément est primordial : il indique quel
type d’éléments on veut récupérer. La syntaxe est importante : le TYPE est
indiqué entre parenthèses (sans espaces), en majuscules, et ce TYPE doit correspondre obligatoirement à
l’un des types prévus dans SPIP (qu’on trouvera dans la présente
documentation) : ARTICLES, RUBRIQUES, AUTEURS, BREVES, etc.
Pour l’exemple précédent, on aurait donc :
<BOUCLE_sousrubriques(RUBRIQUES)...>
...
</BOUCLE_sousrubriques>
Les critères {critère1}{critère2}...
Ils indiquent à la fois selon quels critères on veut sélectionner les éléments
de la base de données (afficher les sous-rubriques incluses dans cette
rubrique, afficher les autres rubriques installées au même niveau hiérarchique
que la présente rubrique...), et la façon dont on va classer ou sélectionner
les éléments (classer les articles selon leur date, selon leur titre...
afficher uniquement les 3 premiers articles, afficher la moitié des
articles...). Comme on peut combiner les critères, on peut très aisément
fabriquer des requêtes très puissantes, du genre « afficher la liste des 5
articles les plus récents écrits par cet auteur ».
<BOUCLE_meme_auteur(ARTICLES){id_auteur}{par date}{inverse}{0,5}>
...
</BOUCLE_meme_auteur>
Les différents critères et leur syntaxe seront
explicités dans la suite, pour chaque type de boucle (certains critères
fonctionnent pour tous les types de boucles, certains sont spécifiques à
certaines boucles).
Le syntaxe indiquée précédemment peut être
complétée par des éléments conditionnels. En effet, la boucle précédente
affiche successivement les éléments contenus à l’intérieur de la boucle.
SPIP permet de plus d’indiquer ce qu’on affiche avant et après la boucle au cas
où elle contient un ou plusieurs résultats, et ce qu’on affiche s’il n’y a
aucun élément.
Cela donne :
<Bn>
Code HTML optionnel
avant
<BOUCLEn(TYPE){critère1}{critère2}...{critèrex}>
Code HTML + balises
SPIP
</BOUCLEn>
Code HTML optionnel
après
</Bn>
Code HTML
alternatif
<//Bn>
Le code optionnel avant (précédé de <Bn>) n’est affiché que si la boucle contient au moins
une réponse. Il est affiché avant les résultats de la boucle.
Le code optionnel après (terminé par </Bn>) n’est affiché que si la boucle contient au moins
une réponse. Il est affiché après les résultats de la boucle.
Le code alternatif (terminé par <//Bn>) est affiché à la place de la boucle (et donc
également à la place des codes optionnels avant et après) si la boucle n’a
trouvé aucune réponse.
Par exemple, le code :
<B1> Cette rubrique contient les éléments
suivants: <UL> <BOUCLE1(ARTICLES){id_rubrique}> <LI>#TITRE </BOUCLE1> </UL> </B1> Cette rubrique ne contient pas
d'article. <//B1> |
donne les résultats suivants :
Il y a un seul article :
Cette rubrique contient les éléments suivants:
<UL>
<LI> Titre de l'article
</UL>
Il y a plusieurs articles :
Cette rubrique contient les éléments suivants:
<UL>
<LI> Titre de l'article 1
<LI> Titre de l'article 2
...
<LI> Titre du dernier article
</UL>
Il n’y a aucun article :
Cette rubrique ne contient pas d'article.
q Historique : Jusqu’à [SPIP 1.7.2], La manière dont SPIP interprétait les
boucles interdisait de mettre une boucle entre <Bn> et <BOUCLEn>. Par contre, il restait possible de mettre des
boucles supplémentaires dans les parties optionnelles situées après la
définition <BOUCLEn...>. Si vous deviez vraiment installer une boucle dans la partie
optionnelle avant, il fallait passer par une commande <INCLURE()>,
Chaque boucle effectue la sélection des éléments
tirés de la base de données en fonction de critères. Ces critères correspondent
à l’environnement dans lequel se trouve la boucle.
Par exemple : si on prévoit une boucle du
genre « Afficher les articles inclus dans cette rubrique », il faut
savoir de quelle rubrique il s’agit. C’est ce que l’on nomme l’environnement.
L’environnement fourni par l’URL
Lorsque l’on visite une page d’un site SPIP, son
adresse contient généralement une variable. Par exemple :
Ø
rubrique.php3?id_rubrique=15
Cette variable définit donc un premier
environnement : la boucle « Afficher les articles inclus dans cette
rubrique » doit alors être compris comme « Afficher les articles de
la rubrique 15 ».
Clairement, avec le même code de squelette, si on
appelle l’adresse :
Ø
rubrique.php3?id_rubrique=7
l’interprétation de cette boucle deviendra
« Afficher les articles de la rubrique 7 ».
L’environnement fourni par les autres boucles
À l’intérieur d’une boucle, l’environnement est
modifié par chaque élément de la boucle. En plaçant des boucles les unes à
l’intérieur des autres, on hérite ainsi d’environnements imbriqués les uns dans
les autres.
Ainsi, dans la structure suivante :
<BOUCLE_articles:
afficher les articles de cette rubrique>
<LI>Afficher
le titre de l'article
<BOUCLE_auteurs:
afficher les auteurs de cet article>
Nom
de l'auteur
</BOUCLE_auteurs>
</BOUCLE_articles>
On doit comprendre que :
Ø
la première boucle (BOUCLE_articles) affiche les articles
en fonction de la rubrique, selon l’environnement fournit par l’URL (id_rubrique=15
par exemple) ;
Ø
dans cette boucle, on
obtient un ou plusieurs articles ;
Ø
à l’intérieur »
de chacun de ces articles, on a un environnement différent (celui de l’article,
c’est-à-dire, par exemple, id_article=199) ;
Ø
la seconde boucle (BOUCLE_auteurs), qui est installée à l’intérieur de la
première boucle, dépend pour chacune de ses exécutions successives (elle est
exécutée pour chaque article de la première boucle) : « afficher les
auteurs de cet article » devient successivement « afficher les
auteurs du premier article », « du deuxième article » et ainsi
de suite.
On voit que, par l’imbrication de boucles
successives, on obtient différentes boucles, incluses les unes dans les autres,
qui dépendent du résultat des boucles dans lesquelles elles sont situées. Et
finalement, la toute première boucle (celle qui contient toutes les autres)
dépend d’un paramètre fixé dans l’adresse de la page.
Si l’on peut inclure des boucles les unes à
l’intérieur des autres (chaque boucle incluse dépendant alors du résultat de la
boucle à l’intérieur de laquelle elle est installée), on peut tout aussi bien
installer des boucles les unes à la suite des autres ; des boucles
successives n’influent pas les unes sur les autres.
Par exemple, la page d’une rubrique est typiquement
constituée des éléments suivants :
<BOUCLE_rubrique(RUBRIQUES){id_rubrique}>
Titre de la
rubrique
<BOUCLE_articles(ARTICLES){id_rubrique}>
<LI> Titre de
l'article
</BOUCLE_articles>
<BOUCLE_sous_rubriques(RUBRIQUES){id_rubrique}>
<LI> Titre de
la sous-rubrique
</BOUCLE_sous_rubriques>
</BOUCLE_rubrique>
Il n'y a pas de
rubrique à cette adresse.
<//B_rubrique>
La première boucle (BOUCLE_rubrique) dépend de la variable passée dans l’URL de la
page (id_rubrique=15 par exemple).
Les boucles suivantes (BOUCLE_articles et BOUCLE_sous_rubriques) sont installées à l’intérieur de la
première boucle. Ainsi, s’il n’existe pas de rubrique 15, la première boucle ne
donne aucun résultat (le code alternatif « Il n’y a pas de
rubrique... » est affiché), et donc les deux boucles incluses sont
totalement ignorées. Mais s’il existe une rubrique 15, ces deux sous-boucles
seront analysées.
On constate également que ces deux boucles se
présentent l’une après l’autre. Ainsi, elles fonctionnent en fonction de
la première boucle, mais indépendamment l’une de l’autre. S’il n’y a pas
d’articles dans la rubrique 15 (BOUCLE_articles), on affichera tout de même la liste des
sous-rubriques de la rubrique 15 (BOUCLE_sous_rubriques) ; et inversement.
Deux balises permettent de compter les résultats
dans les boucles.
Ø
#TOTAL_BOUCLE retourne le
nombre total de résultats affichés par la boucle. On peut l’utiliser dans la
boucle, dans ses parties optionnelles — avant et après — ou même dans la
partie alternative après la boucle.
Par exemple, pour
afficher le nombre de documents associés à un article :
Attention : si la partie centrale de la boucle
ne retourne rien (c’est le cas avec la boucle <BOUCLE_doc> ci-dessus, qui ne sert qu’à compter le nombre de
résultats), le #TOTAL_BOUCLE ne pourra
être affiché que dans la partie alternative après de la boucle (<//B_doc>).
Ø
#COMPTEUR_BOUCLE retourne le
numéro de l’itération actuelle de la boucle. On peut par exemple l’utiliser
pour numéroter des résultats :
Chaque type
de boucle permet de sélectionner des éléments de la base de données de
SPIP : des articles, des rubriques, des brèves, etc. Chacun de ces
éléments est lui-même constitué d’éléments précis : un titre, une date, un
texte, etc. A l’intérieur d’une boucle, il faut donc pouvoir indiquer à quel
endroit du code HTML on place tel ou tel de ces éléments précis.
Pour cela, on
va utiliser des balises SPIP.
Une balise
SPIP se place à l’intérieur d’une boucle (puisqu’il faut savoir si l’on veut
récupérer un élément d’un article, d’une rubrique, etc.). Le nom de ces balises
est généralement simple, et nous fournirons, pour chaque type de boucle, la
liste complète des balises que l’on peut utiliser.
Une balise
est toujours précédée du signe dièse (#).
Par exemple,
affichons une liste de noms d’articles :
<BOUCLE_articles(ARTICLES){id_rubrique}> <li> #TITRE </BOUCLE_articles> |
Lorsque la
boucle sera exécutée, la balise SPIP #TITRE sera à chaque fois remplacée par le titre de
l’article en question :
Rien de bien
compliqué : on se contente d’indiquer à l’intérieur du code HTML le nom de
l’élément désiré, et celui-ci est remplacé par le contenu tiré de la base de
données.
Dans la
pratique, un élément de contenu est souvent accompagné de code HTML qui ne
doit s’afficher que si cet élément existe, faute de quoi la mise en page
devient imprécise.
Par
exemple : il existe une balise SPIP pour indiquer le surtitre d’un
article. Or de nombreux articles n’ont pas de surtitre.
Complétons
l’exemple précédent :
<BOUCLE_articles(ARTICLES){id_rubrique}> <li> #SURTITRE<br> #TITRE </BOUCLE_articles> |
qui,
classiquement, nous donne une liste d’articles, avec désormais l’indication du
titre et du surtitre de chaque article. Mais que se passe-t-il si l’article n’a
pas de surtitre ? On obtient le code : « <LI><BR> »,
c’est-à-dire une petite puce suivie d’une ligne blanche.
Ce que nous
devons faire : n’afficher le code « <BR> » que
si un surtitre existe pour l’article.
La syntaxe de
la balise SPIP devient alors :
[ texte
optionnel avant (#BALISE) texte optionnel après ]
La balise qui
détermine l’option est placée entre parenthèses, et l’ensemble du texte
conditionnel entre crochets. Le texte optionnel avant et le texte
optionnel après ne s’affichent que s’il existe, dans la base de données, un
élément correspondant à cette balise.
Notre exemple
devient :
<BOUCLE_articles(ARTICLES){id_rubrique}> <li> [(#SURTITRE)<br>] #TITRE </BOUCLE_articles> |
On obtient
alors le résultat recherché : s’il existe un surtitre pour cet article, il
est affiché et suivi du <BR> ; s’il n’existe pas de surtitre, même le
<BR> est occulté.
A partir de [SPIP 1.8] on peut
imbriquer des balises étendues les unes dans les autres. Ainsi, si dans notre
exemple on voulait n’afficher le logo de l’article que si le surtitre est
défini, on pourrait écrire :
<BOUCLE_articles(ARTICLES){id_rubrique}> [<li> [(#LOGO_ARTICLE)<br>] (#SURTITRE)] </BOUCLE_articles> |
Note :On ne peut jamais mettre une boucle dans le code
optionnel d’une balise. Mais si on veut faire n’afficher une boucle qu’en
fonction d’une certaine balise, on peut utiliser <INCLURE()> à l’intérieur d’un code
optionnel.
Quand on
imbrique des boucles les une dans les autres, il peut arriver que deux boucles
aient des balises homonymes.
Par exemple,
dans le code suivant :
<BOUCLE_rubriques(RUBRIQUES){id_rubrique}> <BOUCLE_articles(ARTICLES){id_rubrique}> #TITRE </BOUCLE_articles> </BOUCLE_rubriques> |
la balise #TITRE désigne le titre d’un article. Ainsi, si on
voulait afficher le titre de la rubrique à l’intérieur de la boucle _articles, on ne
pourrait pas utiliser #TITRE.
Depuis [SPIP 1.8], on peut
appeler une balise homonyme d’une boucle englobante en explicitant le nom de la
boucle à laquelle la balise appartient.
On écrira
alors la balise de la façon suivante : #n:BALISE où n est le nom d’une boucle[2]. Par
exemple :
<BOUCLE_rubriques(RUBRIQUES){id_rubrique}> <BOUCLE_articles(ARTICLES){id_rubrique}> #_rubriques:TITRE > #TITRE </BOUCLE_articles> </BOUCLE_rubriques> |
affichera le
titre de la rubrique, puis le titre de l’article.
Il est
fréquent de vouloir modifier un élément tiré de la base de données, soit pour
obtenir un affichage différent (par exemple, afficher le titre entièrement en
majuscules), ou pour récupérer une valeur
découlant de cet élément (par exemple, afficher le jour de la semaine correspondant à une date).
Dans SPIP, on
peut directement appliquer des filtres aux éléments récupérés de la base
de données, en les indiquant dans la syntaxe des balises SPIP, qui
devient :
[ option avant (#BALISE|filtre1|filtre2|...|filtren)
option après ]
La syntaxe
est donc de faire suivre le nom de la balise, entre les parenthèses, par les
filtres successifs, séparés par une barre verticale (nommée habituellement pipe).
Voici
quelques filtres fournis par SPIP :
majuscules, passe le
texte en majuscules (plus puissant que la fonction de PHP correspondante, qui
ne fonctionne pas correctement avec les caractères accentués) ; par
exemple :
[(#TITRE|majuscules)]
justifier, affiche le
texte en justification totale (c’est-à-dire <P
align=justify>) ; par exemple :
[(#TEXTE|justifier)]
La présente
documentation consacre un article aux différents filtres livrés avec SPIP.
SPIP applique
un traitement typographique à tous les textes tirés de la base de données. En
particulier, il place des espaces insécables avant certains symboles
(point-virgule, point d’interrogation, etc.), et analyse des raccourcis de mise
en page.
Dans certains
cas, vous pouvez avoir besoin de court-circuiter ce traitement, afin de
récupérer directement le texte brut tel qu’il est placé dans la base de
données. Pour cela, il suffit d’ajouter une astérisque (*) à la suite de
la balise SPIP. Ce qui donne :
[ option avant (#BALISE*|filtre1|filtre2|...|filtren)
option après ]
Depuis [SPIP 1.8], certaines
balises [3] acceptent
des paramètres. On passera alors une liste de paramètres entre accolade «{» et «}» avec des
virgules « , » pour séparer chaque paramètre.
Par
exemple : #ENV{lang,fr}
Un paramètre
peut être une constante ou une autre balise. Seulement les balises de forme
simple peuvent être passées en paramètres (i.e. pas de code optionnel ou de
filtres). On peut mettre les paramètres entre guillemets simples « '...' » si l’on ne veut pas qu’ils
soient interprétés par SPIP.
Une boucle
d’articles se code en plaçant ARTICLES (avec un « s ») entre
parenthèses :
<BOUCLEn(ARTICLES){critères...}> |
Les éléments
contenus dans une telle boucle sont des articles.
On utilisera
l’un ou autre des critères suivants pour indiquer comment on sélectionne les
éléments.
{tout} les articles sont sélectionnés dans
l’intégralité du site (dans toutes les rubriques). Utile notamment pour
afficher les articles les plus récents (dans l’intégralité du site) sur la page
d’accueil. [En réalité, le critère « tout » n’est pas traité de
manière informatique : c’est un aide-mémoire pour le webmestre ; on
obtient le même résultat en n’indiquant aucun des critères suivants.]
{id_article} retourne l’article dont l’identifiant
est id_article. Comme l’identifiant de chaque article est
unique, ce critère ne retourne qu’une ou zéro réponse.
{id_rubrique} retourne la liste des articles contenus dans
la rubrique id_rubrique.
{id_secteur} retourne les articles dans ce secteur (un
secteur est une rubrique qui ne dépend d’aucune autre rubrique, c’est-à-dire
située à la racine du site).
[SPIP 1.4] {branche} : le critère {branche} retourne
l’ensemble des articles de la rubrique ET de ses sous-rubriques. (C’est une
sorte d’extension du critère {id_secteur}. Toutefois, à l’inverse de {id_secteur=2}, il n’est
pas possible d’appeler directement une branche en faisant par exemple {branche=2} : techniquement parlant, il faut que la
rubrique en question figure dans le contexte courant. Ce critère est à utiliser
avec parcimonie : si votre site est bien structuré, vous ne devriez pas en
avoir besoin, sauf dans des cas très particuliers.)
{id_auteur} retourne les articles correspondant à
cet identifiant d’auteur (utile pour indiquer la liste des articles écrits par
un auteur).
{id_mot} retourne les articles correspondant à cet
identifiant de mot-clé (utile pour indiquer la liste des articles traitant d’un
sujet donné).
[SPIP 1.3] {titre_mot=xxxx}, ou {type_mot=yyyy} retourne les articles liés au mot-clé dont le
nom est « xxxx », ou liés à des mots-clés du groupe de mots-clés
« yyyy ». Attention, on ne peut pas utiliser plusieurs
critères {titre_mot=xxxx} ou {type_mot=yyyy} dans une même boucle.
[SPIP 1.4] {id_groupe=zzzz} permet de sélectionner les articles
liés à un groupe de mots-clés ; principe identique au {type_mot} précédent, mais puisque l’on travaille avec un
identifiant (numéro du groupe), la syntaxe sera plus « propre ».
[Nota : Ce critère n’est pas (en l’état actuel du développement de SPIP)
cumulable avec le précédent {type_mot=yyyy}]
[SPIP 1.7.1] {lang}
sélectionne
les articles de la langue demandée dans l’adresse de la page.
[SPIP 1.7.2] Les
critères {date} (ou {date=...} ou {date==...}) permettent
de sélectionner un article en fonction de la date passée dans l’URL.
{recherche} retourne les articles correspondant aux
mots indiqués dans l’interface de recherche (moteur de recherche incorporé à
SPIP). Voir la page consacrée au moteur de recherche.
Une fois fixé
l’un des critères ci-dessus, on pourra ajouter les critères suivants pour
restreindre le nombre d’éléments affichés.
Les
critères communs à toutes les boucles s’appliquent
évidemment.
{exclus} permet d’exclure du résultat l’article
dans lequel on se trouve déjà (par exemple, lorsque l’on affiche les articles
contenus dans la même rubrique, on ne veut pas afficher un lien vers l’article
dans lequel on se trouver déjà).
Les balises
tirées de la base de données :
Les balises
suivantes correspondent aux éléments directement tirés de la base de données.
Vous pouvez les utiliser également en tant que critère de classement (par
exemple : {par date} ou {par titre}).
#ID_ARTICLE affiche l’identifiant unique de l’article.
Utile pour fabriquer des liens hypertextes non prévus (par exemple vers une
page « Afficher au format impression »).
#SURTITRE retourne le surtitre.
#TITRE retourne le titre de l’article.
#SOUSTITRE retourne le soustitre.
#DESCRIPTIF retourne le descriptif.
#CHAPO retourne le texte d’introduction (chapeau).
#TEXTE retourne le texte principal de l’article.
#PS retourne le post-scriptum.
Les
dates : #DATE, #DATE_REDAC, #DATE_MODIF sont explicitées dans la documentation sur
« La gestion des dates ».
#ID_RUBRIQUE est l’identifiant de la rubrique dont dépend
l’article.
#ID_SECTEUR est l’identifiant du secteur dont dépend
l’article (le secteur étant la rubrique située à la racine du site).
#NOM_SITE et #URL_SITE correspondent aux données du « lien
hypertexte » de l’article (si vous avez activé cette option).
#VISITES est le nombre de visites sur cet article.
#POPULARITE donne le pourcentage de popularité de
cet article, voir la documentation La « popularité » des articles.
Les balises
calculées par SPIP
Les éléments
suivants sont calculés par SPIP. (Ils ne peuvent pas être utilisés comme critère
de classement.)
#NOTES les notes de bas de page (calculées à partir
de l’analyse du texte).
#INTRODUCTION : [SPIP 1.4] si l’article
contient un descriptif, c’est celui-ci qui est utilisé ici ; sinon, SPIP
affiche les 600 premiers caractères du début de l’article (chapeau puis texte).
[SPIP 1.3] Dans les
versions précédentes de SPIP, ce sont systématiquement les premiers caractères
de l’article (chapeau puis texte) qui sont pris en compte (le descriptif n’est
pas utilisé).
#LESAUTEURS les auteurs de cet article. Cela permet
d’éviter de créer une boucle AUTEURS pour obtenir le même résultat.
#PETITION le texte de la pétition si elle existe. Si
elle existe mais que le texte est vide, retourne un espace (une chaîne non vide
sans incidence dans une page html).
#URL_ARTICLE est l’URL de la page de l’article.
#FORMULAIRE_FORUM fabrique l’interface permettant de poster un
message répondant à cet article.
#FORMULAIRE_SIGNATURE fabrique l’interface permettant de signer la
pétition associée à cet article.
#PARAMETRES_FORUM fabrique la liste des variables exploitées
par l’interface du formulaire permettant de répondre à cet article. Par
exemple :
[<A HREF="forum.php3?(#PARAMETRES_FORUM)">Répondre à cet article</A>]
Les logos
#LOGO_ARTICLE le logo de l’article, éventuellement avec la
gestion du survol.
#LOGO_ARTICLE_RUBRIQUE le logo de l’article, éventuellement
remplacé par le logo de la rubrique s’il n’existe pas de logo spécifique à
l’article.
#LOGO_RUBRIQUE le logo de la rubrique de l’article.
Les logos
s’installent de la manière suivante :
[(#LOGO_ARTICLE|alignement|adresse)]
L’alignement
peut être left ou right. L’adresse
est l’URL de destination du lien de ce logo (par exemple #URL_ARTICLE). Si l’on
n’indique pas d’adresse, le bouton n’est pas cliquable.
Si l’on veut
récupérer directement le nom du fichier du logo (alors que les balises
précédentes fabriquent le code HTML complet pour insérer l’image dans la page),
par exemple pour afficher une image en fond de tableau, on utilisera le filtre |fichier comme
suit : [(#LOGO_ARTICLE
|fichier)]
Par ailleurs
deux balises permettent de récupérer un seul des deux logos :
#LOGO_ARTICLE_NORMAL est le logo sans survol ;
#LOGO_ARTICLE_SURVOL est le logo de survol ;
La boucle RUBRIQUES retourne une liste de... rubriques (étonnant,
non ?)
<BOUCLEn(RUBRIQUES){critères...}> |
Remarque.
Une boucle RUBRIQUES n’affiche que des rubriques
« actives », c’est-à-dire contenant des articles publiés, des
documents joints (à partir de [SPIP 1.4]), des
sites publiés - ou des sous-rubriques elles-mêmes actives. De cette façon, on
évite de se trouver dans des rubriques « culs de sac » n’offrant
aucun élément de navigation. À partir de la version SPIP 1.7.1, il est possible de forcer l’affichage des
rubriques vides (voir ci-dessous).
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{id_rubrique} retourne la rubrique dont l’identifiant est id_rubrique. Comme l’identifiant de chaque rubrique est
unique, ce critère retourne une ou zéro réponse.
{id_secteur} retourne les rubriques de ce secteur. (On peut
également, par extension, utiliser le critère {branche} décrit dans La
boucle ARTICLES).
{id_parent} retourne la liste des rubriques contenues dans une
rubrique.
{racine} retourne la liste des secteurs (rigoureusement
identique à {id_parent=0}).
{id_enfant} retourne la rubrique qui contient la rubrique (une
seule réponse ; ou zéro réponse si la présente rubrique est située à la
racine du site).
{meme_parent} retourne la liste des rubriques dépendant de la
même rubrique que la rubrique en cours. Permet d’afficher les rubriques
« sœurs » qui se trouvent au même niveau dans la hiérarchie.
{recherche} retourne les rubriques correspondant aux mots
indiqués dans l’interface de recherche (moteur de recherche incorporé à SPIP).
Voir la page consacrée au moteur de recherche.
À partir de la version SPIP 1.4, les rubriques peuvent être liées à des
mots-clés. Les critères de mots-clés peuvent donc être désormais utilisés dans
les boucles (RUBRIQUES) :
[SPIP 1.7.1] {tout} affiche les rubriques vides en plus des
rubriques contenant des éléments publiés. On réservera ce choix à des besoins
très spécifiques ; en effet, par défaut, SPIP n’affiche pas sur le site
public les rubriques qui ne contiennent aucun élément actif, afin de garantir
que le site ne propose pas de « culs de sac » (navigation vers des
pages ne proposant aucun contenu).
[SPIP 1.7.1] {lang} sélectionne les rubriques de la langue demandée
dans l’adresse de la page.
Une fois fixé l’un des critères ci-dessus, on
pourra ajouter les critères suivants pour restreindre le nombre d’éléments
affichés.
Les critères communs à
toutes les boucles s’appliquent évidemment.
{exclus} permet d’exclure du résultat la rubrique dans
lequel on se trouve déjà (utile avec meme_parent).
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par titre}).
#ID_RUBRIQUE affiche l’identifiant unique de la rubrique.
#TITRE retourne le
titre de la rubrique.
#DESCRIPTIF retourne
le descriptif.
#TEXTE retourne
le texte principal de la rubrique.
#ID_SECTEUR est
l’identifiant du secteur dont dépend la rubrique (le secteur étant la rubrique
située à la racine du site).
#LANG retourne la
langue de cette rubrique.
Les balises calculées par SPIP
Les éléments suivants sont calculés par SPIP. (Ils
ne peuvent pas être utilisés comme critère de classement.)
#NOTES les notes
de bas de page (calculées à partir de l’analyse du texte).
#INTRODUCTION les 600
premiers caractères du texte, les enrichissements typographiques (gras,
italique) sont supprimés.
#URL_RUBRIQUE est l’URL
de la page de la rubrique.
[SPIP 1.4]
#DATE affiche la
date de la dernière publication effectuée dans la rubrique et/ou ses
sous-rubriques (articles, brèves...).
#FORMULAIRE_FORUM fabrique l’interface permettant de poster un
message répondant à cette rubrique.
#PARAMETRES_FORUM fabrique la
liste des variables exploitées par l’interface du formulaire permettant de
répondre à cette rubrique. Par exemple :
[<A
HREF="forum.php3?(#PARAMETRES_FORUM)">Répondre
à cette rubrique</A>]
#FORMULAIRE_SITE [SPIP 1.4] Le #FORMULAIRE_SITE
affiche une interface permettant aux
visiteurs du site de proposer des référencements de sites. Ces sites
apparaîtront comme « proposés » dans l’espace privé, en attendant une
validation par les administrateurs.
Ce formulaire ne s’affiche que si vous avez activé
l’option « Gérer un annuaire de sites » dans la Configuration sur
site dans l’espace privé, et si vous avez réglé « Qui peut proposer
des sites référencés » sur « les visiteurs du site public ».
Le logo
#LOGO_RUBRIQUE le logo de
la rubrique, éventuellement avec la gestion du survol. S’il n’y a pas de logo
pour cette rubrique, SPIP va automatiquement chercher s’il existe un logo pour
la rubrique dont elle dépend, et ainsi de suite de manière récursive.
Le logo s’installe de la manière suivante :
[(#LOGO_RUBRIQUE|alignement|adresse)]
[SPIP 1.4]
#LOGO_RUBRIQUE_NORMAL affiche le
logo « sans survol » ; #LOGO_RUBRIQUE_SURVOL affiche le
logo de survol : ces deux balises permettent par exemple, quand on est
dans une rubrique, de gérer un logo « avec survol » pour les liens
vers les autres rubriques, et de laisser le logo de survol seul dans la
rubrique active.
La boucle BREVES,
comme son nom l’indique, retourne une liste de brèves.
<BOUCLEn(BREVES){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{tout} les brèves sont sélectionnées dans l’intégralité du site.
{id_breve}
retourne la brève dont l’identifiant est id_breve. Comme l’identifiant de chaque brève est unique,
ce critère retourne une ou zéro réponse.
{id_rubrique}
retourne toutes les brèves contenues dans la rubrique en cours.
[SPIP 1.2] {id_mot} retourne
toutes les brèves liées au mot-clé en cours (à l’intérieur d’une boucle de type
MOTS).
[SPIP 1.3]
{titre_mot=xxxx}, ou {type_mot=yyyy}
retourne les brèves liées au mot-clé dont le nom est « xxxx », ou
liées à des mots-clés du groupe de mots-clés « yyyy ». Attention, on
ne peut pas utiliser plusieurs critères {titre_mot=xxxx} ou {type_mot=yyyy} dans une même boucle.
[SPIP 1.4] {id_groupe=zzzz} permet
de sélectionner les brèves liées à un groupe de mots-clés ; principe
identique au {type_mot} précédent, mais puisque l’on travaille avec un identifiant (numéro du
groupe), la syntaxe sera plus « propre ».
{lang} sélectionne les brèves de la langue demandée dans
l’adresse de la page.
{recherche}
retourne les brèves correspondant aux mots indiqués dans l’interface de
recherche (moteur de recherche incorporé à SPIP). Voir la page consacrée au moteur de recherche.
Les critères communs à toutes les boucles
s’appliquent.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par titre}).
#ID_BREVE affiche
l’identifiant unique de la brève.
#TITRE retourne le
titre de la brève.
#DATE retourne la
date de publication de la brève.
#TEXTE retourne le
texte de la brève.
#NOM_SITE le nom du
site indiqué en références.
#URL_SITE l’adresse
(URL) du site indiqué en références.
#ID_RUBRIQUE l’identifiant de la rubrique dont dépend cette brève.
#LANG donne
la langue de cette brève. Par défaut, la langue d’une brève est la langue du
secteur dans lequel elle se trouve.
Les balises calculées par SPIP
Les éléments suivants sont calculés par SPIP. (Ils
ne peuvent pas être utilisés comme critère de classement.)
#NOTES les notes
de bas de page (calculées à partir de l’analyse du texte).
#INTRODUCTION les
600 premiers caractères du texte, les enrichissements typographiques (gras,
italique) sont supprimés.
#URL_BREVE est l’URL
de la page de la brève.
#FORMULAIRE_FORUM fabrique
l’interface permettant de poster un message répondant à cette brève.
#PARAMETRES_FORUM fabrique la
liste des variables exploitées par l’interface du formulaire permettant de
répondre à cette brève. Par exemple :
[<A HREF="forum.php3?(#PARAMETRES_FORUM)">Répondre à cette brève</A>]
Le logo
#LOGO_BREVE le logo de
la brève, éventuellement avec la gestion du survol.
Le logo s’installe de la manière suivante :
#LOGO_BREVE_RUBRIQUE affiche, si
il existe, le logo de la brève ; si ce logo n’a pas été attribué, SPIP
affiche le logo de la rubrique [SPIP 1.4].
La boucle AUTEURS,
comme son nom l’indique, retourne une liste d’auteurs. Si l’on ne précise pas
de critère de sélection, la boucle retournera tous les auteurs ayant un
article publié.
<BOUCLEn(AUTEURS){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{tout} les auteurs sont sélectionnés, qu’ils aient écrit un article ou non.
{id_auteur} retourne
l’auteur dont l’identifiant est id_auteur. Comme l’identifiant de chaque auteur est unique,
ce critère retourne une ou zéro réponse.
{id_article}
retourne tous les auteurs de cet article.
Les critères communs à toutes les boucles
s’appliquent.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par nom}).
#ID_AUTEUR affiche
l’identifiant unique de l’auteur.
#NOM retourne
le nom de l’auteur.
#BIO retourne la
biographie de l’auteur.
#EMAIL retourne
son adresse email.
#NOM_SITE le nom de
son site Web.
#URL_SITE l’adresse
(URL) de son site.
#PGP sa clé
publique pour PGP.
#LANG est la
langue de l’auteur.
#FORMULAIRE_ECRIRE_AUTEUR [SPIP 1.4] affiche un formulaire permettant d’écrire
à l’auteur. Il faut que le serveur hébergeant le site accepte d’envoyer des
mails. Ce système permet de ne pas divulguer l’adresse email de l’auteur.
Les balises calculées par SPIP
#NOTES les notes
de bas de page (calculées à partir de l’analyse du texte).
#URL_AUTEUR l’adresse
de la page auteur.php3?id_auteur=....
Le logo
#LOGO_AUTEUR le logo de
l’auteur, éventuellement avec la gestion du survol.
Le logo s’installe de la manière suivante :
[(#LOGO_AUTEUR|alignement|adresse)]
[SPIP 1.6] : les variantes #LOGO_AUTEUR_NORMAL et #LOGO_AUTEUR_SURVOL permettent
un affichage plus fin de ces deux variantes du logo.
La boucle FORUMS retourne une liste de messages de forums.
<BOUCLEn(FORUMS){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{id_forum} retourne le message dont l’identifiant est id_forum.
Comme l’identifiant de chaque message est unique, ce critère retourne une ou zéro
réponse.
{id_article}
retourne les messages correspondant à cet article.
{id_rubrique}
retourne les messages correspondant à cette rubrique.
{id_breve} retourne
les messages correspondant à cette brève.
{id_syndic}
retourne les messages correspondant à ce site.
{id_thread} introduit dans [SPIP
1.8], retourne les messages appartenant à ce fil de discussion.
Note : id_thread n’est rien d’autre que l’identifiant id_forum du message
qui démarre le fil de discussion (aussi appelé « pied » de la
discussion).
{id_parent}
retourne les messages dépendant d’un autre message. Indispensable pour gérer
des fils de discussion (« threads ») dans les forums.
{id_enfant}
retourne le message dont dépend le message actuel (permet de
« remonter » dans la hiérarchie des fils de discussion). (SPIP 1.3)
{meme_parent} retourne
les autres messages répondant à un même message. (SPIP 1.3)
{plat} :
affiche tous les messages de forum sans prendre en compte leur
hiérarchie : avec ce critère, vous pouvez sélectionner tous les messages
quelle que soit leur position dans un thread (dans la limite des autres
critères, bien sûr). Cela permet par exemple d’afficher les messages par ordre
strictement chronologique par exemple, ou de compter le nombre total de
contributions dans un forum.
N.B. En l’absence de critère {id_forum} ou {id_parent}, lorsque {plat} n’est pas utilisé, seuls les messages n’ayant pas de parent (i.e. à
la racine d’un thread) sont affichés.
{id_secteur}
retourne les messages correspondant au secteur. A priori, peu utile ; mais
cela permet par exemple de faire un grand forum thématique regroupant tous les
messages d’un secteur, quel que soit l’endroit où l’on se trouve.
À partir de la version SPIP 1.4, les messages des forums peuvent être liées
à des mots-clés. Les critères de mots-clés peuvent donc être désormais utilisés
dans les boucles (FORUMS) :
Les critères communs à toutes les boucles
s’appliquent.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par titre}).
#ID_FORUM affiche
l’identifiant unique du message.
#ID_THREAD introduit
dans [SPIP 1.8], affiche l’identifiant du
fil de discussion auquel appartient ce message. (Il s’agit de l’id_forum du pied
de la discussion.)
#URL_FORUM donne,
depuis [SPIP 1.8], l’adresse canonique de la
page qui affiche le message de forum (par exemple, avec les URLs normales de
SPIP, article.php3?id_article=8#forum15 pour le message 15 associé à l’article 8).
#ID_BREVE affiche
l’identifiant de la brève à laquelle ce message est attaché. Attention, cela
n’est pas récursif : un message qui répond à un message attaché à une
brève ne contient pas lui-même le numéro de la brève.
#ID_ARTICLE est l’identifiant de l’article auquel répond le
message.
#ID_RUBRIQUE est
l’identifiant de la rubrique à laquelle le message répond.
#ID_SYNDIC est
l’identifiant du site auquel le message répond.
#DATE est la date
de publication.
#TITRE est le
titre.
#TEXTE est le
texte du message.
#NOM_SITE le nom du
site Web indiqué par l’auteur.
#URL_SITE l’adresse
(URL) de ce site Web.
#NOM est le nom
de l’auteur du message.
#EMAIL est
l’adresse email de l’auteur.
#IP est
l’adresse IP de l’auteur du message au moment de l’envoi de sa contribution.
Les balises calculées par SPIP
#FORMULAIRE_FORUM fabrique
l’interface permettant de poster un message de réponse.
#PARAMETRES_FORUM fabrique la
liste des variables exploitées par l’interface du formulaire permettant de
répondre à ce message. Par exemple :
[<a
href="forum.php3?(#PARAMETRES_FORUM)">Répondre à ce message</a>] |
La boucle MOTS retourne une liste de mots-clés.
<BOUCLEn(MOTS){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{tout} les mots sont sélectionnés dans l’intégralité du site.
{id_mot}
retourne le mot-clé dont l’identifiant est id_mot.
{id_groupe} retourne les mots-clés associés au groupe de mots
dont le numéro est id_groupe [SPIP 1.4].
{id_article}
retourne les mots-clés associés à cet article (c’est l’utilisation la plus
courante de cette boucle).
{id_rubrique} retourne les mots-clés associés à une rubrique [SPIP 1.4].
{id_breve} retourne
les mots associés à une brève [SPIP 1.4].
{id_syndic} retourne les mots associés à un site référencé [SPIP 1.4].
{id_forum} retourne les mots associés à un message de forum [SPIP 1.4] (attention, utilisation très spécifique).
{titre=france} retourne
le mot-clé intitulé france (par
exemple).
{type=pays} retourne les mots-clés du groupe de mots-clés
intitulé pays (par exemple).
Les critères communs à toutes les boucles
s’appliquent.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par titre}).
#ID_MOT affiche
l’identifiant unique du mot.
#TITRE est
le titre (le mot-clé lui-même).
#DESCRIPTIF est le
descriptif du mot.
#TEXTE est le
texte associé au mot.
#TYPE est la
catégorie dans laquelle est installé ce mot-clé (par exemple, le mot-clé
« France » pourrait être associé à la catégorie « Pays »).
#LOGO_MOT [SPIP 1.4] affiche le logo associé au mot-clé.
#URL_MOT donne
l’adresse de ce mot
D’une utilisation marginale, la boucle GROUPES_MOTS [SPIP 1.5] mérite d’être citée ici : elle
permet, si vous avez plusieurs groupes de mots-clés, de sélectionner ces
groupes, et d’organiser par exemple une page récapitulative de tous les
mots-clés classés par groupe, puis par ordre alphabétique à l’intérieur de
chaque groupe, par exemple via le code suivant :
<BOUCLE_groupes(GROUPES_MOTS){par titre}> <h1>#TITRE</H1> <BOUCLE_mots(MOTS){id_groupe}{par titre}{" - "}> #TITRE </BOUCLE_mots> </BOUCLE_groupes> |
Les balises et critères associés à cette boucle sont :
#ID_GROUPE, l’identifiant du groupe de mots [également
disponible dans la boucle(MOTS)] ;
#TITRE, le titre du groupe [à l’intérieur de la boucle(MOTS), vous pouvez utiliser #TYPE pour afficher cette valeur].
La boucle SITES (SPIP 1.3)
retourne une liste de sites référencés. (Si l’on a syndiqué des sites
référencés, cette boucle s’utilise, naturellement, associée à une boucle SYNDIC_ARTICLES qui permet
de récupérer la liste des article de ces sites.)
<BOUCLEn(SITES){critères...}> |
Avant la version 1.3 de SPIP, cette boucle était
nommée SYNDICATION, car seuls des sites syndiqués pouvaient être
référencés. Les deux dénominations sont rigoureusement équivalentes (mais
« SITES » correspond mieux au fait que, depuis la version 1.3, il s’agit
d’un système de référencement de sites, la syndication étant une
option).
<BOUCLEn(SYNDICATION){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{tout}, tous les sites
référencés.
{id_syndic}
retourne le site référencé dont l’identifiant est id_syndic.
{id_rubrique}
retourne les sites référencés dans cette rubrique.
{id_secteur}
retourne les sites référencés dans ce secteur.
[SPIP 1.3]
{id_mot}
retourne toutes les sites liés au mot-clé en cours (à l’intérieur d’une boucle
de type (MOTS)).
[SPIP 1.3]
{titre_mot=xxxx},
ou {type_mot=yyyy}
retourne les sites liés au mot-clé dont le nom est « xxxx », ou liés
à des mots-clés du groupe de mots-clés « yyyy ». Attention, on ne
peut pas utiliser plusieurs critères {titre_mot=xxxx} ou {type_mot=yyyy} dans une même boucle.
[SPIP 1.4]{id_groupe=zzzz} permet
de sélectionner les sites liés à un groupe de mots-clés ; principe
identique au {type_mot} précédent, mais puisque l’on travaille avec un identifiant (numéro du
groupe), la syntaxe sera plus « propre ».
Les critères communs à toutes les boucles s’appliquent.
{moderation=oui} [SPIP 1.4]
affiche les sites syndiqués dont les liens sont bloqués a priori
(« modérés ») ; l’inverse de ce
critère est {moderation!=oui}.
(SPIP 1.3)
{syndication=oui},
{syndication=non} permet de n’afficher que les sites référencés
faisant l’objet d’une syndication, ou les sites non syndiqués.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par nom_site}).
#ID_SYNDIC affiche
l’identifiant unique du site syndiqué.
#NOM_SITE est le nom
du site syndiqué.
#URL_SITE est
l’adresse (URL) du site syndiqué.
#DESCRIPTIF est le
descriptif du site syndiqué.
#ID_RUBRIQUE est le
numéro de la rubrique contenant cette syndication.
#ID_SECTEUR est
le numéro de la rubrique-secteur (à la racine du site) contenant cette
syndication.
Autres balises
#LOGO_SITE affiche
le logo attribué au site.
#URL_SYNDIC affiche
l’adresse (URL) du fichier de syndication de ce site.
La boucle SIGNATURES retourne
une liste de signataires d’une pétition associée à un article.
<BOUCLEn(SIGNATURES){critères...}> |
On utilisera l’un ou autre des critères suivants
pour indiquer comment on sélectionne les éléments.
{tout} toutes les signatures sont sélectionnés dans l’intégralité du site.
{id_signature},
la signature correspondant à l’identifiant courant.
{id_article}
retourne les signatures de la pétition de cet article.
Les critères communs à toutes les boucles
s’appliquent.
Attention.
Dans ce type de boucles, certains critères de classement de la boucle ne sont
pas identiques aux balises SPIP indiquées ci-dessous :
{par
nom_email} classe
les résultats selon le #NOM du
signataire ;
{par
ad_email} classe selon l’#EMAIL du signataire.
Les balises tirées de la base de données
Les balises suivantes correspondent aux éléments
directement tirés de la base de données. Vous pouvez les utiliser également en
tant que critère de classement (généralement : {par titre}).
#ID_SIGNATURE affiche
l’identifiant unique du message.
#ID_ARTICLE est
l’identifiant de l’article pour cette pétition.
#DATE est la date
de publication.
#MESSAGE est le
texte du message.
#NOM est le nom
de l’auteur du message.
#EMAIL est
l’adresse email de l’auteur.
#NOM_SITE le nom du
site Web indiqué par l’auteur.
#URL_SITE l’adresse
(URL) de ce site Web.
La boucle HIERARCHIE retourne la liste des RUBRIQUES qui mènent de la racine du site à la rubrique
ou à l’article en cours.
<BOUCLEn(HIERARCHIE){critères...}> |
On utilisera obligatoirement l’un des deux critères
suivants pour indiquer comment on sélectionne les éléments :
{id_article} retourne la liste des rubriques depuis la racine
jusqu’à la rubrique contenant l’article correspondant à cet identifiant.
{id_rubrique}
retourne la liste des rubriques depuis la racine jusqu’à la rubrique
correspondant à cet identifiant (exclue).
Note : Depuis [SPIP 1.8], {tout} permet
d’obtenir aussi la rubrique correspondant à l’identifiant
spécifié.
Les critères {id_article} ou {id_rubrique} ne peuvent pas être utilisés avec une comparaison. Par exemple, <BOUCLE_hi(HIERARCHIE) {id_article=12}> retournera une erreur.
Attention : cette boucle sera obligatoirement placée à l’intérieur d’une boucle ARTICLES ou RUBRIQUES —
elle ne va pas par elle-même « chercher » l’id_article ou id_rubrique indiquée dans l’URL. (Le même
principe vaut pour les boucles HIERARCHIE des
squelettes inclus par la commande <INCLURE(xxx.php3)>.)
Depuis [SPIP 1.8],
tous les critères de la boucle
RUBRIQUES peuvent être utilisés avec
cette boucle, y compris les critères de tri (il devient possible par exemple de
trier une <BOUCLE_x(HIERARCHIE){id_article}{par hasard}>).
Historique : Jusqu’à la version [SPIP 1.7.2], Les critères communs à
toutes les boucles ne s’appliquent pas tous à ce type de boucle.
Seuls les critères {"inter"} et {a,b} étaient utilisables.
Les éléments obtenus avec une boucle HIERARCHIE sont des
rubriques. On peut donc utiliser toutes les balises proposées pour les boucles RUBRIQUES.
[SPIP 1.4] La boucle DOCUMENTS retourne
une liste de documents multimédia associés (à un article, à une rubrique,
éventuellement les images incluses dans une brève).
<BOUCLEn(DOCUMENTS){critères...}> |
Cette boucle gère non seulement les documents
joints non installés dans le texte d’un article, mais peut aussi accéder aux images
(depuis la version 1.4, les images sont gérées, au niveau du programme, comme
un genre spécifique de documents), aux vignettes de prévisualisation et aux
documents déjà insérés dans le corps de l’article.
Pour mémoire, on utilisera donc le plus fréquemment
(utilisation courante) la boucle DOCUMENTS avec, au
minimum, les critères suivants (explications ci-après) :
Depuis [SPIP 1.6],
l’espace privé de SPIP est accessible en plusieurs langues, au bon vouloir de
chaque rédacteur.
Nous sommes loin d’avoir expérimenté toutes les
possibilités, et tous les besoins liés au multilinguisme. Voici néanmoins quelques
éléments qui vous permettront d’ajuster le fonctionnement de votre site à vos
besoins et à vos projets.
Elle se règle dans la configuration, et détermine
plusieurs caractéristiques de votre site. En particulier, ce sera la langue des
formulaires proposés dans l’espace public de votre site (recherche, écrire à l’auteur, s’inscrire, forums, panneau de
connexion vers l’espace privé, etc.), ainsi que celle utilisée dans les emails
envoyés par SPIP.
Cette « langue principale » définit
également les règles de typographie qui s’appliqueront aux textes - en français
et en espéranto, SPIP ajoute des espaces insécables avant les doubles
ponctuations, etc.
Ce sera aussi la langue dans laquelle seront
accueillis les nouveaux rédacteurs lors de leur première entrée dans l’espace
privé : ils pourront ensuite choisir une autre langue, grâce au menu
dédié.
Enfin, pour le vietnamien (une langue qui comprend
des mots très courts et dans laquelle l’accentuation joue un rôle capital), une
règle de translittération spéciale s’applique pour l’indexation des articles
dans le moteur de recherche. De même pour l’allemand.
SPIP 1.7
introduit une amélioration très demandée : la possibilité de réaliser des
sites en plusieurs langues de façon naturelle. Toute une batterie d’outils est
fournie à cet effet. Dans l’espace privé, on peut notamment changer
individuellement la langue des articles et rubriques du site, et gérer les
traductions des articles. Du côté du site public, diverses sophistications
tendent à minimiser les efforts nécessaires à la réalisation d’un site
multilingue.
Modifier la langue d’un élément spécifique (article
ou rubrique) a les mêmes effets que de modifier la langue du site (comme
expliqué plus haut), mais ces effets se limitent à l’élément modifié :
s’il s’agit d’une rubrique, la modification s’applique à tous les éléments
contenus dans cette rubrique (y compris les sous-rubriques, etc.) ; s’il
s’agit d’un article, il est seul affecté par la modification de la langue.
Ainsi une rubrique en arabe verra ses textes
affichés de droite à gauche, un article en français héritera des règles
typographiques du français, et ainsi de suite. Notons que SPIP n’a aucun
problème à afficher plusieurs langues différentes sur une même page. Par
exemple, un sommaire pourra afficher des articles en allemand et en espéranto,
les dates étant affichées dans les langues correspondantes.
SPIP 1.7
est proposé en arabe (ar), catalan (ca), créole de la Réunion (cpf), danois
(da), chinois(zh) allemand (de), anglais (en), bulgare (bg),espéranto (eo),
espagnol (es), farsi (fa), français (fr), galicien (gl), italien (it),
néerlandais (nl), sept dialectes d’occitan (oc) [10], polonais (pl), portugais (pt), et vietnamien
(vi).
Cette liste n’est pas exhaustive, et d’autres
traductions sont en préparation (basque, norvégien (norsk bokmål)hébreu,
langues slovènes, roumain...) ; elles viendront s’ajouter dans les
versions prochaines de SPIP. Si vous désirez participer aux traductions en
cours, aider à traduire ou relire la documentation, etc., vous êtes les
bienvenus sur la liste
de discussion spip-trad@rezo.net ; nous disposons d’outils permettant
de réaliser rapidement (et éventuellement à plusieurs) les fichiers de
traduction - l’opération complète peut prendre entre 3 jours et une semaine de
travail, en fonction de votre connaissance de SPIP.
Nous avons également besoin de personnes désirant
traduire des articles de la présente documentation ; n’hésitez pas à
visiter l’espace des traducteurs
et à proposer votre contribution.
A bientôt !
Ce tableau rappelle brièvement les méthodes à utiliser pendant l'écriture d'un article pour
ajouter des titres, du texte en gras, en italique, etc..., sans avoir à connaître HTML.
L'utilisation d'HTML reste néanmoins possible, et nécessaire pour les cas plus complexes. (d’après le document de Philippe Allart : http://www.spip.net/IMG/pdf/doc-273.pdf)
Fonctionnalités |
Méthodes |
Commentaires |
Intertitre |
{{{ le
titre }}} |
Le texte entre triples
accolades est affiché comme un titre. |
Changement de paragraphe |
Passer une ligne |
|
Caractères gras |
{{texte en
gras}} |
Le texte entre double
accolades apparaîtra en gras. |
Caractères en italique |
{texte en
italiques} |
Le texte entre simples
accolades est affiché en italique. Astuce: pour avoir du texte
en gras et en italique, mettre trois accolades en insérant une espace
(pour faire 1+2), et en respectant la symétrie. Ex : { {{ texte en gras et en italique
}} } |
Liste à puces |
- premier élément - deuxième élement - etc... |
Le petit trait sera
automatiquement remplacé par une puce, telles qu'elle est définie dans la charte
graphique. |
Trait de séparation |
---- |
Entrer une ligne contenant
quatre petits tirets (au moins). |
Lien hypertexte |
[texte -> URL] |
Mettre le texte et l'URL
entre crochets, séparés par une flèche. Le texte devient une zone
cliquable, et renverra le lecteur sur la page web indiquée par « URL ».
Ex : [le site national de
l'AITF->http://www.aivf.asso.fr] |
Lien hypertexte vers un article |
[texte->n°d'article] |
Pour renvoyer vers un
article du site, il suffit de donner le numéro de l'article. Par exemple, en
supposant que l'article 12 donne la liste des contacts : [nous conctacter->12] |
Lien vers une Rubrique |
[texte->rubxxx] |
Où xxx est le numéro de la
rubrique. Ex : [voyez notre
agenda->rub3] |
Lien vers une brève |
[texte->brxxx] |
Où xxx est le numéro de la
brève. Ex : [Annonce de l'AG->br25] |
Note de bas de page Automatique |
[[texte de la note]] |
Le texte entre doubles
crochets droits apparaîtra en bas de la page, et sera remplacé par un numéro
généré automatiquement. |
Note de bas de page Numérotée |
[[<x>texte de la note]] |
Le texte entre doubles
crochets apparaîtra en bas de page, et sera remplacé par le numéro x
indiqué entre « < > ». |
Faire un tableau Simple |
| aaa | bbb | ccc | | xxx | yyy | zzz | |
Pour faire un tableau
simple il suffit de séparer les colonnes par la barre verticale. Cette méthode autorise
uniquement des cellules d'une seule ligne. Pour faire des tableaux plus
complexes, utiliser le langage HTML. |
Insérer une image |
_
<IMG1|left> _
<CENTER> <IMG1|center> </CENTER> _
<IMG1|right> |
L'image doit avoir été
précédemment téléchargée sur le site par la fonction « télécharger une
nouvelle image » dans la colonne de gauche affichée quand on rédige un
article. Le système indique alors
sous quel nom l'image est disponible, et c'est ce nom qui doit être
utilisé dans les commandes ci-contre. Trois commandes sont
disponibles, selon qu'on veut voir l'image à gauche, au centre ou à
droite. |
Pour plus
d'informations, dans l'espace d'administration de SPIP, cliquer sur [AIDE],
puis « łes articles », et enfin « les
raccourcis
typographiques ».
1. J’ai l’impression que je n’ai pas accès à toutes
les fonctionnalités depuis l’interface. Pourtant, je suis bien administrateur.
Vérifiez que vous êtes bien en interface
complète. C’est affiché dans le tableau de bord en haut de chaque page de
l’espace privé. En interface simplifiée, beaucoup de fonctionnalités
sont masquées afin de rendre l’utilisation plus simple pour les néophytes.
1. Comment supprimer un article ?
On ne peut pas supprimer directement un article,
mais on peut le mettre « à la poubelle » dans le menu de sélection du
statut de l’article. Les articles à la poubelle sont automatiquement effacés au
bout de 24 heures ; cela vous laisse un temps de répit en cas
de mauvaise manipulation.
2. Comment supprimer une brève ?
De la même manière que pour les articles (cf.
ci-dessus), on ne peut supprimer directement une brève ; mais les brèves
refusées sont effacées automatiquement au bout du même délai (24 heures).
3. Comment supprimer une rubrique ?
Pour pouvoir être supprimée, une rubrique doit être
vide (i.e. ne contenir ni article - sauf à la poubelle - ni sous-rubrique). Si
cette condition est vérifiée, la rubrique peut être supprimée dans
« afficher tout le site », en dépliant l’arborescence jusqu’à rendre
visible la rubrique, et en cliquant sur le lien « supprimer » à côté
de celle-ci.
1. Quel est l’intérêt des mots-clés ?
Dans la plupart des sites, la navigation la plus
évidente sera celle imposée par les rubriques : on navigue dans le site en
se repérant dans la classification arborescente mise en place grâce aux
rubriques.
Les mots-clés permettent d’avoir un autre niveau de
navigation, transversal et indépendant. Chaque article peut se voir associer
plusieurs mots-clés. Ainsi dans le site public, on peut afficher la liste des
mots-clés associés à un article ; puis la liste des autres articles
associés à chacun de ces mots. La navigation définie ne décrit pas un arbre,
elle est beaucoup plus lâche, horizontale et permet de se déplacer de proche en
proche.
Pour résumer les différences fonctionnelles :
tout article est dans une rubrique et une
seule ;
les rubriques peuvent être imbriquées à
l’infini (sous-rubriques, etc.) ;
un nombre arbitraire (zéro, un, plusieurs)
de mots-clés peut être associé à chaque article, et de même chaque mot-clé peut
être associé à un nombre arbitraire (zéro, une, plusieurs) d’articles ;
les mots-clés ne peuvent pas être imbriqués
les uns dans les autres.
Pour un exemple opérationnel d’utilisation des
mots-clés, on pourra consulter le site du Monde diplomatique. Les
rubriques y définissent la classification rigide du site (dossiers, cahier,
cartes, archives classées par date...). Les mots-clés permettent de lier les
articles traitant d’un même thème ; ils y sont classés en deux groupes,
« sujets » et « pays ».
2. Je ne comprends pas la différence entre
mots-clés et moteur de recherche. Est-ce que c’est la même chose ?
Les mots-clés et le moteur de recherche sont deux
choses fondamentalement différentes dans SPIP (d’ailleurs, on peut désactiver
le moteur de recherche tout en conservant les mots-clés, et vice-versa).
Avec les mots-clés, ce sont les administrateurs du
site qui définissent les relations entre les articles en liant des mots-clés à
ces articles. Ces mots-clés peuvent ensuite être affichés explicitement dans le
site public, ainsi que la liste des articles associés à chacun d’entre eux ;
sans cet affichage, ils servent à très peu de choses. Cela donne une navigation
de proche en proche, indépendante des rubriques, mais toujours fixée par les
administrateurs.
Le moteur de recherche effectue
des recherches à la demande du visiteur sur n’importe quel terme ou groupe de
termes. Les mots-clés sont certes inclus dans les champs utilisés par la
recherche, mais au même titre que les différents champs des articles (chapo,
texte, etc.). Le moteur de recherche sert ainsi à trouver des informations sans
avoir à passer par les navigations (rubriques, mots-clés) définies par les
administrateurs, qui ne sauraient penser à tous les termes susceptibles d’être
recherchés dans un site.
Pour des informations plus techniques sur le moteur
de recherche, voir l’article y consacré dans le
guide du webmestre SPIP.
3. Les mots-clés peuvent-ils ralentir mon
site ?
Non.
4. Le moteur de recherche peut-il
ralentir mon site ?
C’est possible.
Développé, au départ, pour gérer le site
uZine 2, SPIP est naturellement destiné à gérer un site de type webzine :
à la base, une hiérarchie de rubriques, et des articles installés dans ces
rubriques. Le système gère également les forums et des brèves (par
exemple : revue de presse...).
Voyons plus en détail quels sont ces différents
éléments pris en charge par SPIP, ce qui nous permettra par ailleurs de
clarifier le vocabulaire utilisé par la suite.
Une rubrique est un espace destiné à
accueillir des articles, des brèves... Rien de plus simple : on peut aussi
dire dossier (comme sur votre ordinateur : vos documents sont
rangés dans des dossiers).
Les rubriques peuvent être installées les unes dans
les autres, formant ainsi une hiérarchie. Une rubrique est soit à
l’intérieur d’une autre rubrique, soit elle n’est rattachée à aucune autre et
constitue alors un point d’entrée dans le site (nous parlons alors de tête
de rubrique, ou de secteur). L’emboîtement des rubriques les unes
dans les autres constitue l’ossature de votre site, puisque c’est autour de
cette structure que viendront se greffer les différents éléments de votre site
(articles, brèves, sites syndiqués...)
Ci-dessous, les rubriques 1 et 2 sont des secteurs
(logiquement, ces rubriques définissent les grands « secteurs »
thématiques du site).
Rien de plus simple. Ci-dessus, les rubriques 11,
12 et 13 sont dans la rubrique 1. Les rubriques 221 et 222 sont dans la
rubrique 22, elle-même dans la rubrique 2.
On nomme hiérarchie le chemin logique qui
mène à une rubrique. Ainsi, la hiérarchie de la rubrique 221 est :
rubrique 2, puis rubrique 22.
La gestion de la structure hiérarchique est très
simple : il suffit d’indiquer dans quelle rubrique se situe chacune des
rubriques (cela se règle par un simple menu déroulant).
Le schéma ci-dessus montre comment on déplace une
rubrique : lorsqu’une rubrique est déplacée, toutes les sous-rubriques
qu’elle contient la « suivent » vers son nouvel emplacement. Par
exemple, si nous déplaçons la rubrique 22 à l’intérieur de la rubrique 12, les
rubriques 221 et 222 la suivent (la rubrique 22 aurait tout aussi bien pû être
placée comme tête de rubrique, ou à l’intérieur de la rubrique 23 par exemple.
En revanche, l’interface graphique vous interdit de placer la rubrique 22 à
l’intérieur de la rubrique 221 : sinon on obtiendrait une boucle que le
système ne saurait pas gérer.
Signalons ici la première grosse limitation de
SPIP : SPIP ne gère qu’une seule structure, et c’est la structure
hiérarchique que nous venons de décrire. En particulier :
il
n’est pas possible qu’une rubrique appartienne à deux rubriques différentes
(par exemple, pour un site de cinéma, on ne pourrait pas créer une rubrique
« Orson Welles » qui dépendrait à la fois d’une rubrique
« Réalisateurs » et en même temps d’une rubrique
« Acteurs ») ; cela interdit également de réaliser plusieurs
hiérarchies entrecroisées ;
SPIP
ne gère pas les structures en boucle (ou récursives).
Ces limitations ne sont pas dues à des difficultés
techniques : l’impératif, ici, a été de conserver la simplicité
d’utilisation, et notamment la simplicité de l’interface (créer une interface
pour une telle hiérarchie est aisé, car c’est d’un emploi fréquent ; en
revanche, gérer simultanément plusieurs niveaux de hiérarchie ou des structures
en boucle pose de gros problèmes d’ergonomie).
On peut attacher un forum individuel à chaque
rubrique (voir plus loin).
Terminons cette partie sur les rubriques en expliquant
le principe des rubriques actives. Il arrive fréquemment, lorsqu’on
travaille sur le site, que des rubriques soient vides, ou qu’elles ne
contiennent que des articles qui ne sont pas encore publiés (ils sont en
préparation et donc pas encore diffusés publiquement). Imaginons par exemple
que la rubrique 221 ne contienne aucun article publié ; il est évident
que, si un visiteur du site arrivait sur cette rubrique, il serait dans une
impasse, une rubrique qui ne lui proposerait rigoureusement aucune information.
C’est pourquoi nous parlons de rubriques actives : sur le site
visité par le public, seules les rubriques contenant des articles publiés (ou
des sous-rubriques contenant des articles publiés) sont considérées comme
actives, et donc affichées sur le site public. Cette gestion des rubriques
actives/non actives est automatique ; cependant le webmestre doit être
conscient que toutes les rubriques créées dans la partie privée de SPIP
n’apparaissent pas forcément sur le site public.
Les articles, c’est encore plus simple : un
article se trouve dans une rubrique. Point. Cela se gère très simplement par un
menu déroulant.
Notez qu’une rubrique contenant elle-même des
sous-rubriques peut parfaitement recevoir des articles.
La seule subtilité des articles, c’est leur statut.
Un article peut être :
en
cours de rédaction : son (ou ses) auteur(s) sont en train d’y
travailler, il n’apparait donc pas sur le site public, et son accès est limité
sur le site privé ;
proposé
à la publication : lorsque l’auteur décide que son article est
terminé, il le propose au comité de rédaction (les administrateurs et les
autres rédacteurs) afin de décider s’il doit être publié ou non. L’article
n’est toujours pas visible publiquement, mais tous les participants à l’espace
privé peuvent le voir et son invités à le commenter dans un forum lié à cet
article ;
publié :
l’article est publié sur le site public ;
refusé :
l’article n’est pas publié.
C’est la seule chose à comprendre pour les articles ; pour le
reste, c’est très simple, et tout se gère par une interface Web.
Limitation : un article ne peut se trouver que
dans une seule rubrique à la fois (même problème de conception d’interface que
précédemment).
On peut attacher un forum à chaque article (voir
plus loin).
La description la plus simple pour les brèves,
c’est l’anglicisme news. Ce sont des « articles » de moindre
importante que les véritables articles, et ils ne sont pas signés. En revanche,
il est très simple de leur adjoindre un lien vers un article ou un site Web.
Les brèves sont donc idéales pour constituer une revue de presse en ligne (mais
rien n’interdit de les détourner de leur usage).
Les brèves ont une gestion plus sommaire que les articles :
les
brèves ne peuvent être attachées qu’à des secteurs, des têtes de
chapitre (dans notre exemple, les brèves correspondraient aux rubrique 1 et
2) ;
les
brèves ne sont pas signées, et leur mise en place est très simple :
interface réduite, validation d’un clic.
On peut attacher un forum à chaque brève
(ci-dessous).
Les forums de discussion sont gérés automatiquement
par SPIP. Les forums de discussion sont ici directement liés au contenu
rédactionnel du site : on peut ouvrir un forum indépendant pour chaque
article, pour chaque rubrique et pour chaque brève.
Par défaut, les forums de SPIP sont modérés à
postériori. Cela signifie que chaque message envoyé par un utilisateur du site
est immédiatement publié. En revanche, les administrateurs du site bénéficient
d’une interface qui leur permet de lire les derniers messages postés depuis une
semaine et, le cas échéant, de les supprimer.
L’administrateur du site pourra décider de modifier
le comportement des forums. Il pourra choisir :
l’absence
totale de forums sur son site ;
des
forums modérés à priori : les contributions n’apparaissent qu’une fois
validées par un administrateur ;
des
forums sur abonnement : les participants doivent auparavant s’inscrire et
recevoir (automatiquement) par mail un code leur permettant de participer.
Les messages supprimés ne sont pas détruits de la
base : ils sont mis de côté, et affichent l’adresse IP de
l’expéditeur ainsi que la date et l’heure de l’envoi. En cas de problème
juridique (ou de spammeur fou), c’est un recours indispensable.
Lorsque les forums sont actifs, il est possible,
pour chaque article, d’y interdire localement l’usage d’un forum.
SPIP gère les auteurs du site de deux façons :
à la fois pour la signature des articles (pseudo, gestion des adresses email,
biographie...), et pour la gestion des accès au site privé. Ces deux aspects se
gèrent via la même interface (réservée aux administrateurs).
Les systèmes de publication automatique (SPIP,
phpNuke...) fabriquent automatiquement un fichier standardisé (en XML)
indiquant leurs dernières publications.
SPIP permet d’aller récupérer de tels fichiers sur
le réseau, et de les inclure dans sa propre navigation. On peut ainsi indiquer
sur son propre site des listes des dernières publications d’autres sites.
Lorsque ces sites sont mis à jour, les nouveautés apparaissent automatiquement sur
votre propre site.
Dans SPIP, les sites syndiqués sont indiqués dans
les rubriques (de façon à afficher, à côté de ses propres articles, des
articles tirés d’autres sites ayant une thématique similaire).
Il est possible d’attacher à n’importe quel article
une pétition validée par email. Quelques clics permettent de configurer une
telle pétition (invitant les utilisateurs à « signer » tel texte).
Le processus de signature effectue automatiquement
la validation par email (un mail est envoyé au signataire, lui indiquant une
URL sur laquelle il « validera » sa signature). Ainsi on obtient des
pétitions plus « fiables », puisque chaque signature correspond bien
à une adresse email existante.
Il est possible de créer des mots-clés liés aux
articles. Par exemple, un article pourra être lié aux mots clés
« France », « Politique »... L’usage des mots-clés permet
de proposer une navigation entre différents articles portant sur les mêmes
thèmes ; en particulier, cela permet de contourner la limitation de SPIP
selon laquelle un article ne peut appartenir qu’à une seule rubrique.
SPIP propose aux utilisateurs différentes méthodes
pour suivre l’activité de votre site. Les utilisateurs sont invités à les
utiliser en fonction de leurs besoins et/ou des logiciels dont ils ont
l’habitude.
Le suivi par mail de l’activité
éditoriale est facilité dans la version SPIP 1.7 : il
est possible d’indiquer l’adresse d’une liste de diffusion (mailing-list)
dans la configuration du site, tous les participants étant ainsi
automatiquement informés de son existence.
L’annonce des dernières
nouveautés par syndication XML (fichier backend) est toujours
présente, elle est rappelée aux participants du site. En effet, cette
fonctionnalité conçue initialement pour la syndication entre sites Web peut
être utilisée à partir de logiciels sur les ordinateurs de bureau (news
readers, logiciels de suivis de news).
SPIP 1.7 introduit une nouveauté notablement plus
efficace : la
synchronisation des informations privées et publiques du site dans des
logiciels de calendrier. Il s’agit d’une fonctionnalité nettement plus
puissante que les précédentes, la richesse des informations échangées étant sans
commune mesure.
SPIP ne gère pas lui-même de liste de diffusion (ou
mailing-list) : il n’est pas conçu pour cela et, par ailleurs,
d’excellents logiciels libres gèrent une telle fonction parfaitement ; de
plus, de nombreux sites proposent des mailing-lists faciles à utiliser par des
débutants.
SPIP est donc conçu pour faciliter l’utilisation
d’une liste de diffusion « externe » : vous devez créer une
telle liste de diffusion [11]et indiquer ses coordonnées dans SPIP.
Une fois la liste créée, vous obtenez deux
informations :
q l’adresse email à laquelle il faut envoyer un
message pour qu’il soit expédié à tous les abonnés de la liste,
q l’adresse (URL) Web de la page d’information de
cette liste, où vos visiteurs pourront s’abonner en indiquant leur adresse
email personnelle.
L’adresse de cette mailing-list se règle dans la
page de « Configuration du site », « Interactivité », dans
l’encadré « Envoi de mails automatique » :
Dans
la partie « Suivi de l’activité éditoriale », sélectionnez
« Envoyer les annonces à l’adresse... » et indiquez l’adresse email
de votre liste de diffusion. De cette façon, chaque événement du site (article
proposé, article publié...) sera immédiatement envoyé à cette adresse et
expédié à tous les abonnés de cette liste de diffusion.
Indiquez
dans l’encadré qui suit l’adresse (URL) Web de la page d’information de cette
liste. Cette adresse sera alors signalée à tous les rédacteurs dans la page
« Suivre la vie du site » comme la page où ils pourront s’abonner à
la liste de diffusion.
Si la mailing-list ne propose pas de page Web
d’information, vous pouvez indiquer l’adresse email spécifique permettant de
s’y abonner (souvent dans un format du type : spip@rezo.net?subject=subscribe).
Le format XML/RSS a été conçu pour
« exporter » la liste des derniers articles publiés par un site Web.
De cette façon, différents outils peuvent automatiquement récupérer et afficher
les titres et descriptions des dernières mises à jour d’un site
Web.
L’usage premier de ce format est la syndication de
contenu : un site Web affiche (automatiquement) les dernières mises à jour d’un
autre site Web. On appelle cet usage la syndication de contenu.
SPIP, comme la plupart des outils de gestion de contenu (CMS), permet
d’afficher facilement les informations publiées sur d’autres sites (via la
fonctionnalité « Référencer/syndiquer un site Web »).
Une utilisation plus récente de ce format consiste
à permettre aux usagers de l’internet de s’« abonner » à un site Web
en récupérant automatiquement et régulièrement la liste des dernières mises à
jour du site. En
utilisant un logiciel adapté (un newsreader), l’usager n’a plus besoin
de visiter tous les sites qui l’intéressent pour voir s’il y a des mises à
jour : le logiciel lui indique directement quelles sont les nouveautés des
différents sites auxquels il s’est « abonné ». Cet usage est
particulièrement utile pour suivre l’activité de plusieurs sites en même temps.
SPIP créée automatiquement les différents fichiers
au format XML/RSS permettant à un autre site de syndiquer le contenu de son
propre site, et/ou aux visiteurs du site de s’y « abonner » avec un newsreader.
Ces fichiers se nomment des fichiers « backend ».
L’utilisateur doit installer sur son ordinateur un
logiciel spécifique lui permettant de s’« abonner » à des sites Web.
Il existe deux types de logiciels de ce type :
q les extensions s’ajoutant à un client Web (Mozilla
ou Microsoft Explorer notamment) ; ainsi les fonctions de newsreader
sont directement intégrées à l’interface du client Web habituel, le
fonctionnement en est très simplifié (souvent lié à la gestion des signets - bookmarks
- du navigateur) ;
q les logiciels indépendants, non liés à un
navigateur Web.
La solution la plus simple consiste à installer une
extension de son
navigateur Web. On trouvera plusieurs
extensions de ce type pour l’excellent Mozilla FireFox
(habituellement sous la mention « News », ou « RSS
Reader » ; voir par exemple RSS Reader Panel).
Exemple de lecteur RSS dans
Mozilla FireFox
(GIF, 64.7 ko)
Habituellement, les newsreaders se
présentent ainsi :
en haut à gauche, la liste des sites auxquels on
s’est abonnés (on a indiqué le titre du site et l’adresse du fichier
« backend » correspondant) ;
q pour chacun de ces sites (ici en bas à gauche), la
liste des derniers articles publiés, accompagnés d’un court descriptif ;
q dans la fenêtre principale, l’article lui-même est
affiché lorsqu’on clique sur le titre d’un des articles référencés.
SPIP
1.7 introduit une nouveauté très efficace pour
suivre la vie d’un site Web : la synchronisation des informations privées
et publiques du site dans des logiciels de calendrier.
SPIP permet l’exportation de calendriers au format
iCal. Ce format permet à des logiciels de calendrier d’afficher une liste
d’évéments datés et une liste de tâches, en les récupérant automatiquement et
régulièrement sur le Web.
Cette fonction est particulièrement utile pour
suivre l’activité de plusieurs sites sous SPIP. De cette façon, on peut par
exemple afficher sur la même page d’un logiciel de calendrier :
— la liste des derniers articles publiés sur son propre site,
— la liste des activités éditoriales de plusieurs sites SPIP auxquels on
participe,
— les différents rendez-vous personnels (par exemple les rendez-vous
personnels que l’on note sur son site, les annonces de rencontres de l’espace
privé d’une association, etc.),
— la liste des derniers articles référencés par le Portail des Copains,
— les dates des prochaines vacances scolaires,
— les horaires des prochains matchs de son équipe de
basketball préférée...
Les logiciels de calendrier permettant d’exploiter
de tels fichiers sont actuellement peu nombreux. Sous MacOSX, le logiciel iCal est incontournable et
bénéficie d’une ergonomie très poussée. Pour les autres plateformes, le
principal logiciel actuellement disponible est l’extension Mozilla Calendar qui
s’installe très facilement dans Mozilla
ou FireFox.
Une fois ces logiciels (iCal ou Mozilla Calendar)
installés sur votre ordinateur, il suffit de cliquer sur les liens proposant la
synchronisation de calendrier pour qu’un nouveau calendrier s’affiche dans le
logiciel. La gestion et la navigation de ces calendriers est ensuite très
simple.
L’affichage de plusieurs
calendriers sous Mozilla Calendar
La copie d’écran ci-dessus (cliquez sur la vignette
pour l’agrandir) affiche un exemple sous Mozilla Calendar. On trouve :
en
haut à gauche, la liste des calendriers auxquels l’utilisateur s’est
abonné : à la fois des calendriers de rendez-vous personnels, l’activité
éditoriale de plusieurs sites, les publications publiques d’autres sites... Des
codes couleur permettent de repérer les rendez-vous de chaque calendrier ;
à
gauche, une liste de tâches à effectuer : on trouve notamment l’annonce du
nombre d’articles et de brèves proposés sur différents sites ;
à
droite dans la fenêtre principale, des « rendez-vous » présentés dans
un calendrier graphique (ici en affichange mensuel) : en gris les derniers
articles sélectionnés par rezo.net, en rose des rendez-vous personnels, en
jaune des articles proposés sur un autre site...
en
double-cliquant sur un rendez-vous, on a obtenu sa fiche (fenêtre en bas à
gauche) ; on y trouve le titre, le rappel de la date, ainsi que
l’introduction de l’article (éventuellement, le dernier message d’une
discussion privée ou le texte d’un rendez-vous personnel) et, très utile,
l’adresse Web (URL) où l’on pourra consulter ou modifier cette information.
N.B. La « synchronisation » n’est pas possible dans les deux
sens :
— on peut récupérer les informations d’un calendrier réalisé à
partir d’un site sous SPIP dans son logiciel de calendrier, mis à jour régulièrement,
— on ne peut pas envoyer vers le site SPIP concerné des modifications
réalisées à partir du logiciel de calendrier.
Il existe deux dossiers « sensibles »
dans SPIP, ce sont CACHE
et ecrire/data. Le premier comporte tous les fichiers qu’utilise votre cache pour
accélérer l’affichage des pages, il est donc moyennement sensible, mais le
deuxième stocke les journaux d’activité de spip (les spip.log) et vous permet notamment de créer dump.xml, le fichier de sauvegarde de la base de données.
Or le fichier dump.xml contient des données très sensibles : en
particulier on peut y voir tous les articles, même s’ils ne sont pas
rendus publics sur le site, sans compter qu’il liste également les identifiants
et les mots de passe [12] des rédacteurs et administrateurs du site.
La sécurité de tous ces fichiers est assurée
traditionnellement par des fichiers de configuration d’accès nommés .htaccess. SPIP génère automatiquement ces fichiers pour
empêcher l’accès aux données sensibles stockées sur le serveur : vous
pouvez vérifier que CACHE
et ecrire/data contiennent chacun un fichier .htaccess. Hélas, ces fichiers fonctionnent sous Apache (le serveur Web libre faisant
tourner la majorité des sites Web de l’Internet) mais pas sous IIS (Internet
Information Services, le serveur Web de
Microsoft).
Si votre site SPIP est installé sur un IIS,
n’importe qui peut donc voir les dossiers censément sécurisés via .htaccess :
il faut donc les protéger.
Pour protéger un dossier sur votre site :
allez dans le panneau d’administration de votre serveur Web, faites un clic
droit sur le dossier concerné, cliquez sur « propriétés », et dans
l’onglet « Répertoire » décochez la case « Lire ».
Le panneau de propriétés du
dossier /ecrire/data/
Décocher la case
"Lire" suffit à protéger le dossier exactement comme le fait Apache
avec les fichiers .htaccess
Faites cette opération pour chacun des deux
dossiers CACHE et ecrire/data. Si la manipulation est bonne, vous ne devriez
plus pouvoir accéder aux fichiers de ces dossiers à travers le serveur web.
Testez votre configuration en essayant d’afficher http://www.votresite.com/ecrire/data/spip.log avec votre navigateur. Vous devriez obtenir un
message du type « Accès refusé ».
Comme vous le savez sûrement déjà (sinon, lisez le tutorial ou le manuel de référence), le
système de squelettes est basé sur des fichiers .html contenant la présentation graphique du site. Par
exemple, « article.html » présente les articles, « rubrique.html » présente les rubriques...
Or, nous avons remarqué que fréquemment, les
utilisateurs qui manipulaient leur site public en modifiant ces fichiers .html fournis avec SPIP rencontraient des problèmes lors
des mises à jour, s’ils n’avaient pas pris leurs précautions en
sauvegardant les fichiers modifiés.
En effet, en réinstallant tous les nouveaux
fichiers livrés avec SPIP, ils écrasaient purement et simplement leurs fichiers
modifiés (oubliant de faire une copie de sauvegarde de leurs modifications).
Depuis [SPIP 1.8],
les fichiers .html sont
mieux rangés. Un répertoire dist est destiné aux fichiers
fournis avec la distribution de spip. Ces fichiers contiennent les informations
sur la mise en page par défaut du site et ne devraient pas être modifiés.
Ainsi, un utilisateur qui veut créer sa propre mise
en page, développera ses fichiers article.html, rubrique.html, etc. à la racine du site, ou mieux, dans le
répertoire squelettes dédié. A la prochaine réinstallation de
SPIP, seuls les fichiers dans dist seront écrasés et le webmestre
ne perdra pas ses personnalisations.
Remarque : Les fichiers .php3, pendants des fichiers .html dans un squelette SPIP, doivent toujours rester à la racine du site.
Historique : Depuis [SPIP 1.3] et jusqu’à [SPIP 1.7.2], les fichiers de squelettes fournis dans
la distribution de SPIP étaient nommés « article-dist.html », « rubrique-dist.html », et ainsi de suite. Pour personnaliser ces
fichiers, il suffisait de les renommer d’abord « article.html », « rubrique.html », etc. (sans le -dist).
Voici l’ordre (par priorité décroissante) dans
lequel sont utilisés les fichiers de squelettes selon leur nom :
Remarque : Depuis [SPIP 1.8], SPIP recherche ces fichiers d’abord à la racine du site, puis s’ils n’existent pas, dans le répertoire squelettes. En dernier recours, SPIP prend les fichiers par défaut dans le répertoire dist.
rubrique=10.html : si ce fichier existe, il ne s’applique qu’à
la rubrique numéro 10 ;
si
ce fichier n’existe pas, SPIP regarde si il n’y a pas un fichier rubrique-10.html, si ce fichier existe, la rubrique 10 ainsi que
ses sous-rubriques l’utilisent, c’est donc « récursif » ;
Note : pour que ces fichiers soient pris en compte il faut que le fichier par défaut (rubrique.html) se trouve dans le même répertoire.
si
ce fichier n’existe pas, SPIP regarde s’il n’y a pas un fichier rubrique.html, qui s’applique à toutes les rubriques du site qui
ne sont pas concernées par les fichiers indiqués ci-dessus ;
Historique : Jusqu’à [SPIP 1.7.2], si ce fichier n’existe pas, SPIP utilise
alors le fichier rubrique-dist.html qui est le fichier fourni par défaut. Si vous
voulez modifier ce fichier, renommez-le en rubrique.html, de façon à ne pas écraser vos modifications à la
prochaine mise à jour de SPIP.
Note : L’article sur les
variables de personnalisation explique comment procéder pour ranger tous
les squelettes du site dans un sous-dossier pour des versions antérieures à [SPIP 1.8].
1. Comment fais-je pour modifier la mise en page du
site public ?
La gestion de la mise en page s’appuie sur des
fichiers à l’extension .html appelés squelettes de mise en page. Leur
rôle correspond grosso modo à ce que d’autres logiciels nomment
« modèles » « gabarits », ou en anglais, « templates ».
Chaque fichier est associé à un type de page
différent : ainsi un squelette pour le sommaire, un pour l’affichage
des articles, un pour l’affichage des rubriques, etc. Un squelette contient du
HTML standard définissant l’habillage de la page, dans lequel on insère des
« codes » spécifiques à SPIP afin de définir quelles informations
vont venir « habiter » cet habillage.
Le langage des squelettes de SPIP est très souple
et permet de réaliser des mises en page très variées : un simple coup
d’oeil à uZine, Vacarme, Hacktivist
News Service ainsi que les sites enregistrés par leurs créateurs sur cette page saura vous en
convaincre. Il est donc dommage de garder la mise en page d’origine, même si
celle-ci est très utile pour se mettre le pied à l’étrier.
2. Est-il possible d’écrire ces squelettes
soi-même ?
Oui, c’est un des intérêts majeurs de SPIP. Pour
cela allez voir :
le
tutorial, pour comprendre
les bases de la programmation des squelettes.
le
manuel de référence, qui
liste toutes les possibilités de programmation.
3. Je ne sais pas / ne veux pas apprendre à
programmer. Peut-on utiliser des mises en pages déjà existantes ?
Oui. En dehors de la mise en page par défaut,
d’autres jeux de squelettes sont disponibles sur le site des contributions à SPIP, dans la
rubrique « Squelettes ».
Il suffit en général de récupérer l’archive voulue
(le fichier au format .zip ou .tar.gz, au choix), de la décompresser chez vous,
et de transférer son contenu par FTP à la racine de votre site SPIP. Vous
pouvez faire une sauvegarde de vos fichiers .html actuels, au cas où vous
voulez revenir en arrière.
4. Il n’y a pas beaucoup de jeux de squelettes
disponibles. Pourquoi ?
Ces jeux de squelettes sont alimentés par les
webmestres SPIP qui nous fournissent leurs créations. Nous comptons donc sur
les webmestres pour compléter cette base de squelettes afin d’encourager
l’entraide et la richesse des sites SPIP. (cf. section « Partager »
plus bas dans cette FAQ)
1. Peut-on utiliser un éditeur textuel pour créer
et modifier ses squelettes ?
Oui, comme on le ferait pour du HTML classique.
2. Peut-on utiliser un éditeur graphique (WYSIWYG)
pour créer et modifier ses squelettes ?
Oui, comme on le ferait pour du HTML classique.
Voir cependant la question suivante.
3. J’essaie d’utiliser un éditeur graphique pour
créer mes pages, mais il modifie les tags SPIP. Peut-on résoudre ce
problème ?
Certains éditeurs graphiques
« corrigent » automatiquement les tags qu’ils ne comprennent pas. La
plupart ont toutefois une option permettant de désactiver cette fonctionnalité.
Nous avons consacré un article
spécifique à DreamWeaver, mais la démarche est équivalente pour les autres
éditeurs (GoLive...).
1. J’ai écrit des squelettes pour mon site. Comment
fais-je pour qu’ils soient disponibles à tous ?
N’hésitez pas à vous inscrire sur le site SPIP-Contrib mentionné plus haut, afin
de proposer vos squelettes au téléchargement et que d’autres puissent à leur
tour s’en inspirer pour créer leur propre site.
Contrairement à la plupart des systèmes de publication gratuits, SPIP intègre un système de cache permettant d’accélérer l’affichage du site public. Quelques pistes pour comprendre ce qui influe sur la rapidité de votre site...
Si vous vous inquiétez pour la rapidité de votre
site, il est bon de vous intéresser aux pistes suivantes :
Votre
hébergement Web offre-t-il des performances de bonne qualité ? Evidemment,
c’est subjectif. L’expression « mauvaise qualité » recouvre à coup
sûr la plupart des hébergeurs gratuits (notamment Free). « Bonne
qualité » inclut forcément une machine dédiée (i.e. qui ne sert qu’à votre
site) de fabrication récente, mais aussi des hébergeurs commerciaux pas trop au
rabais. Entre les deux, ça devient très subjectif, en fonction de vos
exigences, de la taille de votre site....
Si
la qualité de votre hébergement laisse à désirer, vous aurez intérêt à ne pas
créer de squelettes trop complexes, i.e. qui demandent à SPIP d’afficher trop
d’informations différentes. Cela vaut pour tout type d’informations : tout
ce qui, dans les squelettes, est susceptible d’être transformé par SPIP en
données affichables. Notez, en particulier, que les squelettes fournis par
défaut démontrent au maximum les possibilités de SPIP, et par conséquent
génèrent des pages assez lourdes.
N’oubliez
pas non plus de régler les délais d’expiration des différents types de pages.
Ainsi, si votre site contient un grand nombre d’articles en archives, vous avez
peut-être intérêt à augmenter la durée d’expiration des articles, sinon les
articles consultés peu souvent ne bénéficieraient pas du système de cache.
La présence du cache change quelque peu la donne en
matière de rapidité. Ce n’est pas tant le nombre de visites de votre site qui
sera le point critique, que la capacité de votre serveur à recalculer les pages
dans le temps imparti au script PHP (en effet, sur la plupart des serveurs, une
limite de durée d’exécution par appel de script est fixée afin d’éviter les
abus et les erreurs de programmation). Par contre, si la page demandée est dans
le cache et n’a pas expiré, la réponse du serveur devrait être
quasi-instantanée (dans le cas contraire, votre serveur est vraiment très
chargé).
La qualité des performances devient ainsi
objectivement mesurable si, lors du recalcul d’une page du site, on obtient un
« timeout », c’est-à-dire que le serveur a dépassé le temps
maximal d’exécution d’un script PHP. Alors il faut soit changer d’hébergement,
soit se résoudre à afficher des pages plus simples : pour cela, modifier
les squelettes pour afficher moins d’informations sur une même page.
Si vous utilisez votre propre machine, il faut vous
assurer qu’elle pourra tenir la charge. N’importe quelle machine pas trop
vieille (moins de trois ans environ) devrait en être capable.
Par contre, l’utilisation de SPIP, par rapport à
d’autres systèmes de publication, permet de mutualiser les ressources
techniques entre plusieurs sites. En effet, tant que le cache est utilisé, la
machine est peu sollicitée, donc plusieurs sites peuvent cohabiter sans
problème (sauf s’il y a vraiment un très grand nombre de visites). Le problème
est donc surtout de prévenir qu’il y ait trop de passagers à bord, c’est-à-dire
qu’un trop grand nombre de « services » hébergés (sites Web, boîtes à
e-mail...) mette en péril la qualité du service.
Si vous voulez contribuer à la programmation de SPIP, l’idée la plus importante à retenir est la suivante : vous arrivez sur un projet qui est déjà fonctionnel. Ce projet est muni d’un ensemble de règles qui, toutes arbitraires qu’elles peuvent paraître, assurent sa cohérence. Ces règles n’ont pas besoin d’être énoncées explicitement pour exister : certaines sont clairement visibles après un examen plus ou moins détaillé du code, et les règles tacites doivent être respectées au même titre que les autres.
Il est formellement conseillé de bien suivre ces
règles. Ce respect n’a pas à être lié ou non à vos goûts personnels : il
permet de garder sa cohérence et son unité au projet, et de le conserver aussi
lisible qu’il l’était auparavant. N’oubliez pas que d’autres personnes que vous
sont amenées à lire, comprendre, voire modifier votre code.
Par exemple, il est évident que les fonctions SPIP
sont écrites sous la forme ma_fonction(). Dans le cadre de ce projet, il serait
donc parfaitement déplacé d’ajouter des fonctions en les écrivant MaFonction() -
même si dans l’absolu cette forme n’est pas plus critiquable que l’autre.
Tout ceci n’empêche pas évidemment de critiquer une
règle et d’en proposer une meilleure, le cas échéant. N’hésitez pas à le
faire ; mais il doit y avoir de véritables raisons à cela.
Enfin, tout règle souffre des exceptions. Mais
celles-ci doivent avoir une véritable justification, non uniquement la paresse
du programmeur ; elles doivent être le plus rares possible. Notamment,
garder à l’esprit que le « provisoire » a souvent tendance à devenir
définitif quand personne n’a envie de le corriger ; or il est logique et
juste que tout programmeur soit responsable de la finition de son propre code,
mais non de celui des autres.
Les règles qui suivent sont communes à un nombre
plus ou moins grand de langages de programmation : au minimum tous les
langages présentant une syntaxe similaire à PHP (c’est-à-dire, outre PHP
lui-même, C, C++, Java....).
Ces règles sont communément acceptées, de façon
aussi naturelle que les règles de présentation et de typographie d’un texte en
langage naturel ; d’ailleurs elles sont fréquemment similaires.
Présentation
Le
code doit être espacé et indenté de manière à mettre en valeur sa structure et
la séparation entre les différents blocs logiques (fonctions notamment).
L’espacement et l’indentation doivent être suffisants pour rendre la structure
compréhensible dès le premier regard ; ils ne doivent pas être excessifs.
On doit y apporter le même soin qu’à la division en paragraphes d’un texte en
langage naturel.
L’indentation
sera faite de préférence avec le caractère de tabulation. Cela permet de
choisir librement la profondeur d’indentation dans les options de son éditeur
de texte, tout en n’imposant pas ce choix aux autres développeurs.
Tout
bloc contenu à l’intérieur d’une paire d’accolades sera indenté d’une et une
seule tabulation. De même, récursivement, pour les sous-blocs : ajout
d’une et une seule tabulation supplémentaire à chaque entrée dans un niveau de
profondeur supplémentaire. Cette règle vaut bien aussi pour la déclaration de
fonctions.
Le
code qui ne fait pas partie d’une fonction ne doit pas être indenté.
L’utilisation
des transitions PHP-HTML (<?php et ?>) doit être minimisée. L’éviter lors qu’il s’agit
d’afficher uniquement de petits morceaux de HTML. Ne pas oublier qu’un petit
morceau de code PHP inséré au milieu d’un océan de HTML est invisible sans un
examen très attentionné.
Typographie
Lors
de l’utilisation de parenthèses ou de crochets, il ne faut pas laisser d’espace
après la parenthèse ouvrante ni avant la parenthèse fermante.
Lors
de l’utilisation d’opérateurs binaires (+,
=, *, AND, ...), il faut laisser un
espace de part et d’autre de l’opérateur. Exception manifeste dans cette phrase,
où les opérateurs sont mentionnés et non utilisés en tant que tels.
Les
opérateurs unaires (!, ...) doivent être collés au paramètre auquel ils
s’appliquent.
Par
convention, lors d’un appel de fonction, il n’y a pas d’espace devant la
parenthèse ouvrante : « f($x) » et non « f ($x) ». A contrario, et pour bien distinguer, on laisse un espace
devant la parenthèse quand il s’agit d’une structure de contrôle intégrée au
langage : « if (!$x) » et non « if(!$x) ».
Les
virgules et points-virgules sont suivis mais non précédés d’un espace.
Réfléchir
Avant de programmer une nouvelle fonctionnalité,
réfléchir...
méthodes
et algorithmes utilisés pour l’implémentation : légèreté, performance,
robustesse (ne pas hésiter à faire quelques calculs grossiers pour valider les
choix) ;
adéquation
au projet : portabilité, sécurité, souplesse ;
implications
sur les autres fonctionnalités : modifications et ajouts à faire sur les
fonctionnalités existantes ;
place
« naturelle » pour cette fonctionnalité dans le projet : en
matière d’interface, de fichiers...
Ne pas négliger la factorisation ou mise en commun
du code (par des fonctions, notamment dans des fichiers à inclure). Eviter par
contre le plus possible les fichiers inclus contenant du code hors fonctions
(sauf lorsque c’est « naturel » et voulu).
Nommer
Variables
et fonctions :
Quel que soit le projet, le nommage doit rester
homogène pour que le code soit facile à lire. Ainsi, sous SPIP, les noms de
variables et de fonctions seront en minuscules ; les noms composés, de la
forme variable_composee.
D’une manière générale, les noms seront ni trop
brefs, ni trop longs ; ile seront suffisamment explicites. Cette règle est
particulièrement importante pour les variables globales, qui peuvent être
partagées entre plusieurs fichiers et de nombreuses fonctions. Pour les variables
locales (i.e. à une fonction), la règle est plus souple. Notamment, on peut
employer des variables d’une lettre, par exemple pour obtenir des expressions
plus compactes. Remarquer que dans tous les langages de programmation, un
certain nombre de lettres sont par tradition associées à certains usages
(exemples : $i, $j pour des compteurs de boucles, $n pour un dénombrement,
$t pour un instant ou une durée en secondes...). Ne pas détourner ces conventions permet à vos
lecteurs d’être plus vite dans le bain.
Fichiers :
Pour des raisons historiques, les fichiers à
inclure dans l’espace public seront appelés inc-fichier.php3.
Dans l’espace privé, ce sera ecrire/inc_fichier.php3 (noter
le tiret bas à la place du tiret normal). Les fichiers de l’espace public
appelés par redirection HTTP depuis l’espace privé sont appelés spip_fichier.php3. Tous les autres fichiers ont un nom qui ne
commence ni par "inc", ni par "spip".
Tester
Une fois une modification importante apportée, il
est bon de la tester soi-même, sans attendre que quelqu’un d’autre le fasse à
sa place. Dans le cadre de SPIP, cela veut dire vérifier que le programme
marche de manière correcte sur un certain nombre d’hébergeurs (par
exemple : Altern, Free...) et de configurations (par exemple :
différentes versions de PHP, de MySQL, restriction plus ou moins grande des
droits d’accès aux répertoires...) ; mais aussi qu’un certain nombre de
situations parmi les plus courantes (dans le cas d’une interface graphique
notamment) sont traitées correctement.
Une fois que vous êtes satisfait de votre
modification du code, il est grand temps d’en parler avec les autres
développeurs de SPIP, et de voir s’il mérite d’être intégré à la distribution
officielle de SPIP... Rendez-vous sur la liste de diffusion spip-dev. A
bientôt !
Au-delà du manuel de référence, vous trouverez ici une description détaillée des fonctions plus avancées à la disposition du webmestre.
SPIP 1.2 Lorsque l’on utilise les raccourcis typographiques dans les articles
dans SPIP (permettant par exemple de mettre en gras, en italique, créer des
liens hypertextes, des intertitres, etc.), SPIP produit les balises HTML
nécessaires à ces effets, chacune de ces balises étant alors associée à une
classe de style CSS.
Par exemple,
Ceci
est un [lien->http://www.uzine.net]
est transformé en code HTML ainsi :
Ceci
est un <a href="http://www.uzine.net" class="spip_out">lien</a>
Le code HTML est ainsi complété par l’appel à un
style CSS intitulé « spip_out ». L’utilisateur peut donc pousser la
personnalisation de son interface graphique en définissant ce style « spip_out »
(couleur différente, fond coloré, police utilisée...).
La plupart des raccourcis typographiques de SPIP
peuvent ainsi être paramétrés avec des feuilles de style ; certains sont
très utiles, d’autres seront réservés aux webmestres qui souhaitent obtenir des
effets exotiques...
Lors de l’installation de SPIP, avec les squelettes
fournis en standard, la définition des feuilles de style se trouve dans le
fichier :
spip_style.css
Vous pouvez modifier ces styles (c’est même
conseillé), mais il est préférable de le faire dans votre propre fichier CSS
afin de pas voir vos ajouts « écrasés » lorsque vous installerez une
nouvelle version de SPIP. Vous pouvez aussi bien sûr intégrer directement des
définitions de styles dans vos squelettes.
Notez bien : la notion de feuille de style, ou cascading style sheets, n’est pas une norme propre à SPIP, il s’agit d’un standard du Web. De très nombreuses documentations existent sur ce sujet par ailleurs ; consulter par exemple la page du W3C à ce sujet.
Afin de suivre la suite de la présente explication,
il est vivement conseillé d’ouvrir le fichier « spip_style.css » dans un éditeur de texte.
Les deux premières définitions permettent de
modifier le comportement de « a » et « a :hover » ;
très classiques, elles concernent tous les liens affichés sur votre page Web
(afficher les liens sans soulignement, et régler le « survol » des
liens hypertextes).
Viennent ensuite trois définitions propres aux
raccourcis typographiques de SPIP : « a.spip_in », « a.spip_out », « a.spip_url ».
a.spip_in concerne les liens à l’intérieur de votre propre
site. Par exemple :
Ceci
est un [lien interne->article1177]
a.spip_out concerne les liens vers l’extérieur de votre site.
Par exemple :
Ceci
est un [lien externe->http://www.uzine.net]
a.spip_url traite les adresses URL transformées en lien
hypertexte. Par exemple :
[->http://www.uzine.net]
(ce raccourci affiche directement l’URL, avec un
lien hypertexte vers cette adresse, ainsi : http://www.uzine.net).
Le principal intérêt de ces trois styles différents
est de permettre de différencier graphiquement les liens internes au site et
les liens vers d’autres sites.
Les intertitres, créés par le raccourci
suivant :
{{{Un
intertitre}}}
peuvent être définis par le style h3.spip. Ce style est sans doute l’un des plus importants,
car il permet de définir la taille, la police et le positionnement des
intertitres dans les articles : vous serez certainement amenés à le
modifier en fonction de vos choix graphiques et typographiques.
Par défaut, la définition en est :
h3.spip { font-family:
Verdana,Arial,Helvetica,sans-serif; font-weight: bold; font-size: 120%; text-align: center; margin-top: 2em; margin-bottom: 1.5em; padding: 0em; } |
Notez en particulier les attributs margin et padding qui permettent d’agir sur l’espacement de
l’intertitre avec les paragraphes précédent et suivant. Sans ce réglage, il y
aurait de fortes chances que l’intertitre serait soit trop « collé »
au reste du texte, soit trop espacé (selon les goûts...).
Les éléments de code, définis par le
raccourci :
<code>Du
code dans le texte</code>
sont paramétrés par le style .spip_code. Peu utilisé, sauf dans le cas d’une documentation
technique (comme celle-ci) où l’on doit citer des morceaux de code
informatique, des noms de fichiers ou de répertoires...
Introduit dans SPIP 1.3,
la balise <cadre>...</cadre> permet de présenter du code source dans un tableau
(élément de formulaire) dans lequel il est facile copier-coller le texte. La
feuille de style associée est : .spip_cadre,
définie ainsi par défaut :
.spip_cadre { width : 100%; background-color:
#FFFFFF; padding: 5px; } |
Les notes de bas de page, définies par le
raccourci :
Le
texte[[Une note de bas de page]]
sont paramétrés par le style p.spip_note.
Souvent inutile, puisque les notes peuvent être modifiées directement en HTML
lors de l’emploi de la balise #NOTES dans vos
squelettes.
Les tableaux sont définis dans SPIP de la façon
suivante :
| {{Nom}} |
{{Date de naissance}} | {{Ville}} |
| Jacques | 5/10/1970 | Paris |
| Claire | 12/2/1975 | Belfort |
| Martin | 1/31/1957 | Nice |
| Marie | 23/12/1948 | Perpignan |
ce qui donne :
Nom |
Date de naissance
|
Ville |
Jacques |
5/10/1970 |
Paris |
Claire |
12/2/1975 |
Belfort |
Martin |
1/31/1957 |
Nice |
Marie |
23/12/1948 |
Perpignan |
Les feuilles de style permettent de paramétrer
finement l’affichage de tels tableaux :
table.spip { } table.spip tr.row_first {
background-color: #FCF4D0; } table.spip
tr.row_odd { background-color: #C0C0C0; } table.spip
tr.row_even { background-color: #F0F0F0; } table.spip td { padding: 1px; text-align: left; vertical-align: center; } |
table.spip permet de modifier le comportement général du
tableau (notamment sa position, à gauche, centré...) ;
table.spip
tr.row_first définit le
comportement de la « première ligne » du tableau (ici en jaune) (pour
que la « première ligne » soit prise en compte, il faut que les
éléments qu’elle contient soient placés en gras) ;
table.spip
tr.row_odd pour les lignes
paires ;
table.spip
re.row_even pour les lignes
impaires ;
table.spip
td permet de modifier le
comportement des cases du tableau.
Un des intérêts repose sur le choix de couleurs
différentes pour « row_odd » et « row_even », permettant de
faire une présentation de couleurs alternées pour les lignes d’un tableau (ici,
gris clair et gris foncé).
Une ligne de séparation horizontale, définie
par :
----
peut être modifiée par : hr.spip.
Le gras et l’italique sont définis par les
raccourcis :
Du
texte {{en gras}}, du texte {en italique}
Ils peuvent être modifiés par les styles : b.spip et i.spip. Styles peu utiles.
Les paragraphes créés par SPIP (en laissant des
lignes vides entre les paragraphes) peuvent être modifiés par le style : p.spip.
A priori, peu utile, car on peut directement
paramétrer le comportement des éléments de texte en HTML.
Dans l’espace public, différents formulaires sont
utilisés pour le moteur de recherche interne,
l’interface de rédaction des messages des forums, les inscriptions à l’espace
privé...
Les feuilles de style sont : .forml, .spip_encadrer, .spip_bouton, .formrecherche.
Par défaut, ils sont définis ainsi :
.forml { width: 100% ; background-color: #FFDDAA;} .spip_encadrer { background-color: #EEEEEE; } .spip_bouton { background-color: #FFCC00;} .formrecherche { width: 100% ; background-color:
#FFDDAA;} |
.forml définit
les « cases » de texte des formulaires ; utile pour définir la
largeur de ces cases, et la couleur du fond ;
.spip_encadrer ; lorsqu’un formulaire propose différentes
« parties », la séparation entre ces différentes parties peut être
paramétrées avec ce style (par exemple, encadrer chaque partie, créer un espace
avant ou après...) ;
.spip_bouton modifie l’aspect du bouton de validation du
formulaire ;
formrecherche modifie l’aspect de la case
« Rechercher » du moteur de recherche.
Vous remarquerez que, par défaut, certaines feuille
de style ne sont pas définies. Elles peuvent être considérées comme très
accessoires (réservées aux webmestres voulant obtenir des effets graphiques
très spécifiques).
En règle générale, les styles qui provoquent des
modifications graphiques spectaculaires sur un site, par ailleurs simples à
paramétrer, sont celles qui concernent :
les
liens de l’ensemble de la page, a et a:hover,
le
comportement des intertitres, h3.spip,
les
formulaires.
[SPIP 1.4] Lorsque l’on a des éléments de texte et des
boucles communs à plusieurs fichiers, on peut vouloir extraire ces éléments des
pages où ils se trouvent, les installer dans un fichier séparé, et les appeler
depuis les autres squelettes. De cette façon, le code commun est regroupé dans
un unique fichier, ce qui facilite notamment les modifications qui concernent
plusieurs squelettes d’un seul coup.
Les habitués de PHP connaissent la fonction include, dont le principe est similaire à ce qui est présenté ici.
Dans SPIP, on peut appeler un squelette depuis un
autre squelette grâce à la balise <INCLURE> (on peut aussi utiliser <INCLUDE>, qui est identique). Sa syntaxe générale
est :
<INCLURE(fichier.php3){paramètre}...>
Le « fichier.php3 » est le nom du fichier
que l’on veut intégrer dans sa page. Par exemple, imaginons que toutes les
pages du site affichent les mêmes informations en bas de page. On regroupe
alors le code HTML de ce « pied de page » dans un fichier « pied.html », squelette lui-même appelé par la page
« pied.php3 » (toujours selon le principe des couples de fichiers destinés à
appeler des squelettes). Il suffit d’ajouter la ligne suivante, à l’endroit
voulu, dans chacun des squelettes voulant afficher le bas de page :
<INCLURE(pied.php3)> |
Certaines inclusions peuvent dépendre du contexte.
Par exemple, imaginons un squelette « hierarchie », qui affiche le chemin menant à une
rubrique depuis la racine du site ; on appelerait cette page par une URL
de la forme : « hierarchie.php3?id_rubrique=xxx ».
Dans les squelettes voulant afficher la hiérarchie
à partir de la rubrique courante, il faut donc indiquer que le paramètre concerné
est {id_rubrique} ; si nécessaire, on aura créé une boucle
permettant de récupérer le numéro de la rubrique concernée, et on installera le
code suivant à l’intérieur de cette boucle :
<INCLURE(hierarchie.php3){id_rubrique}> |
Note : dans ce cas, le squelette hierarchie.html commencera certainement par une boucle rubriques avec le critère {id_rubrique}...
On peut imaginer que, dans certains squelettes, on
désire récupérer non pas la hiérarchie en fonction d’une rubrique
« variable » (au gré du contexte, par exemple le paramètre passé dans
l’URL), mais en fonction d’une rubrique dont on connaît à l’avance le numéro.
Pour cela, on peut fixer la valeur du paramètre ainsi :
<INCLURE(hierarchie.php3){id_rubrique=5}> |
N.B.
Il est possible d’indiquer plusieurs paramètres dans la balise <INCLURE> ; cependant ce cas est très rare en pratique.
Evitez d’ajouter des paramètres inutiles, qui rendront le cache moins efficace
et votre site plus lent.
N.B.
Le fichier inclus étant lui-même un squelette, il disposera donc de sa propre
valeur de $delais [13]. Cela peut s’avérer pratique pour séparer des
éléments lourds du site, que l’on recalculera peu souvent, et quelques éléments
dynamiques nécessitant une mise à jour fréquente
(par exemple, syndication).
Si le multilingüisme de SPIP est
activé depuis SPIP 1.7.1 il est possible de définir la langue de
l’environnement d’un squelette inclus en utilisant le paramètre {lang}.
S’il
n’y a pas de paramètre de langue utilisé, c’est-à-dire sous la forme <INCLURE(pied.php3)>, le
squelette inclus est appelé en utilisant la langue par défaut du site,
<INCLURE(pied.php3){lang=es}> appelle le squelette en espagnol. Bien sûr, vous
pouvez remplacer « es » par le code ISO de la langue souhaitée :
en pour l’anglais, fr pour le français, vi pour le
vietnamien, etc. (voir Internationaliser
les squelettes),
et
<INCLURE(pied.php3){lang}> appelle le squelette dans la langue courante du
contexte d’inclusion.
Il convient de noter que cela rend possible
d’utiliser des codes de fichiers de langue dans les squelettes inclus (voir Internationaliser les squelettes).
Les squelettes inclus supportent les mêmes
mécanismes de sélection par langue que les squelettes de « premier
niveau ». En d’autres termes les squelettes inclus (ici pied.html) peuvent être déterminés par rapport à une
certaine langue (pied.es.html, par exemple) de la même manière que tout autre
squelette. Encore une fois, voir « Internationaliser les squelettes »
pour plus de détails.
La modification la plus importante qu’apporte SPIP 1.7 est sa gestion « naturelle » des sites multilingues. La totalité de cet article de documentation concerne SPIP 1.7.
Il n’est pas question dans cet article de rédiger
un tutoriel complet sur les sites multilingues : d’une part, il y a
certainement plusieurs « visions » de ce qu’on appelle
« multilinguisme » ; d’autre part, nous manquons toujours de
recul pour pouvoir définir « la meilleure méthode ».
Vous trouverez donc ci-dessous une revue des
différents outils que SPIP propose pour gérer des sites multilingues ; à
vous de les utiliser, et discutons-en dans les espaces prévus à cet effet (wiki,
listes de discussion, etc.)
Mais avant de lire, oubliez un peu votre projet du
jour, et pensez aux situations suivantes :
un
site de poésies, classées par thèmes (rubriques) ;
un
site de documentation pour, par exemple, un logiciel comme SPIP ;
un
site institutionnel en 25 langues ;
un
site corporate bilingue ;
le
site d’une association bulgare avec quelques pages en anglais.
Le site de poésie choisira plutôt ses langues article
par article ; la documentation de SPIP, pour sa part, les ventile par
« secteurs » (rubriques de premier niveau), et affiche les
traductions disponibles pour chaque article, quand ces traductions sont
disponibles. Le site institutionnel en 25 langues ne pourra sans doute pas
fournir les 25 traductions en même temps, mais cherchera tout de même à
conserver des arborescences parallèles ; le site corporate bilingue aura
obligatoirement une traduction en face de chacun des articles, et une
arborescence de rubriques en deux parties, la partie anglaise étant
« clonée » sur la partie en auvergnat ; l’association bulgare
affectera l’anglais à un secteur particulier de son site, le reste des secteurs
étant tous en bulgare (par défaut).
Pour pouvoir autoriser ces situations différentes,
et d’autres encore, le modèle mis en place dans SPIP consiste à déterminer une
langue pour chaque article, chaque rubrique et chaque brève. Dans l’espace
public comme dans l’espace privé, cette langue détermine le mode de
correction typographique qui est appliqué aux textes ; dans l’espace
public cela détermine également la langue des élements insérés par SPIP autour
de ces « objets » : dates et formulaires principalement.
Pour créer un site multilingue avec SPIP, il faut
d’abord configurer le site en conséquence : dans la configuration du site,
à la section « langues » bien entendu. Là vous pourrez activer la
gestion du multilingue, et choisir les langues que vous utiliserez sur votre
site.
Pour gérer plus facilement le site, on peut choisir
dans la configuration du site avec quelle précision s’effectuera le réglage des
langues, ce qui permet de masquer l’interface là où elle n’est pas nécessaire
et de limiter les risques d’erreurs [14]. SPIP propose trois niveaux d’interface différents
pour choisir les langues affectées aux articles (et brèves, etc.) ; par
ordre croissant de complexité :
Par
secteur (rubrique de premier niveau) : à chaque rubrique de la
racine du site correspond une langue modifiable par les administrateurs, qui
concerne toutes ses sous-rubriques ainsi que les articles et les brèves y
publiés ; ce réglage devrait satisfaire les besoins de la plupart
des sites multilingues tout en conservant une structure et une interface
simples.
Par
rubrique : de manière plus fine, avec ce réglage, on peut changer
la langue pour chacune des rubriques du site, pas seulement celles de premier
niveau.
Par
article : la langue peut être modifiée au niveau de chaque
article ; ce choix est compatible avec les précédents (on peut par exemple
choisir la langue par rubrique mais appliquer des exceptions de-ci de-là à
certains articles) et permet toutes les finesses imaginables, mais attention à
ne pas produire un site à la structure incompréhensible...
[SPIP 1.7.2] Certains objets, comme les auteurs ou
les mots-clés, peuvent s’orthographier différemment selon qu’ils sont affectés
à un article dans une langue ou dans une autre. Cependant, il serait absurde de
concevoir des « traduction d’un mot-clé » ou « traduction d’un
auteur », car c’est bien le même auteur qui signe les deux articles, ou le
même mot-clé (même « concept ») qu’on leur attache. Ces objets n’ont
donc pas de langue au sens de SPIP, mais il est tout de même possible, à l’aide
des « blocs multi », de les faire s’afficher dans la langue du
contexte dans lequel ils sont invoqués (pour le dire plus simplement :
faire que le mot-clé « Irak » s’affiche « Iraq » quand il
est affecté à un article en anglais).
Le « bloc multi » est un nouveau
raccourci de SPIP, dont la structure est relativement intuitive :
<multi>chaîne
1 [xx] chaîne 2 [yy] chaîne 3 ...</multi> |
Pour reprendre l’exemple du mot-clé, son titre
serait entré sous la forme :
<multi>[fr]Irak
[en]Iraq</multi> |
Si un bloc multi est appelé à s’afficher dans une
langue qui n’est pas prévue, c’est toujours la première partie du bloc qui
s’affiche (« chaîne 1 » dans le premier exemple, « Irak »
dans le second). Cela, afin de ne jamais avoir d’affichage vide [15].
NB :
les blocs multi peuvent aussi être utilisés, selon la même structure, dans les
squelettes, cf. Internationaliser
les squelettes.
Une fois l’espace privé réglé aux petits oignons,
passons maintenant au site public. Hé oui, même si chaque article dispose
maintenant de sa propre langue judicieusement choisie (selon le mécanisme
expliqué plus haut), les squelettes doivent bien pouvoir en tenir compte dans
l’affichage du site.
1.
Une bonne nouvelle pour commencer : le multilinguisme des
squelettes est pour la plus grande part totalement naturel ; il n’est pas
nécessaire de faire des squelettes différents pour afficher des articles de
langues différentes. Un même squelette adapte automatiquement son
affichage à la lange courante.
Ainsi tous les éléments affichés autour et dans un
article d’une langue donnée, seront affichés dans cette langue. Cela concerne
aussi bien la date de publication de l’article que les formulaires de réponse
au forum, de signature d’une pétition, etc. Plus généralement : toute
balise SPIP incluse dans une boucle ARTICLES sera
affichée dans la langue de l’article (de même pour les rubriques et les
brèves).
Exemple : si votre page d’accueil contient un sommaire affichant les dix
derniers articles publiés ainsi que leur date de publication, la date des
articles en vietnamien s’affichera en vietnamien, celle des articles en créole
de la Réunion s’afficheront en créole de la Réunion, etc.
Note : ce fonctionnement suppose que la langue de l’article fait l’objet d’une traduction dans SPIP. Ainsi, si un article est écrit en volapück mais que votre version de SPIP n’est pas encore traduite en volapück (nous vous invitons bien évidemment à corriger cette lacune en participant à l’effort de traduction), la date de l’article s’affichera en toutes lettres certes, mais dans une langue par défaut - le français probablement.
2. Le sens de l’écriture
Si votre site contient des langues s’écrivant de
gauche à droite (la plupart des langues) mais aussi des langues s’écrivant de
droite à gauche (notamment l’arabe, l’hébreu ou le farsi), il faudra de petits
compléments au code HTML pour que l’affichage se fasse sans accroc [16].
SPIP offre à cet effet une balise spécifique : #LANG_DIR, qui définit le sens d’écriture de la langue
courante. Cette balise est utilisable comme valeur de l’attribut dir dans la plupart des tags HTML (cela donne donc
« ltr »
pour les langues s’écrivant de gauche à droite, et « rtl » pour les autres [17]).
Une boucle d’affichage du sommaire devient
donc :
<BOUCLE_sommaire(ARTICLES){par date}{inverse}{0,10}> <li
dir="#LANG_DIR">[(#DATE|affdate)]: <a
href="#URL_ARTICLE">#TITRE</a></li> </BOUCLE_sommaire> |
Si la mise en page repose sur des éléments alignés
à droite ou à gauche, ceux-ci devront être inversés pour les langues écrites de
la droite vers la gauche : on peut tout de suite penser à remplacer tous [18] les éléments du squelette marqués left ou right par les balises #LANG_LEFT et #LANG_RIGHT. Pour ce qui est de la définition de la page
elle-même, il est alors judicieux de commencer par donner la langue de
l’élément demandé, et la direction générale de la page :
<html lang="#LANG"> <body dir="#LANG_DIR"> ... </body> </html> |
3. Les liens de traduction
SPIP propose un système de traduction entre
articles : on peut spécifier quelles sont les différentes traductions d’un
article (note : ces traductions sont elles-mêmes des articles à part
entière). Le critère {traduction} permet alors, dans une boucle ARTICLES, de récupérer toutes les versions d’un même
article.
Par exemple, pour afficher toutes les traductions
de l’article courant :
<BOUCLE_traductions(ARTICLES){traduction}{exclus}> [<a
href="#URL_ARTICLE" dir="#LANG_DIR">(#LANG|traduire_nom_langue)</a>] </BOUCLE_traductions> |
Notons le critère {exclus}, qui permet de ne pas afficher la version
courante, et le filtre {traduire_nom_langue} qui fournit le nom véritable de la langue à partir
de son code informatique (cela permet d’afficher « français » au lieu
de « fr »,
« English » au lieu de « en »...).
Un
critère complémentaire {origine_traduction} (pour les plus acharnés) permet de sélectionner
uniquement la « version originale » de l’article courant.
Une page du wiki de spip-contrib rassemble des
exemples de boucles utilisant ces critères : http://www.spip-contrib.net/spikini....
4. Éléments supplémentaires
[SPIP 1.7.2] introduit d’autres éléments permettant
de fabriquer des sites multilingues :
— le critère {lang_select} sert à forcer la sélection de la langue pour la
boucle (AUTEURS), qui normalement ne le fait pas (à l’inverse, le critère {lang_select=non} permet de dire aux boucles (ARTICLES), (RUBRIQUES) ou (BREVES) de ne pas sélectionner la langue).
— la variable de personnalisation $forcer_lang indique à SPIP qu’il doit vérifier si le visiteur
dispose d’un cookie de langue, et si oui le renvoyer vers la page
correspondante. C’est ce que fait la page de connexion à l’espace privé livrée
en standard avec SPIP.
— les balises #MENU_LANG (et #MENU_LANG_ECRIRE) affichent un menu de langue qui permet au visiteur
de choisir « cette page en ... ». La première balise affiche la liste
des langues du site ; la seconde la liste des langues de l’espace privé
(elle est utilisée sur la page de connexion à l’espace privé).
— enfin, les critères optionnels (cf. SPIP 1.7, 1.7.2) permettent
d’utiliser une même boucle (en fait, un même squelette) pour afficher soit tous
les articles du site dans toutes les langues, soit seulement les articles dans
la langue passée dans l’URL. Ça peut être utile dans les backend, par exemple,
ou dans les boucles de recherche :
<BOUCLE_recents(ARTICLES){lang?}{par date}{inverse}{0,10}> |
<BOUCLE_recherche(ARTICLES){lang?}{recherche}{par
points}{inverse}{0,10}> |
Ce qui précède nous a permis de rendre multilingue
la partie proprement SPIP de notre squelette : tout ce qui est issu des
boucles s’affiche dans le bon sens, avec la bonne typographie, et les éléments
produits par SPIP (formulaires, dates...) sont dans la langue demandée.
Pour un site présentant un nombre modeste de langues
(bilingue par exemple), ou pour lequel il existe une langue principale et
quelques langues annexes, on pourrait en rester là. Les textes figés présents
dans les squelettes, c’est-à-dire les mentions écrites directement dans le HTML
comme « Plan du site », « Espace de rédaction »,
« Répondre à ce message »... peuvent dans certains cas rester dans
une seule langue ; ou alors, un site bilingue pourra utiliser des
squelettes séparés pour chacune des deux langues.
Cependant, si vous voulez réaliser et gérer
efficacement un site présentant beaucoup de langues à part entière, il devient
illusoire de maintenir des squelettes séparés, ou d’imposer une navigation dans
une langue unique (même en anglais ou en espéranto...). Pour réaliser un jeu de
squelettes unique fonctionnant dans toutes les langues, il faut
internationaliser les squelettes afin de modifier les textes indépendamment du
code HTML qui les contient (qui reste, lui, figé d’une langue à l’autre). Cette
tâche nécessite de mettre un peu « les mains dans le cambouis » et
fait l’objet d’un article
séparé.
Les
raccourcis typographiques <code> et <cadre>
produisent toujours un texte écrit de gauche à droite, même si la langue de
l’article s’écrit normalement de droite à gauche. En effet ces deux raccourcis
sont destinés à afficher du code ou des données informatiques, qui sont à peu
près toujours écrits de gauche à droite (et, la plupart du temps, en caractères
occidentaux).
Toujours
en ce qui concerne le sens d’écriture, notons que les attributs left et right du HTML sont aussi souvent présents dans les
feuilles de style. Cela veut dire que vous devrez peut-être inclure la partie
correspondante de la feuille de style dans vos squelettes (pour utiliser les
balises #LANG_LEFT et #LANG_RIGHT) plutôt que de la placer dans un fichier séparé.
Voici un récapitulatif du comportement des balises
SPIP liées au sens de l’écriture :
Langue |
#LANG_LEFT |
#LANG_RIGHT |
#LANG_DIR |
langues écrites de gauche à
droite |
left |
right |
ltr |
arabe,farsi,hébreu... |
right |
left |
rtl |
Dès la mise en ligne de documents, SPIP adapte
certaines informations « automatiques » dans la langue désirée.
Notamment les dates sont affichées dans la langue du site, ou d’un article, ou
d’une rubrique, les formulaires sont affichés dans la langue correspondante
(par exemple l’interface pour poster des messages de forums)... Tout cela est
d’ores et déjà traduit par SPIP.
Ce n’est cependant pas suffisant : les
webmestres insèrent dans leurs squelettes un certain nombre d’informations,
décrivant notamment les principes de navigation dans le site. Il est
nécessaire, par exemple, d’afficher des textes du style « Plan du
site », « Répondre à cet article », « Articles du même
auteur », « Dans la même rubrique »... Pour un site dans une
seule langue, ces différents éléments sont faciles à insérer : on les
insère tels quels dans le code HTML des squelettes. Le problème apparaît
lorsque le site est multilingue : sous un article en français, on veut
afficher « Répondre à cet article », mais sous un article en
anglais, on a besoin d’afficher un autre texte (« Comment on this
article »).
[SPIP 1.7.2] propose trois méthodes pour gérer ces
éléments de texte différents selon les langues :
— (1) une méthode consistant à stocker les
éléments de texte des squelettes dans des fichiers de langue (un fichier
différent par langue utilisée sur le site), séparés des squelettes ; un
squelette unique (par exemple article.html appelant, selon des codes définis par le
webmestre, ces éléments de texte en fonction de la langue utilisée ; de
cette façon, un même squelette article.html affichera automatiquement le texte « Répondre
à cet article » ou « Comment on this document » en fonction de
la langue de l’article. Cette méthode est vivement conseillée, elle offre le
plus de souplesse, elle facilite les mises à jour du site (on
travaille avec un squelette unique qui gère automatiquement plusieurs langues),
et à terme des outils seront ajoutés à SPIP facilitant le travail collectif de
traduction de l’interface de votre site (plusieurs administrateurs, parlant
chacun une langue différente, pourront traduire l’interface d’un même
site depuis l’espace privé, sans avoir besoin d’intervenir sur les fichiers des
squelettes) ;
— (2) une méthode plus rapidement accessible,
techniquement très simple, reposant sur la création de fichiers de squelettes
différents pour chaque langue. Dans cette méthode, on fabrique un fichier article.html pour gérer les articles en français, et un fichier
article.en.html pour
les articles en anglais (note : article.html gère en réalité toutes les langues sauf
l’anglais). Cette méthode est déconseillée si le site utilise de nombreuses
langues et/ou si on utilise des squelettes distincts selon les rubriques. Par
ailleurs, elle est dans tous les cas avantageusement remplacée par la méthode 3
décrite ci-dessous :
— (3) la méthode des « blocs
multilingues », introduite par [SPIP 1.7.2], fonctionne aussi bien dans
les contenus que dans les squelettes. Il suffit de mettre dans le squelette la
construction suivante :
<multi> [fr] Répondre à cet article [en] Comment on this article </multi> |
et la phrase s’affichera dans la langue voulue. Si
ce système est très souple, il atteint toutefois ses limites dès que le nombre
de langues est important, et que l’on souhaite que différents traducteurs
interviennent dans le site (il faut en effet qu’ils puissent modifier le
squelette, ce que la méthode des fichiers de langue permet d’éviter).
Le principe des fichiers de langue consiste à
insérer dans un squelette unique un code, lequel correspondra dans
chaque langue à un élément de texte (une « chaîne ») ; entre les
différentes langues le code ne varie pas, mais le texte est traduit.
Par exemple, nous pouvons décider que le code telechargement correspond :
— en français, à la chaîne « télécharger ce
fichier »,
— en anglais, à la chaîne « download this file »,
— en espagnol, à la chaîne « descargar este archivo »,
— etc.
Dans le fichier de squelette des articles (un seul
fichier gérera toutes les langues), article.html, il suffit d’insérer le code (notez la
syntaxe) :
<:telechargement:> |
Lors de l’affichage d’un article, ce code
sera remplacé par sa traduction dans la langue de l’article.
Par exemple, dans le squelette article.html, nous insérons dans la boucle affichant les
documents associés à l’article, le code suivant :
<a
href="#URL_DOCUMENT"><:telechargement:></a> |
Si l’article en question est en français, cela
produira :
<a
href="/IMG/jpg/mondocument.jpg">télécharger ce fichier</a>
si l’article est en anglais :
<a href="/IMG/jpg/mondocument.jpg">download
this file</a>
et ainsi de suite. Un unique squelette, contenant
un unique code, affiche un texte traduit dans toutes les langues utilisées sur
le site.
Utiliser
des textes déjà traduits
Pour faciliter le travail des webmestres, SPIP
fournit un ensemble de chaînes déjà traduites (par les traducteurs de SPIP). En
utilisant ces chaînes, correspondant à des éléments de texte fréquemment
utilisés sur des sites Web, le webmestre peut rapidement réaliser une interface
fonctionnant dans différentes langues, mêmes celles qu’il ne parle pas
lui-même.
Vous pouvez lister les chaînes disponibles depuis
l’espace privé : allez dans la section « Gestion des langues »
de la partie « Administration du site », puis cliquez sur l’onglet
« Fichiers de langues ». Vous n’avez plus qu’à y piocher les codes de
votre choix pour la réalisation de vos squelettes.
Les fichiers de langue dans l’espace privé
Exemple : un webmestre veut réaliser l’interface pour un site en français, en
espagnol et en arabe, mais il ne parle pas lui-même l’espagnol et l’arabe. En
insérant dans ses squelettes les codes livrés avec SPIP, il n’a pas à se
soucier d’obtenir des traductions en espagnol et en arabe, car le travail de
traduction a déjà été effectué en amont par les traducteurs de SPIP ;
ainsi, en mettant au point l’interface en français avec les codes fournis par
SPIP, il sait que ses pages s’afficheront immédiatement en espagnol et en
arabe.
Si par la suite on ajoute des articles en polonais,
ils seront immédiatement affichés avec les éléments de texte traduits en
polonais, sans que le webmestre ait à intervenir à nouveau.
Autre avantage de cette méthode : elle facilite la création de squelettes « à distribuer » immédiatement multilingues. Des squelettes réalisés selon cette méthode seront immédiatement utilisables dans toutes les langues dans lesquelles sera traduit SPIP.
D’un point de vue technique, les éléments de texte fournis en standard
avec SPIP sont stockés dans les fichiers de langue « public » :
— /ecrire/lang/public_fr.php3 contient les chaînes en français,
— /ecrire/lang/public_en.php3 en anglais
— etc.
Créer
ses propres codes
Il est de plus possible de créer ses propres codes,
correspondant à des chaînes que l’on désire ajouter soi-même.
Il s’agit alors de créer des fichiers de langue
personnels, sur le modèle des fichiers public.... Pour créer ses propres fichiers, on installera,
dans votre répertoire de squelette ou dans le répertoire /ecrire/lang :
— local_fr.php3 pour définir les chaînes en français,
— local_en.php3
en anglais,
— ...
historique : Dans les versions antérieures à [SPIP 1.8], les fichiers de langue personnels se plaçaient seulement dans le répertoire /ecrire/lang.
Par exemple, on pourra créer les chaînes suivantes :
— telechargement pour afficher « Télécharger la dernière
version »,
— quoideneuf pour afficher « Modifications
récentes ».
Selon cette méthode, on insère dans les squelettes
les codes <:telechargement:> et <:quoideneuf:>, ils seront ensuite affichés avec les traductions
correspondantes, telles qu’elles sont définies dans les fichiers local_...php3.
Notons que les codes sont arbitraires : c’est vous qui les choisissez. Nous recommandons bien évidemment de choisir des codes qui vous permettent de les retenir facilement (plutôt que des numéros par exemple). Comme souvent avec les codes informatiques, il est préférable de n’utiliser que des lettres de l’alphabet latin, et sans accents...
Les fichiers de langue contiennent les
différentes traductions des codes que vous utiliserez ; ce sont des
fichiers PHP contenant chacun un tableau associant aux codes les chaînes
correspondantes dans chaque langue.
Ils contiendront par exemple :
Version
française :
<?php $GLOBALS[$GLOBALS['idx_lang']] = array(
'telechargement' => 'Télécharger la
dernière version',
'quoideneuf' => 'Modifications récentes' ); ?> |
Version
catalane :
<?php $GLOBALS[$GLOBALS['idx_lang']] = array(
'telechargement' => 'Descarregar la darrera versió',
'quoideneuf' => 'Modificacions recents' ); ?> |
La construction est la suivante :
— au début du fichier :
<cadre> <?php $GLOBALS[$GLOBALS['idx_lang']] = array( |
— à la fin du fichier :
); ?> |
— la partie qu’il faut enrichir soit-même
consiste en plusieurs lignes de définitions, sur le modèle :
'code' => 'La chaîne à afficher', |
N.B.
Chaque ligne de définition se termine par une virgule, sauf la dernière ligne.
N.B.2. Le texte de la chaîne à traduire doit être convertie en codes HTML
(les caractères accentués, par exemple, sont convertis en leur équivalent HTML,
du type é).
Les apostrophes à l’intérieur de la chaîne doivent
être échappées, c’est-à-dire précédées d’un antislash. Par exemple, la
chaîne « sur l’internet » soit être inscrit : sur
l\'internet.
Note : à terme, il est prévu d’inclure un outil permettant de gérer et créer ses propres fichiers de langue sans avoir à modifier « à la main » des fichiers PHP. Un tel outil facilitera de plus l’utilisation de caractères « spéciaux » (caractères accentués, caractères dans des alphabets non occidentaux, échappement des apostrophes...), ainsi que la collaboration de plusieurs personnes au processus de traduction de l’interface du site public.
Pour l’instant, l’outil permettant de gérer la
traduction des chaînes de texte n’est pas livré directement avec SPIP, et son
utilisation très généraliste (nous l’utilisons pour traduire toute l’interface
de SPIP, et pas seulement des fichiers de langue de type local...php3) le rend un peu complexe par rapport à cette
tâche. Ce programme, trad-lang, qui nous sert à traduire le
logiciel SPIP, le site spip.net, etc., est lui-même disponible sous licence
GNU/GPL, mais il n’est pas intégré en standard à SPIP. Vous pourrez le télécharger, pour l’utiliser pour
votre site ou pour d’autres projets de logiciels. Si vous l’améliorez, ou avez
des idées pour le transformer, venez en discuter sur la liste des traducteurs
de SPIP, spip-trad.
La seconde méthode, plus accessible aux webmestres
débutants, consiste à créer des squelettes différents pour chaque langue. Un
peu sur le même principe qui consiste à créer des squelettes spécifiques pour
différentes rubriques pour obtenir des interfaces graphiques différentes.
Nous voulons réaliser un site en français (langue
par défaut), en anglais et en espagnol.
Nous réalisons trois fichiers de squelette différents :
— article.html pour le français (en réalité, pour toutes les langues qui n’ont pas
de fichier de langue spécifique ci-après),
— article.en.html pour l’anglais,
— article.es.html pour l’espagnol.
(Note : si on publie un article en allemand,
alors qu’il n’existe pas de squelette article.de.html sur notre site, c’est le squelette article.html qui sera utilisé.)
Important : pour que les squelettes « par langue », définis par l’ajout d’un .lang à la fin du nom, soient pris en compte, il faut obligatoirement qu’il existe la version « par défaut » sur le site.
Ici, si article.html n’existe pas (on aurait préféré nommer directement
un article.fr.html), les fichiers anglais et espagnol ne seront pas pris en compte.
On peut combiner cela avec le nommage « par
rubriques », et l’ordre suivant sera pris en compte :
— article=8.es.html (le squelette pour les articles en espagnol de la
rubrique 8, mais pas ses sous-rubriques),
— article=8.html
(le squelette pour les articles de la rubrique 8, mais pas ses sous-rubriques),
— article-2.es.html (le squelette pour les articles en espagnol de la rubrique 2 et ses
sous-rubriques),
— article-2.html
(le squelette pour les articles de la rubrique 2 et ses sous-rubriques),
— article.es.html (le squelette pour les articles en espagnol),
— article.html
(le squelette pour les articles),
— article-dist.html (le squelette pour les articles livré avec SPIP).
Note : sauf pour quelques exceptions, il faut utiliser ici les codes de langues à deux lettres normalisés par l’ISO, comme « es ». On en trouvera notamment la liste sur le site de la Bibliothèque du Congrès des Etats-Unis (eh oui !). Pour s’assurer d’un maximum de compatibilité, il faut utiliser en priorité les codes ISO à deux lettres (« iso 639-1 »), quand ils existent, et pour une désignation plus spécialisée d’une langue dans sa famille linguistique les codes ISO à trois lettres (« iso 639-2 T »). Par exemple, l’allemand sera désigné comme « de ». Mais l’ISO ne prend en compte que 182 langues sur les 5 000 à 7 000 langues parlées dans le monde ; pour les langues non encore répertoriées, on peut s’inspirer du répertoire proposé par le site ethnologue.com ; pour en savoir plus, rendez-vous sur la liste spip-trad.
Se simplifier la vie. Une des méthodes de structuration très simple qu’autorise SPIP pour gérer un site multilingue consiste à associer directement les langues aux rubriques (et non article par article). Ainsi, dans le cas où les articles d’une même langue sont regroupés dans une même rubrique (voire par secteurs), on peut se contenter de créer les squelettes spécifiques par rubrique, sans utiliser alors les noms de fichiers par langues.
De cette façon, si, tous les articles en espagnol
sont regroupés dans la rubrique 8 (et ses sous-rubriques), on peut se contenter
de nommer le fichier adapté à l’espagnol rubrique-8.html plutôt que rubrique.es.html.
On devine les problèmes qui peuvent se poser avec cette méthode :
— le fichier article-2.html doit exister si on veut que article-2.es.html puisse être sélectionné ;
— on ne peut pas décider, à l’inverse, que article.es.html doit être utilisé à la place d’article-2.html si article-2.es.html n’existe pas : la sélection par rubriques a
toujours la priorité sur la sélection par langues ;
— une correction de mise en page dans un squelette implique de faire la
même correction dans les autres versions,
— on doit pouvoir insérer soi-même des éléments de texte dans les fichiers
des squelettes, alors qu’on ne comprend pas forcément la langue (imaginez-vous
créer ainsi les squelettes en arabe alors que vous parlez un peu le français de
l’ouest et assez mal l’occitan du nord...).
Cette méthode est donc destinée à travailler rapidement
sur des sites peu complexes (peu ou pas de squelettes spécifiques aux
rubriques) et/ou comportant peu de langues différentes. Dès que votre projet
multilingue devient un peu plus ambitieux, il est vivement conseillé de
travailler avec la méthode des fichiers de langue.
Les blocs multi définis dans l’article Réaliser un site multilingue
fonctionnent aussi bien dans le texte des auteurs ou mots-clés que dans les squelettes.
Attention, ces blocs ne gèrent que du texte, et pas des boucles
SPIP !
Pour gérer rapidement un site multilingue, c’est
sans doute, dans un premier temps, la meilleure méthode, à la fois accessible
et efficace ; ensuite, une fois votre site stabilisé, si vous avez besoin
d’affiner vos squelettes (par exemple, pour les ouvrir à plus de langues ;
ou pour les distribuer sous forme de contrib ;
ou encore pour les « professionnaliser »), il faudra transformer vos
blocs multi en fichiers de langue.
Après l’installation, les pages générées par SPIP
utilisent des adresses relatives ressemblant à article.php3?id_article=123, donnant des URLs du type http://www.spip.net/article.php3?id_article=123.
Ce type de syntaxe, courant chez les sites
« dynamiques », n’est cependant pas très joli ni très évocateur. Il y
a possibilité d’avoir des adresses plus à votre goût — par exemple article123.html ou Titre-de-l-article.html —, et SPIP vous aide en partie dans cette
tâche.
Cette fonctionnalité fait appel à la distinction
entre deux types d’URLs :
l’URL
apparente d’une page, c’est-à-dire telle qu’elle est tapée et/ou affichée
dans la barre d’adresse du navigateur. Par exemple http://www.spip.net/fr_article765.html. Ce sont ces URLs qu’on cherche à rendre plus
« jolies » ou plus « signifiantes » ;
l’URL
réelle de la page, c’est-à-dire l’URL qui est « vue » par SPIP
lorsque la page est calculée sur le serveur. Par exemple http://www.spip.net/article.php3?id_article=765 ; en général, cette URL peut aussi être tapée
directement dans le navigateur (vous pouvez vérifier).
Dans le fichier ecrire/mes_options.php3 [19] (à créer le cas échéant), vous pouvez déclarer une
variable PHP contenant le type d’URLs à utiliser. En l’absence de ce réglage,
SPIP utilisera :
$type_urls
= "standard";
La variable $type_urls détermine le nom du fichier PHP qui est appelé
pour gérer les URLs. Avec la déclaration par défaut ci-dessus, c’est inc-urls-standard.php3.
Vous remarquerez que SPIP propose aussi les
fichiers inc-urls-html.php3, inc-urls-propres.php3 et inc-urls-propres2.php3.
Le
fichier inc-urls-html.php3 permet de traiter des adresses du type (« article123.html »). Vous pouvez décider d’utiliser les « URLs “html” »
en mettant dans ecrire/mes_options.php3 la ligne :
$type_urls = "html";
Le
fichier inc-urls-propres.php3 permet de traiter des adresses du type
(« Titre-de-l-article »). Il faut alors ajouter :
$type_urls =
"propres";
Le
fichier inc-urls-propres2.php3 est une variation du précédent, qui donne des
adresses du type (« Titre-de-l-article.html »). Il faut alors
ajouter :
$type_urls = "propres2";
Si vous voulez plutôt utiliser vos propres adresses
(ce pour quoi vous devez savoir programmer en PHP), il est fortement conseillé
de partir d’un des fichiers existants et de le recopier sous le nom que vous
aurez choisi : inc-urls-XXX.php3. Il est par exemple très aisé de modifier la
fonction _generer_url_propre() dans inc-urls-propres.php3 pour obtenir des variations très
intéressantes ; si vous faites cela, merci de partager vos modifications
sur le site SPIP Contrib’.
Pour que l’adresse article123.html appelle bien en réalité le fichier PHP article.php3 avec comme paramètre id_article=123, il va falloir configurer le serveur Web qui
héberge votre site, soit dans un fichier .htaccess (ça ne
marche pas toujours), soit dans le fichier de configuration centrale du serveur
si vous y avez accès. Cela utilise, sous le serveur Apache (le plus utilisé), ce qu’on appelle
des Rewrite Rules : des règles de réécriture d’adresses Web.
Savoir écrire ces règles n’est pas simple pour les
non-programmeurs, et nous ne pouvons pas vous donner de solutions infaillibles
car cela dépend de votre configuration : cette partie est entièrement
entre vos mains (ou celles de votre hébergeur).
Néanmoins, [SPIP 1.8.1]
fournit un fichier htaccess.txt à titre d’exemple, qui fonctionne sur la plupart des hébergeurs avec
les types d’URLs cités précédemment (« standard »,
« html », « propres » et
« propres2 »). Pour l’activer il faut le recopier à la
racine du site sous le nom .htaccess. Il est fortement conseillé de l’ouvrir au
préalable pour vérifier quelques aspects de configuration.
Vous devrez ensuite tester la validité de ces
adresses, en appelant la page « Voir en ligne » sur un article, un
auteur, une brève, une rubrique, etc.
Afin d’afficher partout les URLs du type choisi,
utilisez dans vos squelettes les balises #URL_ARTICLE, #URL_RUBRIQUE, #URL_BREVE, etc.
Depuis [SPIP 1.8.1],
tout est prévu pour que la transition d’un type d’adresses à l’autre se fasse
en douceur : installez le fichier htaccess.txt, et vous pouvez ensuite librement basculer des
adresses « standard » aux adresses « propres2 »,
« propres » ou « html », et vice-versa, sans jamais
provoquer d’erreur 404 pour les visiteurs (ou les moteurs de recherche) qui auraient mémorisé les anciennes adresses.
Dernier détail pour faciliter la transition, si
vous choisissez les URLs propres ou propres2, les visites des pages portant les
anciennes adresses (standard ou html) sont redirigées automatiquement vers les
nouvelles adresses.
SPIP intègre un moteur de recherche, désactivé par défaut. Ce moteur, lorsqu’il est activé par un administrateur dans la page de configuration, permet d’effectuer des recherches sur différents types d’informations présentes dans la base de données : les articles, les rubriques, les brèves, les mots-clés et les auteurs. Depuis SPIP 1.7.1 les fils de discussion des forums (threads) et les signatures de pétitions sont également indexés.
Il y a deux grandes façons de faire un moteur de
recherche. La première est de chercher tout bêtement dans le
type de stockage existant (fichiers HTML, base de données... selon le type de
site). Cette méthode est très lente car le type de stockage n’est pas prévu à
cet effet.
La seconde méthode, qui a été choisie pour SPIP (et
qui est aussi celle de tous les moteurs professionnels), est d’établir un mode de stockage
spécifique aux besoins de la recherche. Par exemple, le score de chaque mots d’un article
peut être stocké directement afin d’être facilement retrouvé, et d’avoir le
score total d’une recherche par une simple addition. L’avantage est que la
recherche est très rapide : presque aussi rapide que n’importe quel calcul
de page. L’inconvénient est qu’il faut une phase de construction du dit
stockage des informations : cela s’appelle l’indexation. L’indexation a un
coût en termes de ressources (temps de calcul et espace disque), et elle
introduit également un léger décalage temporel entre l’ajout ou la modification
d’un contenu, et la répercussion de cet ajout ou de cette modification sur les
résultats de recherche.
D’autre part, dans le cas de SPIP, nous sommes
obligés d’utiliser PHP et MySQL comme pour le reste du logiciel, ce qui ne
permet pas de réaliser un moteur très performant, en termes de rapidité, mais
aussi de pertinence ou d’enrichissements divers (indexation de documents
extérieurs au site, création de champs sémantiques permettant de proposer des
recherches plus fines, etc.).
L’avantage du moteur interne, cependant, c’est
qu’il permet de gérer l’affichage des résultats à travers les mêmes méthodes
(squelettes) que le reste des pages de SPIP, et à l’intérieur du même
environnement visuel.
L’indexation est réalisée lors des visites du site
public. Afin d’éviter que le cumul d’une indexation et d’un calcul de page ne
mène à un timeout sur les serveurs particulièrement lents, SPIP attend
qu’une page soit affichée en utilisant le cache [20].
L’indexation traite une à une les différentes données
textuelles d’un contenu donné : par exemple, pour un article, le chapo, le
descriptif, le titre, le texte... Pour chaque donnée textuelle, le score de
chaque mot est calculé en comptant simplement le nombre d’occurrences. A cet
effet, les mots de trois caractères ou moins sont ignorés (ils sont, pour la
plupart, non significatifs, et alourdiraient la base de données) ; d’autre
part, les caractères accentués sont translittérés (convertis en leurs
équivalents non-accentués), pour éviter les problèmes de jeux de caractères et
aussi pour permettre d’effectuer des recherches en version non accentuée.
Ensuite, les scores de chaque mot sont cumulés, de
façon pondérée, entre les différentes données textuelles du contenu indexé. La
pondération permet, par exemple, de donner plus de poids aux mots présents dans
le titre d’un article que dans le corps du texte ou le post-scriptum...
Les fonctions d’indexation peuvent être étudiées au
sein du fichier ecrire/inc_index.php3. Pour mieux visualiser la dynamique d’indexation
du site, vous pouvez ouvrir le fichier ecrire/data/spip.log, ou encore regarder la page ecrire/admin_index.php3 (nota : cette page, encore expérimentale,
n’est pas livrée avec toutes les versions de SPIP, et n’existe qu’en français).
Dans la version [SPIP 1.6],
d’importantes modifications ont été apportées au comportement du moteur :
meilleur
comportement dans un environnement multilingue ;
le
tiret bas (underscore) n’est plus considéré comme un séparateur de mot,
mais comme un caractère alphabétique (utile pour de la documentation
informatique) ;
les
mots de deux lettres (et plus) ne contenant que des majuscules et des
chiffres sont considérés comme des sigles, et sont indexés, ce qui supprime
l’un des principaux inconvénients de la limitation de l’indexation aux mots de
plus de 3 lettres (G8, CNT, ONU sont désormais indexés).
La recherche s’effectue
simplement en séparant le texte de recherche en ses différents mots ; le même
filtre est appliqué que lors de l’indexation : suppression des mots de
trois lettres ou moins (sauf sigles), et translittération.
Pour chaque contenu recherché, le score des
différents mots est ensuite récupéré puis additionné afin d’obtenir le score
total. Enfin, les résultats sont en général affichés par ordre décroissant de
score ({par points}{inverse}), c’est-à-dire de pertinence (mais cela est laissé
à la volonté de la personne qui écrit les squelettes de mise en page).
Rapidité
Sur un serveur récent et pas trop chargé,
l’indexation d’un texte long (plusieurs dizaines de milliers de caractères)
prendra entre une et deux secondes : l’attente est presque imperceptible,
comparée aux délais de chargement via le réseau. Les contenus courts sont
indexés de façon quasi-instantanée. Bien sûr, ces affirmations doivent être
modulées selon la taille du site. Un site vraiment très gros risque de voir les
temps d’indexation s’allonger légèrement ; pour relativiser, signalons
qu’un site comme Le Courrier des Balkans
comporte, à la date d’écriture de ce texte, environ 3 800 articles
publiés, et plus de 7500 messages de forum, et que le moteur de recherche de SPIP ne
donne aucun signe de faiblesse.
Par ailleurs, statistiquement, on peut considérer
de façon approximative que chaque contenu ne sera indexé qu’une seule
fois : compte tenu qu’il y a en général beaucoup plus de visites sur un
site que de mises à jour de
contenus, le surcroît de charge du serveur apparaît négligeable.
Qualité
La qualité de l’indexation est plus faible que sous
des moteurs de recherche professionnels. PHP étant un langage plutôt lent, la phase
d’extraction des mots a dû être simplifiée au maximum pour que les temps
d’indexation restent minimes. Par conséquent, les données d’indexation
comportent quelques « déchets », c’est-à-dire des morceaux de texte
qui ne correspondent pas à de « vrais » mots, mais ont été indexés
comme tels (il s’agit souvent de contenus techniques comme des noms de
fichiers, ou de passages à la ponctuation malmenée). L’exemple d’uZine, où l’on constate environ 2 % de
tels « déchets », nous laisse cependant penser que ces données sont
quantité négligeable, d’autant qu’il y a peu de chance qu’elles déclenchent un
résultat positif lors d’une recherche.
La recherche n’offre pas
d’opérateurs booléens, l’opérateur implicite étant grosso modo un
« OU » logique. Cependant, depuis SPIP 1.7.1, les articles
trouvés s’affichent dans un ordre qui privilégie les résultats contenant le
plus de mots orthographiés précisément selon la requête. Ainsi, une requête sur
« la main rouge » mettra en évidence les articles contenant
« main » et « rouge », loin devant les articles ne
contenant que « maintenance » ou « rouget » - ceux-ci
apparaîtront, mais plus loin dans le classement.
Espace disque
MySQL n’étant pas spécialement conçu pour le
stockage de données d’indexation, l’utilisation du moteur de recherche a tendance
à faire beaucoup grossir l’espace disque utilisé par la base de données. Pour
donner quelque précision, disons qu’un contenu génère des données d’indexation
de taille comprise entre la taille du contenu et le double de celle-ci. Donc,
si l’on fait abstraction des données ne donnant pas lieu à indexation (les
forums par exemple), l’indexation fait entre doubler et tripler la place prise
par la base de données. Cela peut être gênant si la place vous est très
comptée.
Si jamais vous désactivez le moteur de recherche afin
d’économiser de l’espace disque, n’oubliez pas ensuite d’effacer les données
d’indexation (dans la page de sauvegarde/restauration de la base de données)
afin de réellement libérer l’espace disque occupé par ces données.
Certains comportements des pages de votre site peuvent être modifiés au moyen de variables PHP. Ces variables sont normalement définies par SPIP, mais, pour obtenir une personnalisation plus fine du site, le webmestre peut les modifier.
Inutile d’entrer dans le code source de SPIP
lui-même pour fixer ces variables (ouf !).
Pour
l’ensemble du site
Si vous voulez fixer ces variables pour
l’intégralité du site, vous pouvez les indiquer, avec une syntaxe un peu
différente, dans un fichier intitulé mes_fonctions.php3, placé à la racine du site. (Il faudra
éventuellement créer ce fichier, et entourer les définitions de vos variables
par les marqueurs <?php et ?>, voir les exemples
ci-dessous.)
Pour
chaque type de squelette
[SPIP 1.4] Vous pouvez aussi définir ces variables squelette
par squelette. Pour cela, il faut les installer au début du fichier PHP
appelant le squelette (par exemple article.php3, rubrique.php3...). Elles s’insèrent naturellement à côté des
variables obligatoires $fond et $delais.
Ces variables sont utilisées lors du calcul de la
mise en page (correction typographique) par SPIP.
$debut_intertitre fixe le code HTML inséré en ouverture des
intertitres (par le
raccourci {{{). En standard, sa valeur est :
$debut_intertitre = "\n<h3
class=\"spip\">\n"; |
$fin_intertitre est le code HTML inséré en fermeture des
intertitres (raccourci }}}). Sa valeur normale est :
$fin_intertitre
= "</h3>\n"; |
$ouvre_ref est le code d’ouverture des appels des notes de
bas de page ; par défaut, c’est une espace insécable et un crochet
ouvrant ;
$ferme_ref est le code de fermeture des appels des notes de
bas de page ; par défaut, c’est un crochet fermant.
$ouvre_note est
le code d’ouverture de la note de bas de page (telle qu’elle apparaît dans #NOTES) ; par défaut, un crochet ouvrant ;
$ferme_note est le code de fermeture des notes de bas de page
(un crochet fermant).
Des choix alternatifs pourront être par exemple
d’utiliser des parenthèses ; ou, plus joliment, d’ouvrir avec le tag HTML <sup>, et de fermer avec </sup>.
Le
fichier puce.gif
et la variable $puce. Lorsque vous commencez une nouvelle ligne par un
tiret, SPIP le remplace par une petite « puce » graphique. Cette puce
est constituée par le fichier puce.gif
installé à la racine du site ; vous pouvez modifier ce fichier selon vos
besoins. Mais vous pouvez aussi décider de fixer vous-même le choix de la puce,
au travers de la variable $puce.
Par exemple pour indiquer un autre fichier graphique :
$puce = "<img src='mapuce.gif' alt='-'
align='top' border='0'>"; |
ou par un élément HTML non graphique :
$puce =
"<li>"; |
Il existe des variables permettant de fixer le
comportement des forums publics avec des mots-clés.
N.B. : Ces variables ne sont utilisées que lorsque vous créez des forums publics dans lesquels les visiteurs peuvent sélectionner des mots-clés ; leur utilisation est donc extrêmement spécifique (et pas évidente...).
$afficher_texte (« oui »/« non »). Par défaut,
les forums publics sont conçus pour permettre aux visiteurs d’entrer le texte
de leur message ; mais lorsque l’on propose le choix de mots-clés dans ces
forums, on peut décider qu’aucun message n’est utile, seul la sélection des
mots-clés importe. Dans ce cas, on pourra indiquer :
$afficher_texte
= "non"; |
$afficher_groupe permet d’indiquer les différents groupes de
mots-clés que l’on souhaite proposer dans tel forum. En effet, tous les forums
sur un site ne sont pas forcément identiques, et si, à certains endroits, on
peut vouloir afficher une sélection de tous les groupes de mots-clés (ceux que
l’ont a rendu accessibles aux visiteurs depuis l’espace privé), à d’autres
endroits, on peut vouloir n’utiliser que certains groupes, voire aucune groupe
(pas de sélection de mots-clés du tout).
La variable $afficher_groupe est un tableau (array), et se
construit donc de la façon suivante :
$afficher_groupe[]
= 3; $afficher_groupe[]
= 5; |
impose l’affichage uniquement des groupes 3
et 5.
$afficher_groupe[]
= 0; |
interdit l’utiliser des mots-clés dans ces forums
(puisqu’il n’existe pas de groupe de mots-clés numéroté 0).
Si l’on n’indique rien (on ne précise pas $afficher_groupe), tous les groupes de mots-clés indiqués, dans
l’espace privé, comme « proposés aux visiteurs du site public » sont
utilisés.
[SPIP 1.5] Si l’on souhaite mettre les squelettes de son site
dans un dossier particulier, par exemple pour faire des essais de différents
jeux de squelettes trouvés sur Internet, ou parce qu’on aime que les choses
soient bien rangées, etc., il est possible de fixer dans mes_fonctions.php3 la variable $dossier_squelettes.
<?php $GLOBALS['dossier_squelettes'] =
'design'; ?> |
À partir de ce moment-là, SPIP ira chercher en
priorité les squelettes présents dans le dossier design/ (que vous aurez créé à la racine du site). Si, de
plus, vous utilisez <INCLURE(xxx.php3)>, SPIP ira chercher le fichier xxx.php3 d’abord dans design/, puis, s’il n’y figure pas, à la racine du site.
Les avantages de ce rangement peuvent sembler
évidents (meilleure séparation du code de spip et de la structure du site,
possibilité de changer tout un ensemble de squelettes d’un seul coup,
etc.) ; l’inconvénient principal est qu’il sera plus difficile de
visualiser les squelettes via un simple navigateur (les liens vers les images,
notamment, risquent de « casser »).
Pour
modifier des variables uniquement pour un certain type de squelettes (par
exemples pour les pages de rubriques), il suffit de les définir dans le fichier
d’appel de ces squelettes. Par exemple, pour les rubriques, on peut fixer des
valeurs directement dans rubrique.php3 :
<?php $fond = "rubrique"; $delais = 2 * 3600; $espace_logos = 20; include
("inc-public.php3"); ?> |
Ici, on a modifié la valeur de l’espace autour des
logos.
Pour
modifier des valeurs de variables pour l’ensemble du site, on peut les définir
dans le fichier mes_fonctions.php3.
Attention, lorsqu’on définit des valeurs dans ce
fichier, il faut impérativement utiliser la syntaxe $GLOBALS['xxx'] pour chacune des variables à personnaliser. Par
exemple, pour définir la valeur de $debut_intertitre, on utilise la syntaxe $GLOBALS['debut_intertitre'].
L’utilisation de cette syntaxe est imposée par des
impératifs de sécurité des sites.
<?php $GLOBALS['debut_intertitre'] = "<h3
class='mon_style_h3'>"; $GLOBALS['fin_intertitre'] =
"</h3>"; $GLOBALS['ouvre_ref'] = ' ('; $GLOBALS['ferme_ref'] = ')'; $GLOBALS['ouvre_note'] = '('; $GLOBALS['ferme_note'] = ') '; $GLOBALS['espace_logos'] = 0; ?> |
[SPIP 1.8.1] permet aux webmestres qui le désirent d’utiliser
sur leurs pages l’outil Tidy, introduisant ainsi une fonction de validation
XHTML sur leur site.
Tidy est un outil (externe à SPIP) qui permet de
transformer du code HTML 4 relativement propre en code XHTML 1.0
transitional valide. SPIP exploite cet outil pour permettre aux webmestres de
proposer des sites conformes aux recommandations du XHTML 1.0 transitional.
Important : Tidy n’est pas un outil
« magique » : il est incapable de transformer du code
« très sale » en code conforme. Face à certaines
« erreurs » de code, il refuse purement et simplement de fonctionner.
L’outil est donc intégré dans SPIP pour, à la fois, créer du code conforme, et
permettre de « traquer » les erreurs de code dans vos pages.
Étape
1 : il convient, avant tout, de créer du code aussi propre et
conforme que possible, avant même le passage par Tidy. Cela se fait à plusieurs
niveaux :
— tout d’abord, SPIP produit, dans ses traitements
typographiques, du code propre, et à chaque version plus conforme (« compliant ») ;
notez bien : SPIP vise la conformité HTML 4.01 transitional ;
— les squelettes du site public doivent
eux-mêmes être aussi conformes que possible (pour rester cohérent, on visera la
conformité HTML 4.01).
Étape
2 : si Tidy est présent sur le serveur, et si le webmestre active
cette option (voir plus loin), alors SPIP fait passer les pages produites par
Tidy, qui va alors tenter de nettoyer les pages et de les transformer en pages
conformes au XHTML 1.0 transitional.
Étape
3 : si le traitement a bien fonctionné (Tidy n’a pas rencontré d’erreur
« bloquante »), alors la page affichée est bien du XHTML 1.0,
dont on peut d’ailleurs faire valider la conformité par le W3C validator ;
en revanche, si Tidy n’a pas fonctionné (voir plus loin), alors c’est la page
d’origine qui est affichée — dans ce cas (c’est un outil important à prendre en
compte), SPIP affiche un bouton d’administration signalant l’« erreur
Tidy », et créé un fichier récapitulant les différentes pages ayant
rencontré des erreurs.
Encore une fois, afin de ne pas préter à l’outil
des possibilités « magiques » qu’il n’a pas, et à ses développeurs
des intentions qui ne sont pas les leurs, il est important de noter que SPIP ne
se contente pas de se reposer sur un outil (Tidy, dont les limites sont
connues), mais de l’intégrer dans une logique plus large de mise en
conformité :
— d’abord en améliorant le code produit par SPIP,
— en utilisant ensuite Tidy à la fois comme outil de
« nettoyage » du code, mais aussi en proposant une indication des
erreurs pour permettre au webmestre d’améliorer son code.
La mise en conformité du code ne peut reposer sur
une solution purement technique, mais sur un travail personnel pour lequel,
avec Tidy, SPIP offre un outil de suivi.
Tidy,
extension de PHP
Tidy existe en tant qu’extension de PHP. C’est la façon la plus simple de l’utiliser, l’outil
étant alors directement utilisable par le webmestre. Pour déterminer sa
présence, on pourra consulter la page /ecrire/info.php3 de son site pour obtenir la configuration de son
serveur et la liste des extensions de PHP disponibles.
N.B. : À l’heure actuelle, l’utilisation de Tidy en tant qu’extension de PHP n’a
pas pu être testée en situation de production dans SPIP. En théorie,
cela fonctionne, mais tout retour d’expérience de la part de webmestres
intéresse les développeurs — sur la liste spip-dev. (Nous avons besoin de
retours d’expérience sur les versions 1 et 2 de Tidy, c’est-à-dire sur des
sites en PHP 4, en PHP 5, mais également des installations via PEAR.)
Tidy
comme programme indépendant
Il est par ailleurs possible d’utiliser Tidy en
ligne de commande (c’est-à-dire en tant que programme indépendant de PHP
s’exécutant directement sur le serveur).
Cette version est particulièrement pratique, puisque :
— il existe des versions de Tidy déjà compilées pour la plupart des
systèmes d’exploitation,
— il est souvent possible et simple d’installer ces versions de Tidy sur
un hébergement sans avoir d’accès root,
— certains administrateurs de sites ont subi des incompatibilités lors de
l’installation de Tidy en extension PHP (avec,
semble-t-il, ImageMagick) ; la version en ligne de commande ne provoque
pas ce genre de problème.
Avant toute chose, vérifiez que Tidy n’est pas déjà
présent sur votre serveur. Pour cela, installez dans le fichier /ecrire/mes_options.php3 les lignes suivantes :
define('_TIDY_COMMAND', 'tidy'); $xhtml
= true; |
Et vérifiez sur votre site public si les pages sont
modifiées (soit transformées en XHTML, soit affichage du message « Erreur
tidy »). Si cela ne fonctionne pas, pensez à supprimer ces deux lignes, et
essayez d’installer Tidy selon la méthode suivante (ou demandez à la personne
responsable de votre hébergement de le faire).
Vous pouvez installer une version déjà compilée de
Tidy correspondant à votre système.
— On trouvera ces versions sur le site officiel de Tidy ;
il en existe pour Linux, divers *BSD, MacOS X, etc.
— Décompressez l’archive téléchargée, et installez le fichier
« tidy » sur votre site.
— Vérifiez les droits d’exécution de ce fichier sur le serveur (si
nécessaire, passez les droits en « 777 »). (Si vous avez un accès SSH
à votre serveur, vous pouvez tester le programme directement depuis le
terminal. Si vous n’avez pas un tel accès, rien de grave, passez aux étapes suivantes,
sachant que vous serez plus démuni si cela ne fonctionne pas du premier coup.)
— Configurez l’accès à ce fichier en indiquant le chemin d’accès en le
définissant ainsi :
define('_TIDY_COMMAND',
'/usr/bin/tidy'); $xhtml = true; |
Si le chemin indiqué dans _TIDY_COMMAND est correct, alors Tidy sera déclenché lors des
affichages des pages de votre site public.
Important. La définition de _TIDY_COMMAND doit se trouver dans /ecrire/mes_options.php3 et non à la racine du site dans /mes_fonctions.php3. Cela est dû au fonctionnement assez spécifique du
système (post-traitement des fichiers tirés du cache de SPIP).
La partie $xhtml = true;, en revanche, fonctionne comme une « variable
de personnalisation » ; vous pouvez, si vous souhaitez faire des
essais ou restreindre le fonctionnement à une partie du site, définir cette
variable au niveau du fichier d’appel, par exemple article.php3 si vous ne voulez passer tidy que sur les
articles.
Encore une fois, il faut bien comprendre que Tidy n’est
capable de rendre conforme que du code qui est déjà, à l’origine, très propre.
Avec les squelettes livrés avec SPIP (eux-mêmes déjà conformes HTML 4) et
le code produit par défaut par SPIP, cela ne pose aucun problème : le code
est très proche du HTML 4 conforme (« compliant »), aussi
Tidy n’a aucun mal à en faire du XHTML 1.0 transitional parfaitement
conforme.
Lorsque Tidy a bien fonctionné, vous constatez dans le code source de
vos pages :
— que le « DOCTYPE » de votre page est devenu
« XHTML... »,
— que le code est joliment indenté,
— que l’ensemble passe la validation W3C sans difficulté.
Si le DOCTYPE n’est pas modifié, c’est que Tidy a
renoncé à corriger la page, dans laquelle il a rencontré des erreurs
impossibles (pour lui) à corriger.
Les erreurs peuvent avoir deux sources : les
squelettes, et le texte des articles.
Vos
squelettes ne sont eux-mêmes pas conformes ; dans ce cas, il faut
les corriger. C’est le cas le plus fréquent.
Vous pouvez, ici, commencer par désactiver Tidy
(passer la variable $xhtml
à false), et
passer vos pages au Validator en visant le conformité HTML 4.01
transitional (SPIP visant, dans ses traitements typographiques, cette
conformité, autant rester cohérent). Le W3C
Validator est un outil très pratique pour nettoyez son code.
Une fois vos squelettes aussi proches que possible
du HTML 4, Tidy n’aura pas de difficulté à produire du XHTML très
compliant. Si ces pages sont complètement conformes, c’est encore mieux !
(Et pas impossible : les squelettes livrés avec SPIP sont déjà conformes).
Certaines
articles contiennent des codes erronés
SPIP laissant les rédacteurs travailler en
« code source », ceux-ci peuvent insérer du code non conforme à
l’intérieur de leurs articles. (Par exemple, dans la documentation de www.spip.net, on trouve à certains endroits l’utilisation de
balises HTML <tt>...</tt> que Tidy considère comme inacceptables.)
Aussi, une fois les squelettes nettoyés, on pourra
chercher à corriger les textes de certains articles (cela concerne, donc, les
insertions de HTML directement dans les articles ; encore une fois, le
code produit par SPIP est essentiellement conforme, et ne provoque pas de
« blocage » de Tidy).
Pour cela, outre l’apparition, sur les pages
concernées, d’une bouton d’aministration intitulé « Erreur Tidy »,
SPIP tient à jour en
permanence un fichier /ecrire/data/w3c-go-home.txt qui contient la liste des pages impossibles à
valider [21]. Une fois vos squelettes rendus propres
(paragraphe précédent), le nombre de pages défaillantes devrait être limité aux
articles contenant du code HTML non accepté par Tidy.
Il est assez difficile de définir précisément ce
que Tidy considère comme une « erreur insurmontable ». Par exemple,
les balises mal fermées ne sont pas réellement considérées comme impossible à
corriger (par exemple, passer en italique dans un paragraphe et fermer
l’italique dans un autre paragraphe fabrique du code HTML non conforme, que
Tidy parvient cependant à bien corriger). Le plus souvent, il s’agit de balises
insérées à la main totalement inexistantes (par exemple : taper <bt> à la place de <br>), ou de balises HTML considérées comme obsolètes
dans le HTML 4 (telles que <tt> ou <blink>), que Tidy refusera purement et simplement de
traiter.
Encore une fois, l’outil Tidy ne doit surtout pas
être considéré comme un produit « miracle » : il ne transforme
pas du code sale en code conforme. Son intégration dans SPIP suit donc une
logique d’accompagnement d’un processus de nettoyage :
— SPIP lui-même continue à produire du code de
plus en plus propre ;
— Tidy sert alors à mettre la dernière touche
de nettoyage sur du code déjà très « compliant » (au passage, en
résolvant quelques incompatibilités difficiles à gérer avec un code unique
entre le HTML et le XHTML, telles que certaines balises auto-fermantes en
XHTML, et non fermées en HTML, telles que <br />) ;
— Tidy est ensuite utilisé pour identifier les
erreurs de codage dans le code source des articles eux-mêmes (lors de
l’insertion, assez fréquent, de code HTML « à la main » dans le corps
des articles).
Encore une fois, ces fonctionnalités sont toutes
récentes, et demandent sans doute des tests supplémentaires. N’hésitez pas à
faire part de votre expérience sur spip-dev.
Attention, cet article est vraiment destiné à des utilisateurs avancés, qui maîtrisent l’usage de LDAP et souhaitent appuyer SPIP sur un annuaire LDAP existant.
LDAP (Lightweight Directory Access Protocol) est un
protocole permettant d’interroger un annuaire contenant des informations
d’utilisateurs (nom, login, authentification...). Depuis la version [SPIP 1.5] il est possible de vérifier si un rédacteur
est dans la base LDAP avant de lui donner accès à l’espace privé.
A l’installation, SPIP détecte si PHP a été compilé
avec le support LDAP. Si oui, à la cinquième étape (« créer un
accès »), un bouton permet d’ajouter un annuaire LDAP à la configuration
SPIP. La configuration qui suit est relativement simple, elle essaie de deviner
les paramètres au maximum. Notamment, elle permet de choisir le statut par
défaut des auteurs venant de l’annuaire : ceux-ci peuvent être rédacteurs
(conseillé), administrateurs ou simples visiteurs.
Note : par défaut, l’extension LDAP de PHP n’est généralement pas activée, donc SPIP n’affichera pas le formulaire correspondant lors de l’installation. Pensez à activer l’extension LDAP dans votre installation de PHP si vous voulez utiliser LDAP avec SPIP.
Si SPIP est déjà installé et que vous voulez
configurer l’annuaire LDAP, il faudra reprendre l’installation en effaçant le
fichier ecrire/inc_connect.php3.
Une fois la configuration correctement effectuée,
tous les utilisateurs de l’annuaire LDAP seront identifiés en tapant leur login
(ou nom) dans l’annuaire LDAP, puis leur mot de passe. Notez que cela n’empêche
pas de créer directement des auteurs dans SPIP ; ces auteurs ne seront pas
recopiés dans l’annuaire mais gérés directement par SPIP. D’autre part les
informations personnelles (biographie, clé PGP...) des auteurs authentifiés depuis LDAP ne seront
pas non plus recopiées dans l’annuaire. Ainsi SPIP n’a besoin que d’un accès en
lecture seule à l’annuaire LDAP.
Important : créez toujours un premier administrateur
« normal » (non LDAP) lors de l’installation de SPIP. C’est
préférable pour éviter d’être bloqué en cas de panne du serveur LDAP.
Les infos de connexion au serveur LDAP sont écrites
dans inc_connect.php3. Corollaire : il faut supprimer ce fichier et relancer
l’installation pour activer LDAP sur un site SPIP existant.
Dans la table spip_auteurs, est ajouté un champ "source" qui
indique d’où viennent les infos sur l’auteur. Par défaut, c’est
"spip", mais ça peut aussi prendre la valeur "ldap". Ca
permet de savoir notamment quels champs ne doivent pas être changés : en
particulier, on ne doit pas autoriser la modification du login, car sinon il y
a une perte de synchronisation entre SPIP et LDAP.
A l’authentification, les deux méthodes sont
testées à la suite : SPIP puis LDAP. En fait un auteur LDAP ne pourra pas
être authentifié par la méthode SPIP (méthode standard avec challenge md5) car
le pass est laissé vide dans la table spip_auteurs. Un auteur SPIP, quant à lui, sera authentifié
directement depuis la table spip_auteurs. D’autre part, si le login entré ne vient pas de
SPIP, le mot de passe est transmis en clair.
Quand un auteur LDAP se connecte pour la première
fois, son entrée est ajoutée dans la table spip_auteurs. Les champs remplis sont : nom, login et
email qui viennent de LDAP (champs ’cn’, ’uid’ et ’mail’ respectivement) et le
statut dont la valeur par défaut a été définie à l’installation (rédacteur,
admin ou visiteur). Important : on peut modifier le statut par la suite,
afin de choisir ses admins à la main par exemple.
Une fois un auteur connecté, il est authentifié par
la voie classique, c’est-à-dire simplement avec le cookie de session. Ainsi on
ne se connecte à LDAP que lors du login (spip_cookie.php3). De même, les infos
prises en compte dans l’affichage et les boucles sont celles de spip_auteurs, pas celles de l’annuaire.
Pour les auteurs SPIP, rien ne change. On peut les
créer et les modifier comme à l’habitude.
[SPIP 1.8] permet d’utiliser les systèmes de traitement
d’images installés sur votre site d’hébergement. Introduites dans la version
1.7, ces fonctions de SPIP sont complétées et plus puissantes.
SPIP utilise le traitement d’images de trois
manières différentes :
— la création de vignettes de
pré-visualisation pour les images installées comme « documents
joints » ; cela était déjà présent dans la version 1.7 ; [SPIP 1.8] permet de plus, dans ces
« portfolios », de faire subir à chaque image une rotation à 90°
(cela est particulièrement intéressant lorsqu’on installe une série de
photographies depuis un appareil photo numérique) ;
— à de nombreux endroits dans l’espace privé,
l’affichage de « vignettes » destinées à illustrer la navigation, à
partir des logos des articles, des rubriques et même des auteurs (par exemple,
si l’on dote les participants à un site de logos d’auteurs, des vignettes de
ces logos accompagneront tous les messages de ces auteurs dans les forums de
l’espace privé) ;
— dans les squelettes, les webmestres
disposent d’une fonction reduire_image
particulièrement utile pour contrôler sa mise en page, et créer différentes
versions (de différentes tailles) d’une même image. Nous ne pouvons
qu’encourager les webmestres à « jouer » avec cette fonction pour
enrichir et contrôler leur interface graphique ; on en tirera avantage
pour obtenir :
Mais, pour réaliser ces opérations de traitement
d’images, SPIP fait appel à des systèmes qui ne peuvent pas être installés
automatiquement avec SPIP, mais doivent être présents sur le serveur qui
héberge votre site. Il faut donc que ces systèmes soient présents en plus de
SPIP (dit autrement : il ne suffit pas que SPIP soit installé pour que
les fonctions de traitement d’images soient disponibles ; il faut en fait
que ces fonctions soient présentes par ailleurs).
Le choix d’un système de traitement d’images se
fait dans la partie « Configuration » (configuration avancée) de
l’espace privé. SPIP permet de choisir parmi 5 méthodes différentes de
traitement des images.
Imagemagick
en tant qu’extension de PHP
(php-imagick) est le choix privilégié par SPIP. SPIP est capable de déterminer
seul sa présence. Si Imagemagick est présent sur votre serveur, alors SPIP
l’utilisera automatiquement.
Si Imagemagick n’est pas présent sur votre serveur,
alors SPIP vous proposera de choisir parmi d’autres méthodes. Ces méthodes
n’étant pas détectables par SPIP (et, en tout cas, pas parfaitement), une
vignette vous est proposée pour chaque méthode ou, éventuellement, pas de
vignette si la méthode ne fonctionne pas sur votre site. Vous êtes alors invité
à sélectionner votre méthode préférée (parfois : sélectionner la seule
réellement disponible !).
GD (et sa version
2, nettement plus puissante) est une extension de PHP
désormais fréquemment présente sur les serveurs, y compris les hébergeurs
mutualisés.
Si GD2 est présente, vous pouvez l’utiliser, elle
donne des résultats de bonne qualité.
En revanche, GD (comprendre : « version 1
de GD ») est proposée comme pis-aller : le traitement des images se
fait en 256 couleurs, et introduit de fortes dégradation des images ; elle
n’est donc à sélectionner que si aucune autre méthode ne fonctionne sur
votre site.
Convert est le
logiciel en ligne de commande de Imagemagick. La qualité est absolument
épatante, cependant son installation est relativement complexe.
Une fois convert installé sur votre site,
vous devez configurer le chemin d’accès dans mes_options.php3 (il s’agit d’un appel en ligne de commande) par la
variable suivante :
$convert_command =
'/bin/convert'; |
Il convient ici d’indiquer le chemin complet
d’accès au programme. Sous Linux, ce chemin est souvent
$convert_command
= '/bin/convert'; |
sous MacOS X, s’il est installé avec Fink :
$convert_command
= '/sw/bin/convert'; |
(ces valeurs sont fournies à titre indicatif ;
comme tout programme, il peut être installé quasiment n’importe où...).
Cette méthode consiste en trois programmes, déjà
anciens, qui permettent de réaliser le redimensionnement de l’image. L’avantage
de cette méthode est que ces programmes peuvent être installés sans accès root
sur la plupart des hébergements.
On trouvera, sur le site du logiciel gallery,
une
explication claire et des versions précompilées de NetPBM.
Dans SPIP, on configure le chemin d’accès à
pnmscale (l’un seulement des trois programmes installés - les deux autres
chemins s’en déduiront, puisque les programmes sont installés dans le même
répertoire) par la variable suivante :
$pnmscale_command
= '/bin/pnmscale'; |
(encore une fois, c’est-à-vous de déterminer le
chemin d’accès réel de votre installation).
* *
Pour rappel, vous pouvez obtenir nombre d’informations utiles sur
votre système via la page /ecrire/info.php3, notamment :
— le système utilisé (utile pour installer NetPBM précompilé) ;
— la version de PHP ;
— la présence éventuelle des extensions GD, GD2 et Imagemagick.
Enfin, en cas de difficulté, la meilleure solution
consiste à contacter votre hébergeur pour qu’il installe les extensions nécessaires
si aucune n’est présente. La présence d’au moins une extension graphique
de PHP est désormais une norme chez les hébergeurs, n’hésitez pas à demander
leur installation pour en bénéficier sur votre site.
[SPIP 1.8] introduit une puissante fonctionnalité permettant
d’insérer dans les textes des formules de mathématique complexes, en utilisant
la syntaxe de TEX/LaTEX.
Cette fonctionnalité permet par exemple d’afficher
une formule comme celle-ci :
en la codant directement dans le texte, comme on peut le faire avec TEX.
Notez bien : l’utilisation de cette méthode nécessite,
évidemment, de connaître la syntaxe des formules dans TEX. Syntaxe
qui n’est pas simple...
Le principe technique de cette méthode consiste à
transformer chacune des formules en image, image qui est ensuite
affichée dans le texte. C’est actuellement la méthode la plus simple et
efficace pour afficher des formules mathématiques complexes sur une page Web.
Pour l’heure, l’affichage de formules mathématiques
sur des pages Web grâce au standard MathML n’est absolument pas viable,
l’implémentation de MathML dans les navigateurs étant totalement erratique. La
solution retenue par SPIP (l’intégration d’images représentant les formules)
est actuellement la seule qui garanti que tous les visiteurs d’un site
verront correctement les formules mathématiques.
Il est important de comprendre que, dans SPIP, seules
les formules sont transformées. Il n’est pas question, en particulier,
d’utiliser les macro-fonctions de TEX pour réaliser la mise en forme
du document. Il s’agit ici d’un outil destiné à intégrer des formules
mathématiques à l’intérieur d’un document codé selon les habitudes de SPIP.
La syntaxe dans SPIP consiste à placer la partie de
texte concernée par le traitement entre les pseudo-tags suivants :
<math>
...
Ici on extrait les formules
mathématiques...
... </math> |
Puisque seules les formules mathématiques sont
traitées, on peut en réalité ajouter <math>...</math> de manière très large (en clair : on peut
ajouter <math> tout au début du texte, et </math> tout à la fin...).
La seule incompatibilité sera le cas où l’on
souhaite afficher le symbole « dollar » dans le texte, ce symbole
étant utilisé pour délimiter les formules. (C’est la raison, en réalité, de
l’existence des codes <math></math>.)
À l’intérieur de ces pseudo-tags, on code ensuite
les formules de mathématiques selon les normes de TEX, en les encadrant de
dollars ou de double-dollars pour les formules centrées.
Voici un exemple :
On peut insérer des matrices : ;
on peut placer des fractions, telles que
,
;
utiliser des lettres grecques
,
,
,
,
;
centrer des
formules complexes :
que l’on pourra coder ainsi :
On peut insérer des matrices: $\pmatrix{1&0&0\cr 0&a&0\cr
0&0&b\cr}$; on peut placer des fractions, telles que
${1\over z}$, ${1\over\displaystyle 1+{1\over x}}$; utiliser des lettres grecques $\alpha$,
$\beta$, $\gamma$, $\Gamma$,
$\varphi$; centrer des
formules complexes: $$\left|{1\over N}\sum_{n=1}^N \gamma(u_n) -{1\over 2\pi}\int_0^{2\pi}\gamma(t){\rm
d}t\right| \le {\varepsilon\over 3}.$$ |
Le système est limité à l’affichage de formules
mathématiques. De ce fait, toutes les autres fonctions de TEX sont
désactivées. Parmi la plus importante interdiction : il n’est pas
possible de définir ses propres macros (\def...{...} est
désactivé) et les macros utilisées en dehors des formules mathématiques ne
seront pas reconnues. À l’usage, on trouvera d’autres limitations, en se
souvenant toujours que le but est d’intégrer des formules mathématiques dans
ses textes, et rien de plus...
Le traitement des équations se fait sur le mode client-serveur : les formules sont envoyées à un serveur
centralisé, qui retourne à votre site les fichiers graphiques de ces équations.
(Évidemment, les fichiers sont sauvegardés sur votre système, et l’échange n’a
lieu qu’une seule fois par équation.)
Pour plus d’informations sur le système utilisé,
vous pouvez consulter la page du Wiki
de SPIP. Vous y trouverez notamment les explications pour monter votre propre
serveur d’équations, afin de ne plus dépendre de notre serveur central.
L’interface graphique de l’espace privé a été, dans la version 1.8, largement remaniée. Au delà de l’aspect purement graphique de l’interface (qu’il est inutile de détailler), nous présentons ci-dessous quelques-uns des éléments d’ergonomie introduits, destinés à faciliter le travail à la fois des utilisateurs débutants et des utilisateurs confirmés.
L’une des principales tâches effectuées sur cette
version a consisté à tenter de réduire le nombre de clics nécessaires pour
accéder aux différentes pages. Il est destiné à la fois aux utilisateurs confirmés
(ils « gagnent » du temps) mais aussi aux utilisateurs débutants en
rendant visible toutes les informations nécessaires (telle page n’est pas
« cachée » comme sous-option d’une autre page, elle est accessible
directement).
Évidemment, on a tenté ici, selon l’habitude de
SPIP, de ne pas rendre plus confuse l’interface pour les débutants en voulant
faciliter le travail des utilisateurs confirmés.
La modification la plus visible par rapport aux
versions précédentes (depuis la version 1.4) est la disparition du second
bandeau de navigation. Désormais tous les éléments de ce « second
bandeau » apparaissent en « popup » par survol des éléments
principaux (eux-mêmes réorganisés selon des principes simplifiés — comme un
retour à l’interface de SPIP 1.0 !). Ainsi chacune des pages de ce
« second bandeau » devient accessible en un clic depuis toutes les
pages de l’espace privé.
Selon la même logique, le « bandeau coloré » accueille,
outre les options d’interface (couleur, taille de l’écran, etc.), quelques
popups récapitulant en permanence certaines informations utiles :
une
navigation dans l’intégralité de la hiérarchie des rubriques, par un système de
menus déroulants,
un
rappel des articles en cours de rédaction et proposés à la publication, ainsi
qu’un des boutons « créer un article, une brève... »,
l’interface
de recherche,
les
raccourcis liés au calendrier interne et à la messagerie.
À différents endroits de l’interface (notamment sur
la page « À suivre »), on pourra repérer des petits boutons
« Plus ». Destinés aux utilisateurs confirmés (l’absence de
descriptif explicite de ces boutons faisant qu’on en découvre l’usage au fur et
à mesure), ils envoient à des pages spécifiques. Par exemple, à côté d’une
liste d’articles, ce bouton mène à la page « Tous vos
articles » ; à côté d’une liste de brèves, le bouton mène à la page
de gestion des brèves, etc.
Une interface de changement de statut à l’intérieur
même des listes (d’articles, notamment) permet aux administrateurs de modifier
le statut d’une série d’éléments sans changer de page. Cette manipulation,
immédiate, permet de changer, par exemple, le statut de tous les articles d’une
même rubrique (tous les publier, tous les dépublier) sans changer de page.
Si vous disposez de fonctions
de traitement d’images sur votre serveur, SPIP peut en tirer partie pour
« illustrer » graphique l’espace privé :
vignettes
des logos dans les listes d’articles, brèves, sous-rubriques,
vignettes
des auteurs dans les forums internes.
Ces fonctions graphiques rendent l’interface plus
agréable, mais aussi plus lisible (les éléments des listes étant ainsi mieux
différenciés graphiquement par l’affichage d’un petit logo).
Ces fonctions permettent aussi d’effectuer des
rotations de photographies dans la nouvelle interface de portfolio.
Outre les changements graphiques de l’interface du calendrier interne,
on remarquera l’apparition de cinq petits boutons de réglage ergonomique :
les
petites horloges permettent de développer plus ou moins l’affichage de la
matinée ou de l’après-midi ;
des
loupes « plus » et « moins » permettent de zoomer sur cet
affichage.
SPIP 1.8 introduit une version nouvelle de
l’interface, destinée aux malvoyants. Par rapport à la version
« texte » de l’interface (introduite dans SPIP 1.4), cette nouvelle
interface est nettement « allégée » (l’interface « texte »
de l’interface, elle, convient aux connexions relativement lentes, mais pour
une lecture à l’écran par un utilisateur voyant).
On peut accéder à cette interface par l’adresse /ecrire/oo, ou bien en suivant le lien « Afficher
l’interface textuelle simplifiée » qui apparaît sur les butineurs ne
comprenant pas Javascript.
Il est possible de revenir à l’interface habituelle
en suivant le lien proposé en bas de page (« Retour à l’interface
graphique complète »). Notez qu’alors vous revenez en interface dite
« simplifiée ».
L’équipe des développeurs (liste de discussion spip-dev) est très intéressée par des retours d’expérience
de la part d’utilisateurs concernés par cette interface. Nous manquons
cruellement de témoignages pour améliorer le système en fonction de tels
utilisateurs.
On notera que cette interface est également
particulièrement adaptée aux connexions sur supports mobiles dotés de
connexions très lentes et/ou d’écrans de petite taille (smartphones, PDA
communiquants).
La zone « Texte » du formulaire de
modification d’articles s’adapte pour occuper toute la hauteur de la fenêtre.
Ce qui, dès qu’on utilise une définition d’écran supérieure à 800x600, permet
d’agrandir notablement l’espace pour saisir son texte.
Selon le même principe, les fenêtres de
« Navigation rapide » occupent toute la hauteur de l’écran.
De nombreux formulaires deviennent
dynamiques : des boutons de validation, des cases de sélection, ainsi que
des zones de texte, apparaissent ou disparaissent en fonction des choix des
utilisateurs.
Ainsi, dans l’affichage d’un article, certains
boutons de « Validation » n’apparaissent que lorsqu’on modifie le
menu déroulant attenant. On pourra également voir de tels formulaires dans
l’espace de configuration du site (par exemple, dans la zone
« Référencement de sites », selon qu’on sélectionne « Gérer un
annuaire de sites Web » ou « Déselectionner », et « Utiliser
la syndication » ou non, on voit les options de
configuration changer immédiatement).
Les pages d’affichage des statistiques ne changent
pas dans leur principe. On notera l’apparition de boutons de « zoom »
pour l’évolution des statistiques.
Les pages des « répartitions de visites »
devient nettement plus compréhensible !
Les adeptes de HTML pourront se demander comment
les grandes icônes de navigation de l’espace privé changent de couleur selon le
choix de l’utilisateur. Cet effet est réalisé en utilisant des icônes au format
PNG 24, et en profitant de la transparence fine autorisée par ce format (couche
alpha).
Or, il est habituellement expliqué que Microsoft
Explorer est incapable d’exploiter la couche alpha du PNG24. L’espace privé de
SPIP utilise une astuce permettant cependant de faire utiliser cette couche
alpha par Microsoft Explorer. Les webmestres intéressés pourront
avantageusement l’exploiter pour la partie publique de leur site, lors de la
création de leurs propres squelettes...
Il convient de créer une classe de style, classe
que l’on attribuera aux images concernées (notez bien : on peut appliquer
sans risque cette classe à des images dans d’autres formats que le PNG, la
classe sera alors simplement inutile, mais sans déterioration de ces images).
Cette classe pourra se définir ainsi :
.format_png {
behavior: url("win_png.htc"); } |
qu’on applique dans les balises <img
src="..." class="format_png">.
On constate que cette classe utilise une
caractéristique de Microsoft Explorer, l’appel d’un behavior. Celui-ci est un fichier Javascript, présent dans l’espace privé (/ecrire/win_png.htc), que l’on recopie à la racine du site pour
l’exploiter en dehors de l’espace privé.
En ouvrant ce fichier de comportement (behavior), on verra qu’il fait appel à un fichier /img_pack/rien.gif dans son fonctionnement. On doit donc recopier ce
fichier à la racine du site (depuis /ecrire/img_pack/rien.gif), et remplacer le chemin dans la version de win_png.htc installée à la racine du site.
Les goûts et les couleurs...
Les couleurs de l’interface peuvent être complétées
d’autres couleurs, ou remplacées. Pour cela, il suffit d’installer des
variables dans un fichier /ecrire/mes_options.php3 :
global $couleurs_spip; $couleurs_spip[1] = array ( "couleur_foncee" =>
"#508A72", "couleur_claire" =>
"#A5DFC7", "couleur_lien" =>
"#657701", "couleur_lien_off" =>
"#A6C113" ); $couleurs_spip[] = array ( "couleur_foncee" =>
"#949064", "couleur_claire" =>
"#DFDBA5", "couleur_lien" =>
"#657701", "couleur_lien_off" =>
"#A6C113" ); |
Ici, on a remplacé le vert (variable
« 1 » ; les couleurs de l’installation normale sont numérotées
de 1 à 6, on peut donc toutes les modifier), et ajouté une nouvelle couleur ($couleurs_spip[] indiquant qu’on ajoute une valeur au tableau (array) $couleurs_spip.
La structure de la base de données est assez simple.
Certaines conventions ont été utilisées, que vous repérerez assez facilement au
cours de ce document. Par exemple, la plupart des objets sont indexés par un
entier autoincrémenté dont le nom est du type id_objet, et qui est déclaré comme clé primaire dans la
table appropriée.
NB : cet article commence à dater, et personne
n’a encore pris la peine d’en faire la mise à jour. Il faut le lire comme un élément permettant de
comprendre le fonctionnement de SPIP, mais plus comme un outil de référence. Si
vous souhaitez contribuer à la documentation en refondant cet article, surtout
n’hésitez pas !
Les rubriques : spip_rubriques
Chaque
rubrique est identifiée par son id_rubrique.
id_parent est l’id_rubrique de
la rubrique qui contient cette rubrique (zéro si la rubrique se trouve à la
racine du site).
titre, descriptif,
texte parlent d’eux-mêmes.
id_secteur est l’id_rubrique de
la rubrique en tête de la hiérarchie contenant cette rubrique. Une rubrique
dépend d’une rubrique qui dépend d’une rubrique... jusqu’à une rubrique placée
à la racine du site ; c’est cette dernière rubrique qui détermine l’id_secteur. Cette
valeur précalculée permet d’accélérer certains calculs de l’espace public (en
effet, les brèves sont classées par secteur uniquement, et non selon toute la
hiérarchie).
maj est
un champ technique mis à jour automatiquement par MySQL, qui contient la date de la dernière
modification de l’entrée dans la table.
export, id_import
sont des champs réservés pour des fonctionnalités futures.
Les articles : spip_articles
Chaque
article est identifié par son id_article.
id_rubrique indique dans quelle rubrique est rangé
l’article.
id_secteur indique le secteur correspondant à la
rubrique susmentionnée (voir le paragraphe précédent pour l’explication de la
différence entre les deux).
titre, surtitre,
soustitre, descriptif, chapo,
texte, ps parlent d’eux-mêmes.
date
est la date de publication de l’article (si l’article n’a pas encore été
publié, c’est la date de création).
date_redac
est la date de publication antérieure si vous réglez cette valeur, sinon elle
est égale à « 0000-00-00 ».
statut
est le statut actuel de l’article : prepa
(en cours de rédaction), prop (proposé à la
publication), publie (publié), refuse (refusé), poubelle
(à la poubelle).
accepter_forum :
permet de régler manuellement si l’article accepte des forums (par défaut,
oui).
maj :
même signification que dans la table des rubriques.
export
est un champ réservé pour des fonctionnalités futures.
images est
un champ contenant la liste des images utilisées par l’article, dans un format
particulier. Ce champ est généré par spip_image.php3.
visites
et referers
sont utilisés pour les statistiques sur les articles. Le premier est le nombre
de chargements de l’article dans l’espace public ; le deuxième contient un
extrait de hash des différents referers, afin de connaître le nombre de
referers distincts. Voir inc-stats.php3.
Les auteurs : spip_auteurs
Chaque
auteur est identifié par son id_auteur.
nom, bio,
nom_site, url_site, pgp
sont respectivement le nom de l’auteur, sa courte biographie, son adresse
e-mail, le nom et l’URL de son site Web, sa clé PGP. Informations modifiables
librement par l’auteur.
email, login
sont son e-mail d’inscription et son login. Ils ne sont modifiables que par un
administrateur.
pass
est le hash MD5 du mot de passe.
htpass est
la valeur cryptée (i.e. générée par crypt()) du mot de passe pour le
.htpasswd.
statut
est le statut de l’auteur : 0minirezo
(administrateur), 1comite (rédacteur), 5poubelle (à la poubelle), 6forum
(abonné aux forums, lorque ceux-ci sont réglés en mode « par abonnement »).
maj
a la même signification que dans les autres tables.
Les brèves : spip_breves
Chaque
brève est identifiée par son id_breve.
id_rubrique est la rubrique (en fait, le secteur) dans
laquelle est classée la brève.
titre, texte,
lien_titre, lien_url sont le titre, le
texte, le nom et l’adresse du lien associé à la brève.
date_heure
est la date de la brève.
statut
est le statut de la brève : prop
(proposée à la publication), publie
(publiée), refuse (refusée).
maj :
idem que dans les autres tables.
Les mots-clés : spip_mots
Chaque
mot-clé est identifié par son id_mot.
Le
type
du mot-clé est le type, ou groupe, choisi pour le mot-clé. En définissant
plusieurs types, on définit plusieurs classifications indépendantes (par
exemple « sujet », « époque », « pays »...).
titre, descriptif,
texte parlent d’eux-mêmes.
maj :
idem que dans les autres tables.
Les sites syndiqués : spip_syndic
Chaque
site syndiqué est identifié par son id_syndic.
id_rubrique et id_secteur définissent l’endroit dans la hiérarchie du
site où viennent s’insérer les contenus syndiqués.
nom_site, url_site,
descriptif sont le nom, l’adresse et le descriptif du
site syndiqué.
url_syndic
est l’adresse du fichier dynamique utilisé pour récupérer les contenus
syndiqués (souvent il s’agit de url_site suivi de backend.php3).
Les articles syndiqués : spip_syndic_articles
Chaque
article syndiqué est identifié par son id_syndic_article.
id_syndic
réfère au site syndiqué d’où est tiré l’article.
titre, url,
date, lesauteurs parlent d’eux-mêmes.
Les messages de forums : spip_forum
Chaque
message de forum est identifié par son id_forum.
L’objet
auquel est attaché le forum est identifié par son id_rubrique, id_article ou id_breve. Par défaut,
ces valeurs sont égales à zéro.
Le
message parent (c’est-à-dire le message auquel répond ce message) est identifié
par id_parent. Si le
message ne répond à aucun autre message, cette valeur est égale à zéro.
titre, texte,
nom_site, url_site sont le titre et le
texte du message, le nom et l’adresse du lien y attaché.
auteur
et email_auteur
sont le nom et l’e-mail déclarés par l’auteur. Dans le cas des forums par
abonnement, ils ne sont pas forcément identiques aux données enregistrées dans
la fiche de l’auteur (i.e. dans la table spip_auteurs).
id_auteur identifie l’auteur du message dans le cas de
forums par abonnement.
statut
est le statut du message : publie
(lisible dans l’espace public), prive
(écrit en réaction à un article dans l’espace privé), privrac (écrit dans le forum interne dans l’espace privé),
off (supprimé ou à valider, selon la
modération des forums - a priori ou a posteriori).
ip est
l’adresse IP de l’auteur, dans les forums publics.
maj
a la même signification que dans les autres tables.
Les pétitions : spip_petitions
id_article identifie l’article auquel est associée la
pétition (une seule pétition par article).
email_unique, site_obli,
site_unique, message définissent la
configuration de la pétition : l’adresse e-mail des signataires doit-elle
être unique dans les signatures, l’adresse Web est-elle obligatoire, est-elle
unique, un message attenant aux signatures est-il autorisé (oui ou non).
texte est
le texte de la pétition.
maj :
pareil que dans les autres tables.
Les signatures de pétitions : spip_signatures
Chaque
signature est identifiée par son id_signature.
id_article identifie l’article, donc la pétition
sur laquelle est apposée la signature.
nom_email, ad_email, nom_site,
url_site sont le nom, l’adresse e-mail, ainsi que le
site Web déclarés par le signataire.
message
est le message éventuellement entré par le signataire.
statut
est le statut de la signature : publie
(acceptée), poubelle (supprimée) ;
toute autre valeur donne la valeur de la clé de validation utilisée pour la
confirmation par e-mail.
maj
a la même signification que dans les autres tables.
Ces tables ne gèrent aucun contenu, simplement une
relation entre les objets présents dans d’autres tables. Ainsi :
spip_auteurs_articles spécifie la relation entre auteurs et articles. Si
un id_auteur y est
associé à un id_article, cela veut dire que l’auteur en question a écrit
ou co-écrit l’article (il peut y avoir plusieurs auteurs par article, et
vice-versa bien sûr).
spip_mots_articles définit de même la relation de référencement des
articles par des mots-clés.
La table spip_meta est primordiale. Elle contient des couples (nom, valeur)
indexés par le nom (clé primaire) ; ces couples permettent de stocker
différentes informations telles que la configuration du site, ou la version
installée de SPIP.
La table spip_forum_cache est utilisée afin d’adapter le système de cache à
l’instantanéité des forums. Pour chaque fichier du cache ayant donné lieu à une
requête sur la table spip_forum, la table spip_forum_cache stocke les
paramètres de la requête (article, rubrique, brève et éventuel message parent
du forum). Lorsqu’un message est posté, les paramètres du message sont comparés
avec ceux présents dans spip_forum_cache, et pour chaque correspondance trouvée
le fichier cache indiqué dans la table est effacé. Ainsi les messages
n’attendent pas le recalcul régulier de la page dans laquelle ils s’insèrent
pour apparaître dans l’espace public.
Six tables sont utilisées par le moteur de
recherche. Elles se divisent en deux catégories.
Le dictionnaire d’indexation : spip_index_dico
Chaque mot rencontré au cours de l’indexation est
stocké dans cette table, ainsi que les 64 premiers bits de son hash MD5. C’est
le mot qui sert de clé primaire, permettant ainsi d’effectuer très rapidement
des requêtes sur un début de mot ; on récupère alors le(s) hash
satisfaisant à la requête, afin d’effectuer la recherche proprement
dite dans les tables d’indexation.
Les tables d’indexation : spip_index_*
Ces tables, au nombre de cinq, gèrent chacune
l’indexation d’un type d’objet : articles, rubriques, brèves, auteurs,
mots-clés. Une entrée par mot et par objet est stockée. Chaque entrée contient
le hash du mot (en fait les 64 bits de poids fort du hash MD5, cf. ci-dessus), l’identifiant
de l’objet indexé (par exemple l’id_article pour un article), et le nombre de points associé à
l’indexation du mot dans l’objet. Ce nombre de points est calculé en fonction
du nombre d’occurences du mot, pondéré par le champ où ont lieu les
occurences : une occurence dans le titre d’un article génère plus de
points qu’une occurence dans le corps de l’article.
Le mécanisme d’indexation est expliqué plus en
détail ici.
Pour tirer parti de toute la souplesse de SPIP, il
est recommandé d’utiliser les feuilles de style. Pas de panique, cette petite
initiation permettra aux débutants de raccrocher les wagons...
Cette présentation considère que vous connaissez le
système des squelettes SPIP et que vous êtes capables de comprendre des
squelettes simples. Dans le cas contraire, nous vous conseillons de relire le tutorial et/ou le manuel de référence.
Si vous réalisez des pages Web de manière
« traditionnelle », les indications graphiques sont insérées dans le
code HTML de votre page. Ainsi à chaque fois que vous voulez mettre un texte en
rouge, vous écrivez <font color="red">. Pour afficher un tableau avec des bordures
épaisses, vous écrivez <table border="2">.
Avec cette méthode et un site statique (où chaque
article a une page HTML spécifique), changer la maquette de tout un site est un
cauchemar : il faut dans tous les fichiers HTML rechercher les morceaux de
HTML à modifier, et effectuer les modifications une par une (par exemple
remplacer <font
color="red"> par <b> si l’on décide que les éléments anciennement
affichés en rouge seront désormais en gras).
Comme vous le savez déjà, SPIP améliore beaucoup la
situation : vous n’avez plus à modifier des centaines de fichiers HTML,
juste quelques squelettes ; et votre mise en page est remise à jour automatiquement sur l’ensemble du site. Cependant le problème
n’est pas entièrement résolu. Par exemple, mettons que vous ayez décidé
d’employer un certain bleu pastel sur beaucoup d’éléments du site, afin de donner
une identité graphique à votre site : les liens, les encarts, certains
éléments de navigation... sont affichés en bleu pastel. Le jour où vous voudrez
remplacer ce bleu pastel par un vert pâle, vous devrez modifier tous les
endroits du squelette où ce bleu apparaissait pour le remplacer par le vert
pâle. Cela peut être décourageant : il n’est pas aisé dans ces conditions
de changer rapidement le rendu des pages, ne serait-ce que pour faire des
essais.
La solution réside dans l’utilisation des feuilles
de style. Une feuille de style est un fichier où vous définissez un ensemble de
propriétés graphiques, et les endroits où elles s’appliquent. On note deux
avantages capitaux des feuilles de style :
la
feuille de style est un fichier unique et centralisé, que vous pouvez
appliquer à autant de fichiers HTML (et de squelettes SPIP) que vous le
désirez ;
les
propriétés graphiques sont définies une seule fois dans la feuille de style,
quel que soit le nombre d’endroits où ces propriétés sont appliquées dans le
HTML.
La feuille de style, lorsque vous l’appliquez à un
fichier HTML (qui peut être un squelette SPIP), doit être déclarée dans le tag <head> du fichier HTML - aux côtés du titre et autres
champs <meta>. De la façon suivante :
<head>
...
<link
rel="stylesheet" type="text/css"
href="mes_styles.css">
</head>
Ici le fichier mes_styles.css contient les propriétés graphiques que je veux
appliquer à la page HTML (dans toute la suite du tutorial, on supposera que mes_styles.css est le nom que vous avez choisi pour ce fichier).
Ce fichier porte l’extension « css ». En effet, CSS [22] est le nom du langage utilisé pour les feuilles de
style, de la même manière que HTML est le nom du langage
utilisé pour la réalisation de pages Web.
Note : une feuille de style peut s’appliquer
aussi bien à une page HTML classique (« statique ») qu’à un squelette
SPIP. Cela veut dire que toute astuce CSS valable dans du HTML classique sera
aussi utilisable dans un squelette de votre site...
Si vous avez bien lu les paragraphes précédents,
vous serez peut-être dubitatifs : oui, il faut apprendre un nouveau
langage pour utiliser les feuilles de styles (SPIP n’y est pour rien !).
Les CSS n’utilisent pas, en effet, la syntaxe du HTML. Cependant ce langage est
très simple, et il suffit de quelques exemples pour se mettre le pied à
l’étrier...
Dans l’article précédent, nous
avons exposé de manière générale les avantages des feuilles de style. Ici nous
expliquons les apports supplémentaires des feuilles de style lorsqu’elles sont
utilisées en conjonction avec SPIP.
Comme vous le savez désormais, les feuilles de
style permettent de centraliser et de gérer de manière beaucoup plus aisée les
indications graphiques que l’on insérait traditionnellement dans le HTML. Cela
rend leur utilisation appréciable, sans être forcément indispensable :
vous pouvez continuer à insérer, par endroits, des indications graphiques
directement dans le HTML tout en utilisant aussi une feuille de style.
Dans SPIP, les feuilles de style acquièrent une
fonction supplémentaire, fondamentale : elles servent à modifier les
propriétés graphiques des éléments qui ne sont pas définis dans votre
HTML (celui de votre squelette) ! En effet, SPIP génère de lui-même une
multitude de styles d’affichage divers et variés. Ainsi, les raccourcis
typographiques (liens hypertexte, intertitres, gras, italique, tableaux...)
sont transformés en code HTML afin de les représenter à l’écran. Cela vaut
aussi pour les formulaires automatiques (répondre à un forum, signer une
pétition...) et d’autres encore.
Afin que vous puissiez tout de même modifier
l’apparence graphique de ces styles, SPIP leur donne un nom spécifique,
immuable (ces noms font l’objet d’une liste exhaustive dans « Spip et les feuilles de style »).
Par exemple, les {{{intertitres}}} ne génèrent pas un simple tag <h3>,
mais un tag <h3 class="spip">. Quel est l’intérêt ? Ces tags portent un nom
spécifique dans l’attribut class : ce nom définit à quelle
« classe » ils appartiennent, c’est-à-dire un ensemble d’éléments
HTML qui hériteront des mêmes propriétés graphiques définies dans la feuille de
style.
Comment fait-on alors pour changer l’apparence de
tous les intertitres SPIP ? C’est très simple, il suffit d’ouvrir votre
fichier mes_styles.css (ou tout autre nom que vous avez décidé de lui donner) dans un
éditeur de texte et d’y ajouter les lignes suivantes :
h3.spip {
color: red;
font-size: 18px;
}
Rechargez la page et tous les intertitres SPIP
apparaîtront comme par magie en rouge ; remarquez de plus que les autres
tags <h3> de votre page, s’il y en a, ne sont pas affichés en rouge...
Si rien de tout cela n’apparaît, vérifiez bien que vous avez déclaré la feuille
de style dans le squelette (dans le tag <head> comme expliqué dans l’article précédent), et
recalculez la page...
Expliquons brièvement la syntaxe de cette règle de
mise en page :
h3.spip juste avant les accolades signifie que la règle
qui suit ne s’appliquera qu’aux tags <h3> qui ont un attribut class égal à « spip ». Notez bien : ni les tags <h3> n’ayant pas cet attribut, ni les tags ayant cet
attribut sans être des tags <h3>, ne seront concernés.
Les
accolades contiennent la liste des propriétés graphiques associées au style
ainsi définies. Notons que toutes les propriétés non définies dans cette liste
garderont leur valeur habituelle pour le tag considéré ; dans le cas
présent, le tag <h3> générera toujours un texte en gras, car rien dans
le style ne dit le contraire.
Les
propriétés listées entre accolades sont chacune terminées par un point-virgule.
Elles sont constituées d’un nom (ce nom est standardisé par le langage CSS),
suivi d’un deux-points et d’une ou plusieurs valeurs. Ici nous voyons que la
couleur est réglée à rouge et que la police de caractères doit être affichée
avec une taille de 18 pixels.
Important : si vous ajoutez vos propres styles, sachez que la
valeur donnée à l’attribut class
est totalement arbitraire. Votre navigateur ne fera aucune différence, que cet
attribut soit nommé spip,
menu-rubriques ou cheval321. La seule chose qui compte est que cette valeur
corresponde bien à la règle que vous aurez énoncée dans votre feuille de style.
Comme vous le remarquerez, le langage CSS est très
simple et utilise le même type de vocabulaire que les attributs HTML
classiques. Quand vous progresserez dans le langage des feuilles de style, vous
continuerez à retrouver des notions plus ou moins héritées du HTML traditionnel
(border, width, height...).
Le fait que votre feuille de style soit définie
dans un fichier séparé (le fameux mes_styles.css) a une conséquence importante. En effet, ce
fichier, au contraire de vos squelettes n’est pas géré par SPIP (il n’en a pas
besoin !). Cela signifie que si vous modifiez votre feuille de
style, vous n’avez pas besoin de vider le cache de SPIP : il suffit de
recharger la page dans votre navigateur. Cela rend le réglage de la
mise en page encore plus aisé.
Rappelons tout de même que votre feuille de style
doit être déclarée dans vos fichiers HTML, et que ceux-ci doivent être
recalculés une première fois pour que cette déclaration soit prise en
compte : la ligne <link rel="stylesheet"
type="text/css" href="mes_styles.css"> doit se trouver « dans le cache » pour
que votre navigateur puisse en tenir compte.
Après une introduction générale sur les feuilles de
style, nous allons maintenant passer en revue quelques-uns de leurs usages les
plus courants sous SPIP.
Intéressons-nous ici aux styles créés lorsque des
raccourcis typographiques sont insérés dans un texte entré sous SPIP. Que l’on
affiche un article, une brève, une rubrique ou autre n’a aucune importance :
les styles portent toujours les mêmes noms. Cela ne nous empêchera pas de
découvrir comment y appliquer éventuellement des habillages graphiques
distincts...
Même le texte de base sous SPIP, celui que vous
entrez dans un formulaire en tapant au kilomètre, génère des tags HTML
particuliers. En effet, il est découpé en paragraphes ; à chaque
paragraphe correspond un tag <p
class="spip">. Nous pouvons donc associer à ces paragraphes un
style bien précis, qui ne sera pas appliqué au reste du texte de la page.
Commençons par choisir une police de caractères.
Pour cela on utilise la propriété font-family,
qui prend pour valeur un ou plusieurs noms de polices de caractères à utiliser.
Pour un corps de texte comme celui d’un article il vaut mieux une fonte à
empattements ; mettons que vous vous décidiez pour « Bookman
Old Style ». Ajoutez donc à votre
fichier mes_styles.css la règle suivante :
p.spip {
font-family: "Bookman Old
Style";
}
(notez qu’un nom de fonte en plusieurs mots doit
être entouré de guillemets...) Un problème peut survenir si la police « Bookman
Old Style » n’est pas installée
sur l’ordinateur de vos visiteurs : chaque ordinateur a une configuration
différente, et n’oubliez pas que les fontes « gratuites » de Microsoft
sont rarement installées sur Linux et Macintosh... Il est préférable de prévoir
ce cas et spécifier une ou plusieurs polices de remplacement successives :
p.spip {
font-family: "Bookman
Old Style", "Times New Roman", serif;
}
On spécifie ici comme remplaçantes successives de
Bookman, la classique « Times
New Roman », et en dernier
recours « serif ». « serif » n’est pas une
police en soi, c’est un code générique qui indique au navigateur de prendre la
police à empattements par défaut de l’ordinateur ; de même « sans-serif » spécifie la police sans empattements par
défaut (en général Arial ou Helvetica).
On retiendra cette règle importante : dans la
propriété font-family, il convient toujours de proposer plusieurs choix
successifs pour s’adapter aux polices de caractères installées sur l’ordinateur
du visiteur. Notons que cette règle est aussi valable pour le tag <font face="..."> du HTML traditionnel.
Bien évidemment d’autres propriétés sont à votre
disposition. Vous pouvez par exemple régler la taille du texte avec la
propriété font-size. Notez cependant que les navigateurs disposent d’un réglage pour
configurer la taille du texte par défaut, et le texte principal de vos pages ne
devrait pas outrepasser ce réglage, pour des raisons de confort visuel :
c’est l’utilisateur qui choisit la taille de base, non le webmestre.
Notez bien que les styles que vous appliquez aux
tags <p> s’appliquent à chaque paragraphe en tant qu’objet autonome. Cela
autorise certains effets intéressants, comme par exemple d’indenter la première
ligne des paragraphes en utilisant la propriété text-indent. Par défaut, cette propriété prend pour valeur
zéro, c’est-à-dire qu’il n’y a pas d’indentation. On peut la modifier pour
obtenir, sur chaque première ligne, un décalage de soixante pixels à
droite :
p.spip {
text-indent: 60px;
}
Ceux qui ont déjà réalisé leurs premières armes en
CSS savent qu’on peut modifier l’habillage des liens de façon globale :
a {
color: green;
text-decoration: none;
}
Cette règle de style spécifie que tous les liens
hypertexte (c’est-à-dire tous les tags <a ...>, qu’ils aient ou non un attribut class) seront affichés en vert sans soulignement.
SPIP permet d’aller plus loin. Les liens
hypertexte, lorsqu’ils sont générés par les raccourcis typographiques,
utilisent en effet plusieurs styles différents :
lorsque
le lien est interne (il renvoie vers une autre page de votre site), le tag est <a
class="spip_in"> ;
lorsque
le lien est externe (il renvoie vers un autre site Web), le tag est <a
class="spip_out">
[23];
enfin,
lorsque l’URL est entrée sans titre, le tag est <a
class="spip_url">.
Il devient donc très simple de manifester par une
apparence graphique différente ces trois types de liens. Ainsi :
a {
color: green;
text-decoration: none;
}
a.spip_in {
color: blue;
}
a.spip_out {
color: red;
}
affiche les liens internes en bleu et les liens
externes en rouge. Tous les autres liens, y compris ceux qui ne sont pas
générés par SPIP, s’afficheront en vert. De plus tous les liens seront
affichées sans surlignement : en effet la propriété text-decoration, spécifiée dans la première règle, n’a pas été
modifiée dans les suivantes ; elle s’applique donc automatiquement à tous
les éléments de type <a ...>.
On note ici une propriété fondamentale des feuilles
de style : les règles graphiques s’appliquent dans l’ordre allant de la
plus générique à la plus spécifique. Cela permet de spécifier un comportement
général pour la plupart des éléments, et de modifier ce comportement pour un
plus petit sous-ensemble d’éléments. Cette caractéristique fait toute la
puissance des feuilles de style.
Plutôt que de nous étendre sur la panoplie de
styles générés automatiquement par les raccourcis typographiques de SPIP, et
que vous pourrez habillez à votre guise (ils sont énumérés dans « Spip et les feuilles de style »),
étudions ici le cas où vous voulez appliquer un habillage différent à un même
style, selon sa position dans ce squelette. Ce besoin est légitime : on
veut par exemple afficher le corps de texte dans une police à empattements avec
indentation en début de paragraphe, mais le post-scriptum dans une police plus
« lisse » (sans empattements) et plus petite, sans indentation.
Cette opération est en réalité très simple. Il faut
d’abord modifier votre squelette afin d’introduire les éléments qui permettront
de discriminer le texte et le post-scriptum. Cela prendra par exemple, à
l’intérieur de la boucle ARTICLES principale,
la forme suivante :
<div class="texte">#TEXTE</div>
<div
class="ps">#PS</div>
Il faut ici recalculer la page (car on a modifié le
HTML...). L’affichage du navigateur est toujours le même : normal, nos
nouveaux styles ne faisant l’objet d’aucune règle dans la feuille de style, ils
sont ignorés par le navigateur. Remédions-y :
.texte p.spip {
font-family: "Times New Roman", serif;
text-indent: 50px;
}
.ps
p.spip {
font-family: Tahoma, Arial, sans-serif;
font-size: 90%;
}
La grande nouveauté ici ne réside pas dans les
propriétés graphiques mais dans la façon dont on les applique au code HTML. En
effet, « .texte p.spip » signifie : « cette règle s’applique à tous les tags <p
class="spip"> qui
sont contenus dans un tag ayant un attribut class égal à “texte” ». On pourrait restreindre un peu cette
règle en spécifiant que le tag parent doit en plus être un tag <div> (le début de la règle s’écrirait alors « div.texte
p.spip ») ; mais
comme nous maîtrisons la structure de nos propres squelettes, il n’est pas
utile de rendre la feuille de style très restrictive.
Toujours est-il que cette feuille de style a le
résultat voulu : les paragraphes du corps de texte s’affichent avec une
indentation, ceux du post-scriptum dans une fonte plus petite et sans
indentation. Pour vérifier que ces règles s’appliquent bien à chacun des
paragraphes <p class="spip"> et non au <div
class="...">
englobant, on peut s’amuser à définir un cadre noir :
.texte
p.spip {
border: 1px solid black;
}
On note que chaque paragraphe du corps de texte
(mais pas du post-scriptum) est entouré de son propre cadre noir. Si on avait
simplement écrit « .texte » au lieu de « .texte p.spip », c’est le texte tout entier qui serait
entouré d’un unique cadre noir englobant. Remarquons en passant l’apparition de
la propriété border...
Note : cette astuce, consistant à tracer un cadre
de couleur pour savoir à quels éléments s’applique précisément une règle, peut
être très utile quand votre feuille de style s’enrichit. N’hésitez pas à
l’utiliser si vous commencez à perdre pied...
Cette méthode est très puissante et se généralise
avec profit pour la structuration de votre mise en page.
Vous avez personnalisé la mise en page et la
typographie de votre site, mais maintenant ce sont les formulaires SPIP qui
jurent totalement sur le reste ! Pas de panique, là aussi les feuilles de
style remédient au problème.
Vous vous souvenez que les feuilles de style,
utilisées en conjonction avec SPIP, permettent d’adapter le rendu
des raccourcis typographiques à votre mise en page. Eh bien, il en va de
même pour les formulaires générés par SPIP : leur aspect graphique peut
être modulé afin de s’insérer sans hiatus dans votre design.
Encore une fois, pas question ici de passer en revue l’ensemble des
styles fournis par SPIP. Sachez cependant que vous pouvez altérer l’aspect
de tous les formulaires de l’espace public : formulaire de réponse aux
forums, de recherche, de signature de pétition...[24] Nous nous bornons ici à donner quelques recettes.
Une nouvelle qui ravira les débutants en CSS :
on peut changer la couleur des champs et des boutons des formulaires [25].
Par exemple, pour que les boutons aient un fond bleu
clair, ajoutez la règle suivante à votre fichier CSS (qui, si vous avez suivi
cette initiation à la lettre, s’appelle mes_styles.css) :
.spip_bouton {
background-color: #b0d0FF;
color: black;
}
Les boutons apparaissent désormais avec un fond bleu
clair (propriété background-color), et un texte noir. Notez que .spip_bouton est le style utilisé par les boutons et champs des
formulaires SPIP.
Modifions maintenant l’aspect du bord des
boutons. Le relief traditionnel des boutons HTML est un peu vieillot. On peut
décider d’aplatir les bords, et de les épaissir en contrepartie pour qu’ils
restent bien visibles. Par exemple :
.spip_bouton {
background-color: #b0d0FF;
color: black;
border: 2px solid #000060;
}
La propriété border ainsi définie trace un bord épais de 2 pixels, à
l’aspect plat (« solid » en langage CSS) et de couleur bleu foncé
autour des boutons. On pourra également modifier la police de caractères du
bouton (avec les propriétés font-size et font-family
comme vu aux étapes précédentes de cette initiation).
Et pour les champs ? Il suffit d’appliquer vos
choix au style .formul au lieu de .spip_bouton.
Les feuilles de style permettent non seulement de
changer les couleurs et les polices de caractères, mais aussi de gérer le
positionnement relatif des objets dans la page. Sans aller très loin, montrons
comment aérer un peu les formulaires :
.formulaire {
background-color: #e8f4ff;
font-family: Verdana, Arial, sans-serif;
font-size: 90%;
font-weight: normal;
border: 1px solid black;
padding: 10px;
}
Nous modifions ici l’affichage du style .formulaire, qui est le style principal de tous les
formulaires générés par SPIP. L’intérêt de modifier ce style est que l’on peut
gérer l’affichage de tous les formulaires. Ici l’on applique une couleur de
fond, très claire, et une police de caractères. Mais surtout, on modifie
l’espacement intérieur de chaque formulaire pris individuellement. C’est la
propriété padding
qui permet cet effet d’aération. Notez bien que cette aération se produit
précisément à l’intérieur du bord défini par la propriété border : le formulaire est ici considéré comme un bloc
rectangulaire autonome.
Remarque : les feuilles de style permettent même de définir précisément la
disposition de ces blocs rectangulaires entre eux, sans utiliser de tableaux
pour la mise en page. C’est cependant un sujet trop vaste pour cette
initiation.
Cette initiation n’a fait qu’effleurer la puissance
des feuilles de style. Vous êtes libres de vous contenter du niveau abordé ici,
ou d’explorer les nombreux documents disponibles sur le Web afin d’aller plus
loin.
Citons quelques portes de sortie intéressantes.
OpenWeb, site mêlant argumentaires
idéologiques et articles techniques sur les CSS et autres standards du
Web ;
un
cours « CSS débutant » ;
« Techniques et astuces pratiques
pour une mise en page CSS » vous expliquera comment gérer le
positionnement d’éléments avec les feuilles de style ;
une
collection de recettes
pour une utilisation efficace des CSS ;
un
pense-bête, pour ne pas
se perdre dans le feu de l’action ;
une
traduction
en français du standard CSS2 (assez aride).
Listes
d’éléments : des exemples
d’effets graphiques à foison ;
de
très bons tutoriaux sur
le positionnement d’objets avec les CSS ;
le
W3C a ses propres tips’n’tricks...
et
pour ceux qui ont le goût du risque, l’intégrale des spécifications originales du W3C !
Si
vous utilisez l’excellent navigateur Firefox, le plug-in EditCss
vous permet de modifier et tester les feuilles de style à la volée, depuis
votre brouteur.
La situation est la suivante : dans un même
site, la présentation des articles dans différentes rubriques doit être
différenciée :
dans
certaines rubriques, les articles sont publiés les uns après les autres, on
veut donc les présenter selon l’ordre chronologique : les plus récents en
début de liste, les plus anciens en fin de liste ;
dans
d’autres rubriques, on veut « forcer » l’affichage des articles en
les numérotant (« 1. Le premier article », « 2. Le deuxième
article »...) ; sur le site public, on veut donc les présenter selon
cet ordre indiqué par la numérotation.
Voici une méthode pour réaliser cet effet.
Nous sommes à l’intérieur d’une boucle de rubrique
(par exemple, la page « rubrique.html ») :
<BOUCLE_rubrique_principale(RUBRIQUES){id_rubrique}> ... </BOUCLE_rubrique_principale> |
À l’intérieur de cette boucle, nous allons
effectuer le test suivant : est-ce qu’il existe, dans cette rubrique, au
moins un article dont le titre commence par un numéro suivi d’un point ?
<BOUCLE_test_numero(ARTICLES){id_rubrique}{titre==^[0-9]+\.}{0,1}> Il existe un article numéroté dans
cette rubrique. </BOUCLE_test_numero> Il n'y a pas d'article numéroté. <//B_test_numero> |
Le critère intéressant ici est :
{titre==^[0-9]+\.} |
Il s’agit d’une sélection sur le titre, selon une expression régulière (« == » indique une sélection selon une expression
régulière) dont la syntaxe est : au début du titre (« ^ » indique le début de la chaîne testée), il y
a un ou plusieurs (« + »
indique « au moins un des caractères précédents ») caractères compris
entre 0 et 9 (« [0-9] »
signifie « caractères compris entre 0 et 9 inclus »), suivis du
caractère « point » (« \. »).
Notez enfin qu’on ne sélectionne qu’un seul article
ainsi numéroté ({0,1}) ;
de cette façon, l’intérieur de la boucle ne sera effectué qu’une seule fois. De
plus, il suffit qu’il existe un seul article numéroté pour provoquer
l’affichage d’une liste par ordre « numéroté ».
Cette boucle affiche ainsi « Il existe un
article numéroté dans cette rubrique. » s’il y a au moins un article dont
le titre est précédé d’un numéro dans la rubrique, et « Il n’y a pas
d’article numéroté. » sinon.
Il suffit maintenant d’installer à la place de ces
mentions des boucles d’affichage des articles selon l’ordre de présentation
désiré :
<BOUCLE_test_numero(ARTICLES){id_rubrique}{titre==^[0-9]+\.}{0,1}>
<BOUCLE_ordre_numeros(ARTICLES){id_rubrique}{par num titre}>
<li> [(#TITRE|supprimer_numero)]
</BOUCLE_ordre_numeros> </BOUCLE_test_numero> <BOUCLE_ordre_date(ARTICLES){id_rubrique}{par date}{inverse}>
<li> #TITRE
</BOUCLE_ordre_date> <//B_test_numero> |
Mettons que vous voulez présenter une série
d’articles par ordre alphabétique, sauf le prologue que vous voulez
légitimement afficher au début de la liste...
Il existe une astuce pour « duper » le
tri effectué par SPIP : il suffit d’ajouter un espace au début du titre de
l’article (par exemple, transformer "Prologue"
en " Prologue"). Le tri
alphabétique pensera alors que ce titre doit « passer avant les
autres », et l’affichera en premier. Cependant l’espace supplémentaire du
titre sera ignoré par le navigateur Web, et ne provoquera pas de décalage
disgrâcieux dans la mise en page.
Notez bien : l’astuce ne fonctionnera que si vous utilisez un classement alphabétique sur le titre des articles (c’est-à-dire le critère de boucle {par titre}). Tout autre classement ne fonctionnera pas.
Remarque : cela s’applique également aux
rubriques, brèves, sites référencés, etc.
Il est fréquent, pour rythmer la navigation sur son
site, de vouloir utiliser des logos différents (notamment de tailles
différentes) pour un même article en fonction de l’endroit où il apparaît. Par
exemple, utiliser un « gros » logo sur la page d’accueil du site qui
permette de bien mettre en valeur l’article principal du moment, et un
« petit » logo pour la navigation générale du site.
Jusqu’à récemment, les utilisateurs avaient créé
des méthodes personnelles basées sur l’utilisation différenciée du logo
« normal » et du logo « pour survol ». Dans notre exemple,
le logo « normal » utilisé comme « petit logo », appelé par
la balise #LOGO_ARTICLE_NORMAL, et sur le sommaire, le logo « pour
survol » appelé par la balise #LOGO_ARTICLE_SURVOL pour
afficher la « grande » version du logo. Cette méthode complique
souvent le code des squelettes, et interdit l’utilisation habituelle des logos
« avec survol » que SPIP fournit automatiquement. Elle est de plus
d’une souplesse très limitée.
Depuis la version [SPIP
1.4], il est possible de joindre des documents aux articles (et,
accessoirement, aux rubriques). Nous allons expliquer ci-dessous comment
utiliser ces documents joints pour créer plusieurs logos pour un même article.
Nous
continuerons à utiliser les deux logos de l’article pour afficher les logos
« normaux » (ceux qui apparaissent dans les liens de navigation les
plus fréquents, par exemple sur les pages des rubriques), ce qui permet de
conserver la simplicité de gestion des logos avec SPIP et la gestion
automatique du survol (on revient à l’utilisation évidente de la balise
#LOGO_ARTICLE, ou de #LOGO_ARTICLE_RUBRIQUE).
Nous
déciderons de joindre aux articles un document (généralement une image aux
formats GIF, JPEG ou PNG) auquel nous donnerons systématiquement le même nom.
Il nous suffira d’afficher ce document (en l’appelant par son nom) à la place
du logo « normal » lorsque nous le désirerons.
Cette
méthode permet ainsi de créer autant de logos différents que nécessaire pour un
même article (pas seulement un grand logo et un petit logo, mais pourquoi pas
une image pixelisée avec un travail typographique élaboré pour afficher le
titre, etc.).
Nous
verrons de plus que, grâce aux boucles de SPIP, on pourra très facilement dans
les squelettes déterminer si un tel « grand » logo (document portant
le nom choisi par nous) est présent, et agir en conséquence (afficher à la
place le logo « normal », du texte spécifique, ou carrément un autre
élément graphique).
Miracle
de la technologie moderne, des formats propriétaires et de l’accès par
haut-débit, de telles versions spécifiques des logos, étant des documents
joints, pourront être d’un autre format que des images. On pourra ainsi
afficher, en tant que « grands » logos, des animations Flash ou
Shockwave, des animations vidéo...
Nous
décidons (arbitrairement, mais faites selon vos besoins) que les documents
joints utilisés en tant que « gros » logo seront tous intitulés
« spip_logo » ; ce document « spip_logo » sera affiché sur la page du sommaire de
notre site à la place du logo normal.
Nous utiliserons d’autres noms dans la suite de cet
exemple pour créer des effets plus fins, décidons immédiatement qu’ils auront
tous des noms commençant par « spip_... ». (Cela nous permettra, dans l’affichage habituel des documents
joints à un article d’exclure tous les documents dont le nom commence par
« spip_... ». De cette façon, l’utilisation de documents
en tant que logos alternatifs n’interfèrera pas avec l’affichage, par exemple,
d’un portfolio.)
Sur
un article publié en ligne (de façon à pouvoir bidouiller nos squelettes en les
testant), nous installons simplement :
Le logo « normal »
Le logo est installé classiquement. A priori, il s’agit d’une image de taille modeste.
Le document « spip_logo »
Le seul impératif est de donner à ce document le
titre « spip_logo ».
Il est inutile d’installer une vignette de prévisualisation.
Dans le cas d’un document multimédia (Flash,
Shockwave...), il faut indiquer à la main ses dimensions en pixels.
Nous
décidons de l’usage de ce document intitulé « spip_logo » : il sera affiché sur la page
d’accueil du site à la place du logo normal du dernier article publié. De cette
façon, la page de Une du site peut afficher une « grande » image pour
mettre en valeur l’article en vedette.
Commençons
par insérer une boucle toute simple pour afficher le dernier article publié sur
le site et son logo « normal ». (Dans tous les exemples qui suivent,
le code HTML est réduit à son strict minimum ; à vous d’enrober cela avec
la mise-en-pages graphique qui vous convient.)
<BOUCLE_article_vedette(ARTICLES){doublons}{par date}{inverse}{0,1}> #LOGO_ARTICLE <h1>#TITRE</h1> </BOUCLE_article_vedette> |
Cette boucle très simple affiche le premier article
({0,1}) parmi tous les ARTICLES, sélectionnés par date de publication ({par date}) du plus récent au plus ancien ({inverse}). On affiche donc bien le dernier article publié
sur le site. À l’intérieur de la boucle, on affiche le logo de l’article suivi
du titre de l’article.
Nous
avons dit que nous voulions afficher, à la place du logo normal, le document
joint à cet article dont le titre est « spip_logo ». Le code devient :
<BOUCLE_article_vedette(ARTICLES){doublons}{par date}{inverse}{0,1}>
<BOUCLE_logo_article_vedette(DOCUMENTS){id_article}{titre=spip_logo}> [(#EMBED_DOCUMENT)]
</BOUCLE_logo_article_vedette> <h1>#TITRE</h1> </BOUCLE_article_vedette> |
La BOUCLE_logo_article_vedette sélectionne parmi les documents joints à cet
article ({id_article}) celui dont le titre est « spip_logo » ({titre=spip_logo}). À l’intérieur de la boucle, on demande l’affichage
de ce document joint (#EMBED_DOCUMENT).
L’usage de #EMBED_DOCUMENT (encore peu répandu parmi les
sites utilisant SPIP) dans les squelettes permet d’insérer, via le système de
boucles, directement le document à l’intérieur de la page. SPIP se charge de
créer le code correspondant à des images ou à des fichiers multimédia.
Inconvénient :
si l’article n’a pas de document joint intitulé « spip_logo », le code précédent n’affiche que le titre. On va donc effectuer
une nouvelle modification, qui permet d’afficher le logo « normal »
de l’article s’il n’existe pas de document joint pour cet usage. Notez
bien : une fois cette méthode comprise, il n’y aura plus d’autres
subtilités pour réaliser tous les effets suivants...
<BOUCLE_article_vedette(ARTICLES){doublons}{par date}{inverse}{0,1}>
<BOUCLE_logo_article_vedette(DOCUMENTS){id_article}{titre=spip_logo}> [(#EMBED_DOCUMENT)]
</BOUCLE_logo_article_vedette> #LOGO_ARTICLE
<//B_logo_article_vedette> <h1>#TITRE</h1> </BOUCLE_article_vedette> |
Nous avons tout simplement ajouté l’appel au logo
« normal »
(#LOGO_ARTICLE) en texte alternatif (ce qui se trouve avant <//B...> d’une boucle s’affichant si la boucle ne fournit
pas de résultat - ici, s’il n’y a pas de document joint à l’article portant le
titre « spip_logo »).
Nous avons obtenu le résultat désiré :
s’il
existe un document joint associé à l’article auquel nous avons donné le titre
« spip_logo », il est directement affiché ;
sinon,
c’est le logo « normal » qui est affiché.
Dans le squelette des articles, on affiche les
documents joints grâce à la BOUCLE_documents_joints, dont les critères essentiels sont :
<BOUCLE_documents_joints(DOCUMENTS){id_article}{mode=document}{doublons}> |
On appelle les DOCUMENTS liés à cet article ({id_article}), qui sont bien des documents joints et non des
images ({mode=document}) et qu’on n’a pas déjà affichés à l’intérieur du
texte de l’article en utilisant le raccourci <EMBxx> ({doublons}).
Modifions ce code pour interdire l’affichage, dans
cette boucle (qui est une sorte de « portfolio »), des documents dont
le nom commence par « spip_... » (on ne veut pas afficher ici le « gros » logo
utilisé en page de Une du site) :
<BOUCLE_documents_joints(DOCUMENTS) {id_article}{titre!==^spip\_}{mode=document}{doublons}> |
Le critère {titre!==^spip\_} est une expression régulière, dont la syntaxe est très codifiée. On
sélectionne les documents dont le titre n’est pas formé ainsi (le !== signifie « qui ne correspond pas à
l’expression régulière ») : les premiers caractères (le symbole ^ indique le début de la chaîne de caractères) sont
« spip » suivi de « _ »
(dans la syntaxe des expressions régulières, « \_ » indique le caractère « _ », de la même façon que « \. » indique le caractère « . »).
Ce critère sélectionne donc les documents joints
dont le titre ne commence pas par « spip_ ».
L’exposé du principe général est terminé, vous avez
largement de quoi vous amuser avec ça sur votre propre site. Les exemples
suivants n’en sont que des variations.
Je décide, toujours de manière arbitraire, qu’il
doit toujours y avoir une grosse image en haut de page de mes articles. Il
s’agit d’un choix graphique de ma part : pour assurer l’unité graphique de
mon site, j’affiche en haut de page une version de grand format liée à
l’article (une variation du principe du « grand » logo) et, à défaut,
une image stockée ailleurs sur mon site.
Toujours
le même principe : je joins à mon article un document dont je fixe le
titre à « spip_haut ».
(Pour éviter que ce document ne s’affiche dans le « portfolio » de la BOUCLE_documents_joints précédente, je fais commencer son titre par
« spip_... ».)
Dans mon squelette des articles, j’affiche
simplement en haut de page ce document :
<BOUCLE_doc_haut(DOCUMENTS){id_article}{titre=spip_haut}> #EMBED_DOCUMENT </BOUCLE_doc_haut> |
Comme dans l’exemple précédent, j’affiche le
document, lié à l’article de cette page, et dont le titre est « spip_haut ». Fastoche.
Comme
dans le premier exemple, je pourrais décider d’afficher le logo de l’article si
ce document n’existe pas :
<BOUCLE_doc_haut(DOCUMENTS){id_article}{titre=spip_haut}>
#EMBED_DOCUMENT </BOUCLE_doc_haut>
#LOGO_ARTICLE <//B_doc_haut> |
Mais
ça n’est pas le résultat désiré. Je veux, pour des impératifs graphiques,
toujours afficher une grande image aux dimensions prédéterminées.
Je vais donc (toujours un choix arbitraire de ma
part) créer des images de substitution, utilisées « par défaut », au
cas où un article n’aurait pas d’image en propre. Ces images répondent à mes
impératifs graphiques (par exemple, elles ont toutes les mêmes dimensions que
les documents que j’utilise d’habitude en « spip_haut »).
Sur mon site, je créée une rubrique pour accueillir
« en vrac » ces documents de substitution. J’active les documents
associés aux rubriques. (Je peux aussi créer un article qui accueillerait tous
ces documents, et ainsi ne pas activer les documents joints aux rubriques. Le
code serait à peine différent.) Admettons que cette rubrique porte le numéro 18
(c’est SPIP qui va fixer automatiquement le numéro de la rubrique lors de sa
création). J’installe tous mes documents de substitution à l’intérieur de cette
rubrique numéro 18. (Il est inutile de leur donner un titre.)
Pour appeler, au hasard, un document installé dans
cette rubrique, il me suffit d’invoquer les critères suivants :
<BOUCLE_doc_substitution(DOCUMENTS){id_rubrique=18}{0,1}{par hasard}> #EMBED_DOCUMENT </BOUCLE_doc_substitution> |
(Notez bien : le critère {par hasard} ne signifie pas que l’image sera différente à chaque visite de la
page, mais qu’elle sera sélectionnée au hasard à chaque recalcul de la page.)
On prendra soin, dans la navigation du site,
d’interdire l’affichage de la rubrique 18, qui n’a pas besoin d’être présentée
aux visiteurs. Le critère {id_rubrique!=18} fera l’affaire.
Pour
terminer la mise en place du dispositif, il nous suffit d’insérer cette boucle
affichant un document de substitution pris au hasard dans la rubrique 18 en
tant que texte alternatif à notre BOUCLE_doc_haut
(à la place du #LOGO_ARTICLE) :
<BOUCLE_doc_haut(DOCUMENTS){id_article}{titre=spip_haut}> #EMBED_DOCUMENT </BOUCLE_doc_haut>
<BOUCLE_doc_substitution(DOCUMENTS){id_rubrique=18}{0,1}{par hasard}> #EMBED_DOCUMENT </BOUCLE_doc_substitution> <//B_doc_haut> |
Toujours sur le même principe, nous allons afficher
une version graphique du titre de l’article. Il s’agit d’une image réalisée
avec un logiciel de dessin, où apparaît
,
avec une typographie particulièrement soignée (effets
de relief, de dégradés de couleurs, avec des polices de caractère exotiques...)
le titre de l’article.
Décrétons
qu’il s’agira d’un document joint associé à l’article, que nous titrerons
« spip_titre ».
Pour
appeler ce document, à l’endroit où doit être affiché le #TITRE de
l’article, installons la boucle désormais connue :
<BOUCLE_doc_titre(DOCUMENTS){id_article}{titre=spip_titre}> #EMBED_DOCUMENT </BOUCLE_doc_titre> |
Notez à nouveau que cette méthode permet non
seulement d’utiliser une image pour afficher le titre, mais aussi une animation
Flash, un film... Dans ces cas, il vous faudra indiquer à la main pour votre
document joint quelles sont ses dimensions en pixels.
Complétons
le dispositif : s’il n’existe pas de document joint portant le titre
« spip_titre », il faut afficher en tant que texte HTML
classique les informations nécessaires :
|
* * *
Signalons un dernier avantage à cette méthode...
Elle permet de faire par la suite encore évoluer
radicalement l’interface graphique de votre site. Sans avoir à supprimer un par
un tous les documents intitulés « spip_haut », « spip_titre »..., il vous suffit de créer de nouveaux
squelettes qui ne les appellent tout simplement pas.
Par exemple, si les documents
« spip_haut » étaient précédemment tous conçus pour une largeur de
450 pixels, et que la nouvelle interface graphique requiert des images d’une
largeur de 600 pixels, vous n’aurez pas besoin de modifier un par un tous vos
fichiers « spip_haut ».
Il vous suffit, dans les squelettes, de ne plus faire appel aux documents
intitulés « spip_haut », mais d’utiliser un nouveau nom (par exemple
« spip_large ») et d’installer au fur et à mesure vos
nouvelles versions de documents en les titrant « spip_large ». Pendant la transition, il n’y aura pas
d’incohérences graphiques.
Les plus jetés d’entre vous peuvent même imaginer
toutes sortes de tests sur le type de document ({extension=...}) ou sur leur taille ({largeur=...}, {hauteur=...})
(aucun PHP nécessaire) pour réaliser des interfaces selon ces tests (par
exemple, une certaine interface graphique si « spip_haut » fait 450
pixels de largeur, et une autre s’il fait 600 pixels de largeur...).
Par défaut SPIP vous propose une page auteur qui
vous permet de montrer la liste des auteurs/rédacteurs participant à votre
site, ainsi que leurs dernières contributions.
Mais un problème vient à se poser quand vous avez
plusieurs rédacteurs et que ceux-ci participent activement à votre site. Cela
finit par être une page à rallonge.
Cependant il existe un moyen de montrer les
dernières contributions de vos auteurs/redacteurs et ce pour chacun d’eux.
Comment procéder ?
Tout d’abord, on va créer deux fichiers : un
fichier myauteur.php3 et un fichier myauteur.html
Dans le fichier myauteur.php3 mettre le
code suivant :
<?php $fond = "myauteur"; $delais = 24*3600; include
("inc-public.php3"); ?> |
Création du fichier myauteur.html
Dans le fichier myauteur.php3 mettre les codes suivants :
Juste
après la balise <body>, mettre
Maintenant, il faut configurer votre page auteur
(page où vous énumérez vos différents auteurs) pour que, en cliquant sur le
lien auteur, celui-ci, dirigera vers la page myauteur où sera inscrit
les derniers articles écrits par l’auteur.
Le lien devra être écrit de la manière
suivante :
<a
href="myauteur.php3?id_auteur=#ID_AUTEUR">nom
du lien</a>
Par exemple, on peut vouloir créer un tableau
contenant les titres des articles d’une rubrique agencés sur trois colonnes, le
nombre de lignes dépendant du nombre total d’articles ; sur le principe :
article 1 |
article 2 |
article 3 |
article 4 |
article 5 |
article 6 |
article 7 |
article 8 |
article 9 |
L’astuce consiste à jouer à la fois avec les
doublons et avec les
boucles récursives. On construit une première boucle qui affiche les trois
premiers articles de la rubrique une fois les doublons éliminés. On voit
qu’il suffit ensuite de réafficher cette boucle à chaque fois qu’il reste des
articles pour afficher graduellement tous les articles, ceux déjà affichés
venant à chaque fois grossir les rangs des doublons. Pour cela, dans le code
conditionnel de cette boucle, on ajoute un appel récursif vers la boucle
elle-même : elle sera affichée tant qu’elle produit des résultats.
<table> <B_ligne> <tr> <BOUCLE_ligne
(ARTICLES) {id_rubrique} {doublons} {par titre} {0,3}> <td width="33%"> <a href="#URL_ARTICLE">#TITRE</a> </td> </BOUCLE_ligne> </tr> <BOUCLE_ligne_suite
(BOUCLE_ligne)></BOUCLE_ligne_suite> </B_ligne> </table> |
Le même type de boucle, en remplaçant l’appel du
titre par le logo (avec la balise #LOGO_ARTICLE), permet d’afficher une galerie où chaque logo d’article
donne un aperçu (dont la taille sera de préférence fixée afin d’avoir une belle
mise en page), et le texte de l’article contient la ou les oeuvres exposées.
Cela s’effectue avec le critère « age », qui est l’âge de l’article (calculé depuis
sa date de mise en ligne dans l’espace public) en nombre de jours.
Ainsi pour conserver tous les articles de moins
d’un an dans la rubrique courante. Le critère de sélection qui nous intéresse
ici est : « age ».
<B_articles_recents> <ul> <BOUCLE_articles_recents(ARTICLES){id_rubrique}{age < 365}{par titre}> <li>#TITRE</li> </BOUCLE_articles_recents> </ul> </B_articles_recents> |
Pour prendre en compte l’âge vis-à-vis de la date
de première publication au lieu de la date de mise en ligne, il faut utiliser
le critère « age_redac »
au lieu de « age ». L’âge est indiqué en nombre de jours.
Notons que cette manipulation est possible avec
tous les types de données auxquels est associée une date (brèves, forums...).
Il suffit d’inclure la boucle de recherche dans une
boucle de type rubriques sélectionnant les rubriques de premier niveau ;
dans la boucle de recherche, on ajoute alors le critère « id_secteur » pour se limiter au secteur courant.
<BOUCLE_secteurs(RUBRIQUES){racine}> <B_recherche> <b>#TITRE</b> <ul> <BOUCLE_recherche(ARTICLES){recherche}{id_secteur}{par points}{inverse}{0,5}> <li><a
href="#URL_ARTICLE">#TITRE </a> </BOUCLE_recherche> </ul><hr> </B_recherche> </BOUCLE_secteurs> |
On remarquera que le titre du secteur n’est affiché
que si la recherche a donné des
résultats pour ce secteur. D’autre part, pour chaque secteur on n’affiche que
les cinq articles les mieux classés, par ordre décroissant de pertinence.
Attention cependant, comme la recherche est
effectuée autant de fois qu’il y a de secteurs, le calcul risque d’être
ralenti.
C’est un poil acrobatique.
À première vue, il est très simple de connaître le
nombre d’éléments d’une boucle : il suffit d’utiliser le code SPIP :
#TOTAL_BOUCLE. Ce code peut s’utiliser non seulement à
l’intérieur de la boucle, mais aussi (c’est le seul dans ce cas) dans le texte
conditionnel après (le texte qui s’affiche après la boucle si elle contient
des éléments) et le texte conditionnel alternatif (le texte qui
s’affiche si la boucle est vide).
Nous devons créer une boucle de type FORUMS, liée à un article, de façon à compter son nombre
de résultats.
Première subtilité : nous voulons tous
les messages des forums liés à l’article, en comptant les réponses aux
messages, les réponses aux réponses...
Une simple boucle de type :
La BOUCLE_news fait tout le travail : elle
affiche le titre de chaque news, son texte, et si nécessaire le post-scriptum
et des notes de bas de page.
Comme à l’habitude, la BOUCLE_news_machines affiche
le logo des machines concernées par la news.
Considérons notre page des news terminée. On pourra
évidemment y ajouter les liens vers les articles de la même rubrique (les
tests, les previews, les solutions...).
Notre site utilise désormais ce qui était prévu à
l’origine :
le
rubriquage thématique (par genre de jeux) ;
l’indication
des machines concernées par chaque article ;
la
gestion des types d’articles (tests, news, previews...).
L’étape suivante consistera à créer des navigations
parallèles (naviguer selon une unique machine, ou selon un type d’articles).
Mais avant de nous lancer dans le développement de
ces navigations transversales, compliquons-nous un peu l’affaire, en ajoutant
deux autres éléments indispensables aux sites de jeux vidéo :
la
note attribuée à un jeu ;
la
date de sortie officielle du jeu.
Ces deux éléments devraient être, désormais,
simples à installer avec le système des mots-clés. Ils permettront eux-même de
proposer des navigations transversales (notamment une page des jeux ayant les
meilleures notes, et une page d’annonce des prochaines sorties).
Il est logique d’attribuer une note à la fin d’un
test :
pour
les previews, c’est trop tôt, puisqu’il ne s’agit pas d’une version
définitive ; pour les autres types d’articles (news, soluces...), ça n’a
tout simplement rien à voir ;
il
est impossible d’attribuer une note à la rubrique-jeu, puisque cette rubrique
peut présenter différentes versions d’un jeu.
Donc, nous décidons que, dans le fonctionnement de
notre site, la note est liée à un article de test. Dans une même rubrique d’un
jeu, puisqu’il peut y avoir plusieurs tests différents (selon les critiques,
selon les machines...), il y aura donc plusieurs notes, associées à ces tests.
Arbitrairement, nous choisissons une notation sur
10 (de 1 pour nul, à 10 pour génial).
Retour à la page de gestion des mots-clés :
nous
créons un groupe de mots intitulé « Note » ;
dans
ce groupe de mots, nous créons 10 mots-clés, dont les noms sont successivement
« 01 », « 02 », ..., « 09 »,
« 10 ». Ce qui donne :
On peut choisir, comme pour les machines,
d’attribuer un logo différent à chaque note (par exemple des étoiles), et
ensuite dans les squelettes utiliser les logos plutôt que le nombre indiqué par
le mot-clé en toutes lettres. Par pure fainéantise, nous nous contenterons ici
d’utiliser le texte des mots-clés.
Désormais, avant la publication d’un test, en plus
de sélectionner les mots-clés correspondant au type de l’article
(« Test », donc) et ceux des machines concernées, il faut penser à
choisir une note. Si l’on veut un fonctionnement cohérent, il est évident qu’on
ne doit sélectionner qu’une seule note par article.
La boucle permettant d’afficher la note d’un
article est très simple.
Dans
« article.html », plaçons la note de l’article sous la signature de
l’auteur (avant le #PS et les
#NOTES) :
<BOUCLE_note(MOTS){id_article}{inverse}{type=Note}> [<p align="right"><b>NOTE :
(#TITRE)/10</b>]
</BOUCLE_note> |
Ajoutons également la mention de la note dans les
« autres tests de ce jeu ». La BOUCLE_tests est ainsi modifiée :
<B_tests><p>Les tests de ce jeu :
<ul>
<BOUCLE_tests(ARTICLES){id_rubrique}{titre_mot=Test}>
<li>
<BOUCLE_tests_machines(MOTS){id_article}{type=Machines}> [(#LOGO_MOT)]
</BOUCLE_tests_machines>
<a href="#URL_ARTICLE">#TITRE</a>
<BOUCLE_autre_note(MOTS){id_article}{inverse}{type=Note}> [ - NOTE : (#TITRE)/10]
</BOUCLE_autre_note>
- [(#DATE|affdate)] </BOUCLE_tests> </ul> </B_tests> |
Dans
« rubrique.html », cette même BOUCLE_tests est à remplacer
directement.
Voilà, l’intégration d’une note de test n’a pas
pris cinq minutes ! Tout cela étant trop facile, nous verrons
par la suite comment exploiter ailleurs cette note attribuée aux jeux.
L’affichage de la date de sortie officielle des
jeux est plus problématique. En effet, une date ne peut pas être elle-même un
mot-clé (nous avons déjà souligné que les mots-clés devaient être des éléments
stables de la structure : on ne va donc pas créer des mots-clés de
dates !).
Il existe une possibilité : utiliser la date
de première publication de certains articles. Problème : quels
articles ?
Les
dates de sortie sont connues (de manière plus ou moins approximative) longtemps
à l’avance, donc on ne peut pas attendre qu’il y ait des articles consacrés au
jeu pour pouvoir l’annoncer.
Les
articles d’un jeu peuvent traiter d’une plateforme ou de plusieurs. Or les
dates de sorties selon les plateformes est très variables. On peut donc
difficilement utiliser des articles communs à plusieurs plateformes pour
annoncer les dates. Par exemple, Alone in the Dark : the new nightmare,
est très similaire entre ses versions Playstation 2 et Dreamcast, il est
donc logique de consacrer un test unique aux deux versions ; en revanche,
les dates de sorties sont différentes sur ces plateformes.
Tant
que le jeu n’est pas commercialisé, les dates annoncées doivent être corrigées
régulièrement (retards, plus grande précision...). Le webmestre doit donc
facilement trouver où il doit modifier ces informations.
Dans la structure de notre site, on peut donc
considérer que la date de sortie d’un jeu est une information indépendante
des autres informations (tests, previews, etc.) ; nous ne pouvons donc pas
utiliser la « date de première publication » d’un autre article pour
indiquer cette date de sortie. Nous allons procéder de la façon suivante (il en
existe certainement d’autres) :
nous
créons un nouveau type d’article (en plus des tests, previews, etc.) ;
installé dans le groupe « Type_article », nous le nommerons
« Date_sortie » ;
dans
la rubrique du jeu, nous créons autant d’articles nécessaires qu’il y a de
versions du jeu avec des dates de sortie différentes. Ces articles sont vides :
ils n’ont qu’un titre et une date de « publication » (fixée
manuellement à la date de sortie du jeu). Son titre lui-même n’a aucune
importance, nous ne l’afficherons pas sur le site public ; en revanche, ce
titre facilitera la navigation dans le site privé ;
à
chaque article associé à « Date_sortie », on attribue également le
mot-clé de la machine concernée par cette date.
Voici par exemple comment procéder avec Resident
Evil : Code Veronica :
créer
un nouvel article dans la rubrique « Code Veronica » ;
titrer
cet article « Sortie Veronica Dreamcast » (titre de convenance, sans
autre intérêt que d’identifier ces articles dans l’espace privé) ;
attribuer
les mots-clés « Dreamcast » et « Date_sortie » à cet
article ;
« publier »
l’article, et modifier sa date en « mai 2000 » (si l’on ne connait
pas le jour exact, on
peut sélectionner « n.c. » dans le menu déroulant du jour) ;
recommencer
l’opération avec un nouveau article « Sortie Veronica PS2 » ;
lui
attribuer les mots-clés « Playstation 2 » et
« Date_sortie » ;
publier
et modifier la date (13 septembre 2001).
Pour le premier article, cela donne :
L’auteur de ces articles est totalement indifférent
(inutile de perdre du temps à le supprimer, de toute façon il ne sera pas
utilisé).
Notez l’intérêt de notre façon d’afficher les
articles d’une rubrique en fonction de certains types d’articles (tests,
previews...) : les articles ayant pour mot-clé « Date_sortie »
ne sont pas affichés (avec les squelettes standards de SPIP, ces
« articles » pourtant vides de tout contenu seraient affichés comme
les autres).
Lorsque l’on se trouve dans un article (d’un jeu),
la (les) date(s) de sortie sont contenus dans des articles associés au mot
« Date_sortie », situés dans la même rubrique. Pour connaître la date
de sortie d’un jeu depuis un article de test (par exemple), il faut donc
récupérer le (ou les) article(s) installés dans la même rubrique et ayant pour
mot-clé « Date_sortie ».
Dans le squelette « article.html »,
insérons (par exemple juste après le titre) :
<BOUCLE_sortie(ARTICLES){id_rubrique}{titre_mot=Date_sortie}> <li> #TITRE : [<b>(#DATE|affdate)</b>] </BOUCLE_sortie> |
Cependant, nous avions décidé de ne pas utiliser le
titre de l’article contenant la date. Nous souhaitons en effet unifier la présentation
de cette information, sans pour autant nous obliger à saisir le titre toujours
de la même façon. Nous n’allons donc pas afficher le #TITRE de cet
article-bidon (ni même le titre de la rubrique, nous connaissons déjà le titre
du jeu, inutile de le rappeler ici). En revanche, pour différencier
(éventuellement) les différentes dates de sorties en fonction des machines,
nous allons insérer :
<BOUCLE_sortie(ARTICLES){id_rubrique}{titre_mot=Date_sortie}> <li> Date de sortie
<BOUCLE_machine_sortie(MOTS){id_article}{type=Machines}{", "}>#TITRE</BOUCLE_machine_sortie> : [<b>(#DATE|affdate)</b>] </BOUCLE_sortie> |
Ce qui lors de la visite donnera :
Date
de sortie Playstation : 22 août 2001
Date
de sortie Dreamcast : mai 2001
Cela ne nous satisfait pas encore (c’est un
tutorial, nous avons le droit d’être exigeants !) : la BOUCLE_sortie
affiche les dates de sortie sur toutes les machines ; or, notre article
peut ne pas traiter de toutes ces machines. Nous voulons donc n’afficher que
les dates de sortie correspondant aux machines traitées par l’article.
Attention, ça devient coton, et cela utilise une
subtilité des boucles :
<BOUCLE_mac2(MOTS){id_article}{type=Machines}> <BOUCLE_sortie(ARTICLES){id_rubrique}{titre_mot=Date_sortie}> <BOUCLE_verifier_mot(ARTICLES){id_article}{id_mot}> <li> Date de sortie
<BOUCLE_machine_sortie(MOTS){id_article}{type=Machines}{", "}>#TITRE</BOUCLE_machine_sortie> : [<b>(#DATE|affdate)</b>] </BOUCLE_verifier_mot> </BOUCLE_sortie> </BOUCLE_mac2> |
Vous reconnaissez les BOUCLE_sortie et
BOUCLE_machine_sortie, que nous n’avons pas modifées. En revanche, deux boucles
apparaissent.
(1) L’ensemble est placé dans une BOUCLE_mac2, qui
va récupérer les mots-clés des machines associées à cet article. À l’intérieur
de cette boucle, nous avons donc une certaine valeur pour « id_mot » (l’identifiant de chaque machine concernée
par l’article).
(2) La BOUCLE_sortie, inchangée, récupère tous les
articles de la rubrique associés au mot-clé « Date_sortie ». Notez
bien : cette boucle n’utilise pas « id_mot », donc les articles de cette boucle sont à
la fois des boucles associés au mot-clé dont « id_mot » et qui n’y
sont pas associés. Second point important, c’est une boucle (ARTICLES), cette boucle ne renvoit aucune information sur
les mots-clés ; donc la valeur « id_mot » fournie par BOUCLE_mac2
reste inchangée à l’intérieur de cette boucle.
(3) La BOUCLE_verif_mot est une subtilité
intéressante : c’est une boucle (ARTICLES) sélectionnant l’article dont l’identifiant est
« id_article » ; or nous sommes déjà dans la
BOUCLE_sortie, qui a déjà retourné un article. Donc la BOUCLE_verif_mot
retourne exactement le même résultat que la boucle précédente ! À cette
différence que la BOUCLE_verif_mot instaure un critère supplémentaire, {id_mot}, l’article doit donc être associé au mot-clé
« id_mot ». Résultat : si l’article retourné par BOUCLE_sortie
est associé au mot-clé « id_mot », on continue ; si l’article de
BOUCLE_sortie n’est pas associé, on s’arrête et on passe au suivant.
On
peut ainsi dire que la BOUCLE_verif_mot est un filtre : elle prend
l’article et vérifie s’il correspond au critère du mot-clé.
On
peut le présenter autrement : BOUCLE_verif_mot est seulement un critère de
sélection supplémentaire pour la BOUCLE_sortie. Le plus simple en effet aurait
été de ne pas utiliser de BOUCLE_verif_mot, mais d’ajouter un critère à
BOUCLE_sortie, ainsi :
<BOUCLE_sortie(ARTICLES){id_rubrique}{id_mot}{titre_mot=Date_sortie}> |
C’est-à-dire : récupérer les articles de la
même rubrique associés à la machine « id_mot » et au mot-clé « Date_sortie ».
Cela aurait été plus direct, malheureusement SPIP n’accepte pas ce genre de
constructions (il faut un seul critère portant sur les mots-clés dans une
boucle). Une telle boucle est donc refusée par SPIP.
Vous remarquerez que nous avons empilé quatre
boucles successives pour afficher une information aussi peu importante que la
date de sortie d’un jeu ! On peut le déplorer, mais on peut préférer
penser que, si l’on comprend bien la logique des boucles, les possibilités de
SPIP sont beaucoup plus étendues que ce que les squelettes standards laissent
supposer.
N.B.
En utilisant un peu de code PHP très simple, on aurait obtenu le même résultat
avec une seule boucle. Dans le développement d’un site, on aura certainement avantage
à gagner du temps en préférant la version de raccourcie utilisant un peu de
PHP. Mais nous tenions à montrer que des certains résultats peuvent très bien
se passer de PHP.
Déjà une tripotée d’articles dans ce tutorial, et
nous n’avons pas encore réalisé le sommaire !
Tenez-vous bien : nous n’allons pas encore
nous y attaquer. Le sommaire général du site, c’est en effet la partie la plus
difficile à réaliser graphiquement, et l’interface doit présenter les informations
les plus importantes de manière cohérente (ni trop, ni pas assez...). Avant de
créer le sommaire, il faut donc déjà connaître tous les types d’information
présents sur le site, et les différentes structures de navigation. Le sommaire
général, c’est donc pour la fin...
Nous allons donc commencer à réellement exploiter
les informations de notre site pour créer des « sommaires »
alternatifs. Les sites de jeux vidéo regorgent en effet de ces pages
récapitulatives présentant les jeux selon différents critères : le
calendrier des sorties, les meilleures notes...
Créons un couple de fichiers pour afficher la liste
des meilleurs jeux.
La page d’appel sera « notes.php3 », dont
le contenu est :
<?php $fond =
"notes"; $delais = 24 *
3600; include
("inc-public.php3"); ?> |
Nous pouvons maintenant commencer le squelette,
« notes.html » :
<html> <title>[#NOM_SITE_SPIP] Les meilleurs jeux</title> </head> <body> <blockquote> <h2>Les
meilleurs jeux</h2> <BOUCLE_notes(MOTS){type=Note}{par titre}{inverse}> <h1>#TITRE/10</h1> </BOUCLE_notes> </blockquote> </body> </html> |
Nous avons installé une première BOUCLE_notes, qui
affiche tous les mots-clés de type « Note » (c’est-à-dire
« 01 », « 02 », ..., « 10 ») par ordre
inversé (« 10 » en haut de liste).
Affichons le titre des articles correspondant à
chaque note (c’est-à-dire les articles associés au mot-clé renvoyé par la
BOUCLE_notes) :
<BOUCLE_notes(MOTS){type=Note}{par titre}{inverse}> <B_articles> <h1>#TITRE/10</h1> <BOUCLE_articles(ARTICLES){id_mot}{par date}{inverse}> <li>#TITRE </BOUCLE_articles> </BOUCLE_notes> |
La seule subtilité : le mot (la note) est
désormais affiché dans le texte conditionnel avant de la
BOUCLE_articles. De ce façon, seules les notes qui ont été réellement
attribuées à des articles sont affichées.
Nous affichons ici le titre de l’article. Ce n’est
pas ce qui nous intéresse. Nous voulons afficher :
le
titre du jeu, c’est-à-dire le titre de la rubrique qui contient
l’article ;
la
(les) machine(s) sur lesquelles tournent ces jeux ;
la
(les) date(s) de sortie du jeu.
Rien de bien compliqué, nous avons déjà réalisé ces
opérations sur d’autres pages (pour la date de sortie, nous recopions
directement ce que nous avons développé pour « article.html ») :
<BOUCLE_notes(MOTS){type=Note}{par titre}{inverse}> <B_articles> <h1>#TITRE/10</h1> <ul> <BOUCLE_articles(ARTICLES){id_mot}{par date}{inverse}> <BOUCLE_rubrique_jeu(RUBRIQUES){id_rubrique}> <li><b><a href="#URL_ARTICLE">#TITRE</a></b> </BOUCLE_rubrique_jeu> <BOUCLE_machines_jeu(MOTS){id_article}> #LOGO_MOT </BOUCLE_machines_jeu> <BOUCLE_mac2(MOTS){id_article}{type=Machines}> <BOUCLE_sortie(ARTICLES){id_rubrique}{titre_mot=Date_sortie}> <BOUCLE_verifier_mot(ARTICLES){id_article}{id_mot}> <br> Date de sortie <BOUCLE_machine_sortie(MOTS){id_article}{type=Machines}{", "}>#TITRE</BOUCLE_machine_sortie> : [<b>(#DATE|affdate)</b>] </BOUCLE_verifier_mot> </BOUCLE_sortie> </BOUCLE_mac2>
</BOUCLE_articles> </ul> </B_articles> </BOUCLE_notes> |
Seule petite subtilité : la balise
#URL_ARTICLE est
utilisée dans une boucle de type RUBRIQUES, de façon en réaliser le lien vers la page du test
plutôt que sur la page générale de la rubrique du jeu. Cette utilisation d’un
élément propre aux ARTICLES est
possible ici, car l’#URL_ARTICLE est réalisé à partir de la variable
« id_article ». Cet id_article est fourni par la
BOUCLE_articles, puis la BOUCLE_rubrique_jeu ne la modifie pas (puisqu’il
s’agit d’une boucle de RUBRIQUES). C’est le même principe qui permet d’utiliser
« id_mot » dans la BOUCLE_verifier_mot.
Dernier problème à régler : cette page
fonctionne bien au lancement du site et pendant les essais, avec une dizaine
d’articles, mais quand votre site aura un an et plusieurs milliers de jeux
tests (au minimum !), la liste sera trop longue. De toute façon, afficher
indifféremment des jeux sortis il y a une semaine et des jeux sortis depuis
plusieurs mois n’a pas
grand intérêt : un jeu noté « 9/10 » il y a un an serait
certainement moins bien noté aujourd’hui. Introduisons donc une limitation de
temps en modifiant la BOUCLE_articles :
<BOUCLE_articles(ARTICLES){id_mot}{age<90}{par
date}{inverse}> |
{age<90}, c’est-à-dire les articles publiés depuis moins de
3 mois.
Incontournable sur les pages de jeux vidéo, la page
indiquant les sorties récentes et les prochaines sorties.
La page d’appel sera
« sorties.php3 » :
<? $fond = "sorties"; $delais = 24 * 3600; include ("inc-public.php3"); ?> |
Commençons le fichier « sorties.html »
ainsi :
<html> <title>[#NOM_SITE_SPIP] Les
sorties</title> </head> <body> <blockquote> <h2>Les
prochaines sorties</h2> <BOUCLE_sorties(ARTICLES){titre_mot=Date_sortie}{par date}{age < 0}> <p>
#TITRE - [(#DATE|affdate)] </BOUCLE_sorties> </blockquote> </body> </html> |
Le #TITRE est celui
de l’article contenant la date de sortie ; c’est un titre bidon utilisé
par commodité dans l’espace privé. Il faut donc le remplacer par le titre du
jeu, c’est-à-dire le titre de la rubrique qui contient cet article. Toujours le
même processus. Nous voulons de plus afficher le logo des machines concernées
par cette sortie. Là non plus rien de compliqué.
<BOUCLE_sorties(ARTICLES){titre_mot=Date_sortie}{par date}{age < 0}> <p> <BOUCLE_rubrique_jeu(RUBRIQUES){id_rubrique}> <b><a
href="#URL_RUBRIQUE">#TITRE</a></b> </BOUCLE_rubrique_jeu> <BOUCLE_machines_jeu(MOTS){id_article}> #LOGO_MOT </BOUCLE_machines_jeu> - [(#DATE|affdate)] </BOUCLE_sorties> |
Il y a ici un défaut de navigation important :
il y a systématiquement un lien vers la rubrique du jeu. Or, et surtout pour
les jeux qui ne sont pas encore sortis, il est très possible qu’il n’y ait
aucune information publiée sur ce jeu, en dehors de sa date de sortie. On
risque alors de pointer vers une rubrique qui ne présente aucune information.
Modifions donc encore ce code, pour afficher non
plus un lien vers la rubrique elle-même, mais vers chaque type d’articles.
Afin d’obtenir une présentation un peu plus
condensée, commençons par créer une interface sous forme de lignes et de
colonnes (et au passage, nous supprimons le lien hypertexte fautif) :
<B_sorties> <table
cellpadding="4"> <BOUCLE_sorties(ARTICLES){titre_mot=Date_sortie}{par date}{age < 0}> <tr> <BOUCLE_rubrique_jeu(RUBRIQUES){id_rubrique}> <td><b>#TITRE</b></td> </BOUCLE_rubrique_jeu> <td align="center"> <BOUCLE_machines_jeu(MOTS){id_article}> #LOGO_MOT </BOUCLE_machines_jeu> <//B_machines_jeu> </td> <td>[(#DATE|affdate)]</td> </tr> </BOUCLE_sorties> </table> </B_sorties> |
Ce code ne présente pas de grosse difficulté.
Expliquons rapidement le positionnement des balises du tableau.
<table> et </table> sont placés en texte optionnel de la
BOUCLE_sorties ; de cette façon, si la liste des jeux à venir est vide, on
évite d’afficher un <table></table> peu élégant.
Les
<tr> et </tr> sont à l’intérieur de la BOUCLE_sorties, et
englobent l’intégralité de son contenu ; il s’agit ici de créer les lignes
du tableau.
Dans
la BOUCLE_rubrique_jeu, nous plaçons les <td> et </td> directement dans la boucle, autour du #TITRE. Nous savons en effet que, l’article étant
forcément dans une rubrique, il y aura forcément une (et une seule) réponse
dans BOUCLE_rubrique_jeu (inutile de placer ces codes dans du texte
optionnel ; et comme il n’y aura qu’une seule réponse, on peut se
placer à l’intérieur de la boucle).
C’est
différent pour la BOUCLE_machines_jeu : les <td
align="center"> et
</td> sont à
l’extérieur de la boucle, et ne sont même pas placés en code optionne.
En effet : (1) ils sont à l’extérieur de la boucle, car il peut y avoir
plusieurs machines concernées par cette date de sortie (c’est-à-dire plusieurs
mots-clés de machines associés à l’article) ; si on avait placé ces
balises à l’intérieur de la boucle, comme précédemment, le tableau perdrait son
alignement, puisqu’on créerait des « cases » supplémentaires à chaque
nouveau logo de mot-clé ; (2) ils ne sont pas placés dans du texte
optionnel, car ce ne sont pas des balises optionnelles ; si on a oublié
d’indiquer une machine pour la date de sortie, il faut tout de même créer cette
« case » du tableau, certes vide, pour conserver l’alignement. Enfin,
nous avons placé un en texte optionnel alternatif : s’il n’y a pas de mot-clé
de machine associé à la date de sortie, on affiche cet espace insécable pour
que la « case » ait un contenu (dans de nombreux butineurs, une case <td></td> n’est pas affichée de la même façon qu’une case <td> </td>.
Nous allons maintenant afficher pour chaque jeu la
liste des Tests qui concernent ce jeu (insérons cela juste avant le </tr> final de la ligne) :
<td>
<B_tests_jeu>
<b>Test :</b> <BOUCLE_tests_jeu(ARTICLES){id_rubrique}{titre_mot=test}> <br><a
href="#URL_ARTICLE">#TITRE</a> </BOUCLE_tests_jeu>
<//B_tests_jeu> </td> |
Cette BOUCLE_tests_jeu utilise des méthodes déjà
expliquées.
Cependant, cela ne nous convient pas encore :
nous affichons ici tous les tests, pour toutes les machines, alors que notre
date de sortie ne concerne pas forcément toutes les versions du jeu (on peut
ici afficher la date de sortie de la versions Dreamcast, alors qu’on a déjà
publié des tests pour les versions Playstation, Dreamcast, Window...).
On ne veut donc afficher que les tests qui
concernent les versions concernées par cette date de sortie. Nous avons déjà
réalisé un processus similaire dans la page « article.html » pour
n’afficher que les dates de sortie sur les mêmes machines que l’article affiché
(BOUCLE_mac2). Cela donne :
<td> <BOUCLE_mac2(MOTS){id_article}{type=Machines}>
<BOUCLE_tests_jeu(ARTICLES){id_rubrique}{titre_mot=test}>
<BOUCLE_verifier_mot(ARTICLES){id_article}{id_mot}> <li><a
href="#URL_ARTICLE">#TITRE</a> </BOUCLE_verifier_mot> </BOUCLE_tests_jeu> </BOUCLE_mac2> </td> |
La BOUCLE_mac2 récupère la liste des machines de la
date de sortie. La BOUCLE_tests_jeu récupère l’ensemble des tests de jeu de la
rubrique (toutes machines confondues). La BOUCLE_verifier_mot vérifie pour
chaque test récupéré dans BOUCLE_tests_jeu qu’il est associé à la machine
récupérée par BOUCLE_mac2.
Nous avons pour l’instant supprimé l’affichage de
« Tests :» en texte conditionnel pour des raisons de lisibilié. Voici
maintenant le code, exactement sur le même principe, qui permet d’afficher
cette indication (ainsi que le ) :
<td> <B_mac2>
<b>Tests :</b> <BOUCLE_mac2(MOTS){id_article}{type=Machines}><BOUCLE_tests_jeu(ARTICLES) {id_rubrique} {titre_mot=test}><BOUCLE_verifier_mot(ARTICLES){id_article}{id_mot}> <li><a href="#URL_ARTICLE">#TITRE</a> </BOUCLE_verifier_mot></BOUCLE_tests_jeu></BOUCLE_mac2> <//B_mac2> </td> |
Notez bien : les BOUCLE_mac2, BOUCLE_tests_jeu
et BOUCLE_verifier_mot sont « collées », c’est-à-dire qu’elles ne
sont plus séparées par des retours à la ligne ni par des espaces. En effet,
nous testons le « contenu » de la BOUCLE_mac2 pour savoir si nous
affichons l’indication « Tests :» ou le (les textes conditionnels). Si nous avions
conservé les retours à la ligne ou des espaces blancs entre les boucles, quel
que soit le résultat de BOUCLE_tests_jeu et de BOUCLE_verifier_mot, la
BOUCLE_mac2 aurait été considérée comme ayant un contenu à cause de l’affichage
de ces retours-chariot.
Pour afficher une liste des previews, dupliquons
simplement ce code, en modifiant le nom des boucles et en remplaçant titre_mot=test par titre_mot=preview :
<td> <B_mac3> <b>Previews :</b> <BOUCLE_mac3(MOTS){id_article}{type=Machines}><BOUCLE_preview_jeu(ARTICLES) {id_rubrique}{titre_mot=preview}><BOUCLE_verifier_mot3(ARTICLES) {id_article}{id_mot}> <li><a
href="#URL_ARTICLE">#TITRE</a> </BOUCLE_verifier_mot3></BOUCLE_preview_jeu></BOUCLE_mac3>
<//B_mac3> </td> |
Ajoutons enfin une boucle pour les
« news » concernant ce jeu. Ici nous ne nous préoccuperons pas des
machines, puisque toutes les news sont affichées sur une unique page. Nous
n’afficherons donc pas de #TITRE, mais directement la mention « Les
news » ; le lien hypertexte pointe vers la page spécifique que nous
avons créée pour ce jeu. Notez enfin la restriction {0,1} qui permet de ne récupérer qu’une seule
« news » pour créer un unique lien.
<td> <BOUCLE_news_jeu(ARTICLES){id_rubrique}{titre_mot=news}{0,1}> <br><a
href="news_jeu.php3?id_rubrique=#ID_RUBRIQUE">Les news</a> </BOUCLE_news_jeu> <//B_news_jeu> </td> |
Pour être exhaustif, il resterait à recommencer
l’opération avec les Soluces et les Astuces. Mais puisqu’il s’agit ici
d’afficher une liste de sorties, considérons que ces informations ne sont pas
pertinentes ici. Même si, techniquement, on peut les afficher facilement,
faisons un choix éditorial : l’information n’est pas intéressante ici et
surchargerait l’interface, donc nous préférons ne pas l’indiquer. (Mais si cela
vous amuse, vous pouvez vous entraîner en les intégrant vous-même.)
Nous commençons à avoir une idée plus précise de la
navigation de notre site. Réalisons une première version du sommaire.
<html> <head> <title>[#NOM_SITE_SPIP]
Sommaire</title> </head> <body> <center> <a
href="sorties.php3">Les prochaines sorties</a> | <a
href="notes.php3">Les meilleurs jeux du moment</a> </center> <BOUCLE_secteurs(RUBRIQUES){id_parent=0}{par titre}> <p><b><a
href="#URL_RUBRIQUE">#TITRE</a></b> <B_sous_rubriques> <ul>
<BOUCLE_sous_rubriques(RUBRIQUES){id_parent}> <li><a
href="#URL_RUBRIQUE">#TITRE</a> </BOUCLE_sous_rubriques> </ul> </B_sous_rubriques> </BOUCLE_secteurs> </body> </html> |
Avant de placer les boucles qui permettront
d’afficher les nouveautés du site, nous nous contentons de créer (à la main)
les liens vers les deux sommaires alternatifs, et d’afficher la structure du
site (uniquement les grandes rubriques et leurs sous-rubriques).
Installons la liste des cinq plus récents tests
publiés sur le site. Pour chacun, nous afficherons (en plus du logo, du titre
du test, et son descriptif) :
une
boucle (RUBRIQUES) pour récupérer le titre du jeu ;
une
boucle (MOTS) avec pour type de mot « note » pour
afficher la note ;
une
seconde boucle (MOTS) avec pour type « machines » pour afficher le
logo des machines concernées.
Rien que nous ne sachions déjà faire.
<BOUCLE_tests(ARTICLES){titre_mot=test}{par date}{inverse}{0,5}> <p><div
style="border:1px solid black"> [(#LOGO_ARTICLE_RUBRIQUE|left|#URL_ARTICLE)] <BOUCLE_rub_tests(RUBRIQUES){id_rubrique}> <h3>#TITRE</h3> </BOUCLE_rub_tests> <h4>#TITRE</h4> <BOUCLE_note_tests(MOTS){id_article}{type=Note}> <b>NOTE : #TITRE/10</b><p> </BOUCLE_note_tests> <BOUCLE_mac_tests(MOTS){id_article}{type=Machines}> [(#LOGO_MOT|left)] </BOUCLE_mac_tests> [(#DESCRIPTIF)] <p
align="right"><a href="#URL_ARTICLE">Lire ce test...</a> </div> </BOUCLE_tests> |
Ajoutons maintenant les cinq dernières previews,
cinq soluces et cinq astuces. Les présentations sont différentes à chaque fois,
mais le principe est rigoureusement similaire à la boucle précédente (dans des
versions simplifiées, puisque nous voulons afficher moins d’informations) :
<B_previews> <p><b>Previews
:</b> <ul> <BOUCLE_previews(ARTICLES){titre_mot=preview}{par date}{inverse}{0,5}>
<BOUCLE_rub_previews(RUBRIQUES){id_rubrique}>
<li><b>#TITRE</b> /
</BOUCLE_rub_previews> <a href="#URL_ARTICLE">#TITRE</a>
<BOUCLE_mac_previews(MOTS){id_article}{type=Machines}> [(#LOGO_MOT)] </BOUCLE_mac_previews> </BOUCLE_previews> </ul> </B_previews> <B_soluces> <p><b>Soluces :</b> <ul> <BOUCLE_soluces(ARTICLES){titre_mot=soluce}{par date}{inverse}{0,5}>
<BOUCLE_rub_soluces(RUBRIQUES){id_rubrique}>
<li><b><a href="#URL_ARTICLE">#TITRE</a></b>
</BOUCLE_rub_soluces>
<BOUCLE_mac_soluces(MOTS){id_article}{type=Machines}>
(#TITRE)
</BOUCLE_mac_soluces> </BOUCLE_soluces> </ul> </B_soluces> <B_astuces> <p><b>Astuces :</b> <ul> <BOUCLE_astuces(ARTICLES){titre_mot=astuces}{par date}{inverse}{0,5}>
<BOUCLE_rub_astuces(RUBRIQUES){id_rubrique}>
<li><b><a href="#URL_ARTICLE">#TITRE</a></b>
</BOUCLE_rub_astuces>
<BOUCLE_mac_astuces(MOTS){id_article}{type=Machines}>
(#TITRE)
</BOUCLE_mac_astuces> </BOUCLE_astuces> </ul> </B_astuces> |
Enfin, la liste des news. Toujours le même
principe ; cette fois, le lien hypertexte pointe vers la page commune aux
news d’un jeu. Le lien se fait sur le titre du jeu (c’est-à-dire le titre de la
rubrique), et nous affichons le titre de la news.
<B_news> <p><b>News :</b> <ul> <BOUCLE_news(ARTICLES){titre_mot=news}{par date}{inverse}{0,5}> <BOUCLE_rub_news(RUBRIQUES){id_rubrique}> <li><b><a
href="news_jeu.php3?id_rubrique=#ID_RUBRIQUE">#TITRE</a>:</b> </BOUCLE_rub_news> #TITRE </BOUCLE_news> </ul> </B_news> |
Il nous reste désormais à indiquer la structure
thématique du site (par grand genre de jeux : Action/aventure, Plateforme,
Sport...). Là encore rien de bien compliqué :
<BOUCLE_secteurs(RUBRIQUES){id_parent=0}{par titre}> <p><b><a
href="#URL_RUBRIQUE">#TITRE</a></b> <B_sous_rubriques> <ul>
<BOUCLE_sous_rubriques(RUBRIQUES){id_parent}>
<BOUCLE_art_sous(ARTICLES){id_rubrique}> </BOUCLE_art_sous> <li><a
href="#URL_RUBRIQUE">#TITRE</a> <//B_art_sous>
</BOUCLE_sous_rubriques> </ul> </B_sous_rubriques> </BOUCLE_secteurs> |
Notons tout de même cette subtilité : dans les
sous-rubriques, la BOUCLE_art_sous vérifie la présence d’articles (cette boucle
n’affiche rien). L’affichage du titre et du lien et du titre de la
sous-rubrique n’est effectif que s’il n’y pas de rubrique dans la
sous-rubrique, puisque cet affichage est placé dans le texte optionnel
alternatif. En effet, il ne faudrait pas afficher les rubriques de jeu
placés directement dans une rubrique.
Notre sommaire est complet. Pas terminé pour autant
(dans les articles suivants, nous étendrons encore ses possibilités), mais
complet :
la
structure thématique du site par grande rubriques de type de jeux est
présentée ;
les
tests récents (dont nous considérons - et c’est un choix éditorial - qu’ils
constituent l’élément le plus important du site) sont affichés de manière très
visible ;
nous
exploitons l’indication des machines ;
nous
exploitons les « types d’articles » (les news, previews, tests,
soluces, astuces sont présentés séparément) ;
la
note des jeux est exploitée, ainsi que les dates des sorties...
Tout cela, notez bien, sans utiliser la moindre
ligne de code PHP, et sans modifier la structure de la base de données. Nous
n’avons même pas détourné certaines indications des articles pour y arriver (on
aurait pu par exemple décider que le surtitre des articles serait utilisé pour
indiquer la machine, et le soustitre pour indiquer la note ; nous aurions
ainsi pu afficher ces informations).
Les amateurs de jeux vidéo possèdent généralement
une seule machine (deux pour les accros, trois pour les collectionneurs...).
Une page de sommaire général, si elle se justifie à l’arrivée sur le site (le
visiteur indique l’URL du site, on ne sait donc pas à priori ce qu’il utilise
comme machine), contient trop d’informations superflues pour le propriétaire
d’une seule machine : le possesseur d’une Playstation 2 n’est pas
concerné par le dernier jeu sorti sur Dreamcast.
Donc, il faut pouvoir présenter un sommaire
différent pour chaque machine. Un sommaire qui n’affiche que les jeux de cette
machine.
Nous allons donc créer un squelette dont le contenu
change en fonction de la machine. Nous nommerons ces fichiers :
« sommaire_machine.php3 » et « sommaire_machine.html ». La
machine étant indiquée, dans notre structure, par un mot-clé, ces pages
dépendront donc d’un « id_mot ». Chaque machine différente sera donc
appelée par une URL du type :
sommaire_machine.php3 ?id_mot=23 (23 étant le numéro du mot-clé de la machine).
Revenons à notre sommaire général : nous allons
y inclure les liens vers ces sommaires spécialisés ; la création
automatique de ces liens (avec les « id_mot » correspondants) nous évitera de devoir
effectuer les tests en cherchant les numéros (id_mot) de chaque machine. Dans
« sommaire.html », insérons la boucle suivante :
<table
cellpadding=5><tr> <BOUCLE_somm_mac(MOTS){type=Machines}{par titre}> <td><a
href="sommaire_machine.php3?id_mot=#ID_MOT">#LOGO_MOT</a></td> </BOUCLE_somm_mac> </tr></table> |
Attention : si l’on a réalisé des logos avec
survol, le lien ne fonctionnera pas correctement, car SPIP ajoutera une
commande javascript. Le code ci-dessus ne fonctionne qu’à la condition que le
logo de chaque mot ne soit constitué que d’un unique fichier (pas d’image de
survol).
Le moyen le plus simple et le plus efficace
d’éviter un tel désagrément consiste à ne pas utiliser directement #LOGO_MOT, qui construit l’intégralité de la balise HTML de l’image,
éventuellement avec un petit code javascript pour gérer le survol, mais à la
place l’appel d’une image dont le fichier est : [(#LOGO_MOT|fichier)] (ce qui retourne uniquement le nom du fichier de
l’image).
La boucle devient :
<table cellpadding=5><tr> <BOUCLE_somm_mac(MOTS){type=Machines}{par titre}> <td><a
href="sommaire_machine.php3?id_mot=#ID_MOT"><img src='IMG/[(#LOGO_MOT|fichier)]' border=0></a> </td> </BOUCLE_somm_mac> </tr></table> |
Comme toujours :
<?php $fond =
"sommaire_machine"; $delais
= 24 * 3600; include
("inc-public.php3"); ?> |
Inutile de nous compliquer la vie : dupliquons
le fichier « sommaire.html », et renommons-le
« sommaire_machine.html ».
Puisque cette page dépend d’un « id_mot », nous commençons par ajouter une
BOUCLE_principale qui va contenir l’intégralité des autres boucles. Il suffit
donc d’ajouter l’appel de cette boucle juste après <body> et de la refermer juste avant </body> (tout en fin de fichier) :
<body> <BOUCLE_principale(MOTS){id_mot}> ... </BOUCLE_principale> </body> |
Le titre de la page, qui jusqu’à présent ne
contenait que : <h1>#NOM_SITE_SPIP</h1, est modifié pour afficher le nom et le logo de la
machine (c’est-à-dire du mot-clé correspondant à « id_mot ») :
<h1>#NOM_SITE_SPIP /
#LOGO_MOT #TITRE</h1> |
La BOUCLE_somm_mac, qui affiche tous les logos des
machines pour créer les liens vers les sommaires spécifiques, ne doit plus
contenir le logo de la machine principale (nous sommes déjà sur cette page,
inutile donc de créer un lien vers elle-même). Il suffit d’insérer le critère {exclus} dans la définition de cette boucle :
<BOUCLE_somm_mac(MOTS){type=Machines}{exclus}{par titre}> ... </BOUCLE_somm_mac> |
La BOUCLE_tests, qui affiche les derniers tests
publiés, ne doit désormais afficher que les tests qui concernent des jeux sur
la machine sélectionnée. Pour cela, nous allons ajouter à l’intérieur de cette
boucle une BOUCLE_verif_test, qui va vérifier pour chaque article qu’il
concerne bien la machine choisie.
Inconvénient désormais : la BOUCLE_tests
affichait les cinq derniers tests. Désormais, sur ces cinq articles, nous ne
sélectionnons que ceux qui concernent notre machine. Il est fort probable que
cela donne moins de cinq articles, et dans certains cas extrêmes, cela
n’affichera plus aucun article. Modifions le critère, et décidons d’afficher
non pas les cinq derniers tests ({0,5}), mais tous les tests publiés depuis moins de
trois mois ({age<90}) ; on pourra modifier cette valeur en
fonction de l’activité réelle du site (si le site est très actif, on réduira le
délai de cette boucle, si le site publie peu d’articles, on pourra le
rallonger).
Au passage, supprimons la petite boucle qui
affichait le logo des machines concernées : cela devient inutile, puisque
cette page n’affiche que les informations d’une unique machine.
La boucle devient :
<BOUCLE_tests(ARTICLES){titre_mot=test}{par date}{inverse}{age < 90}> <BOUCLE_verif_test(ARTICLES){id_article}{id_mot}>
<p><div style="border:1px solid black">
[(#LOGO_ARTICLE_RUBRIQUE|left|#URL_ARTICLE)] <BOUCLE_rub_tests(RUBRIQUES){id_rubrique}> <h3>#TITRE</h3> </BOUCLE_rub_tests> <h4>#TITRE</h4> <BOUCLE_note_tests(MOTS){id_article}{type=Note}> <b>NOTE : #TITRE/10</b><p> </BOUCLE_note_tests> [(#DESCRIPTIF)] <p
align="right"><a href="#URL_ARTICLE">Lire ce
test...</a>
</div> </BOUCLE_verif_test> </BOUCLE_tests> |
Le principe est identique pour les previews,
soluces, astuces, news : on ajoute une boucle de vérification, et on
supprime la boucle qui affiche la liste des machines concernées :
<B_previews> <p><b>Previews :</b> <ul> <BOUCLE_previews(ARTICLES){titre_mot=preview}{par date}{inverse}{age < 90}><BOUCLE_verif_previews(ARTICLES){id_article}{id_mot}> <BOUCLE_rub_previews(RUBRIQUES){id_rubrique}> <li><b>#TITRE</b> /
</BOUCLE_rub_previews> <a
href="#URL_ARTICLE">#TITRE</a> </BOUCLE_verif_previews></BOUCLE_previews> </ul> </B_previews> <B_soluces> <p><b>Soluces
:</b> <ul> <BOUCLE_soluces(ARTICLES){titre_mot=soluce}{par date}{inverse}{age <
90}><BOUCLE_verif_soluces(ARTICLES){id_article}{id_mot}> <BOUCLE_rub_soluces(RUBRIQUES){id_rubrique}> <li><b><a href="#URL_ARTICLE">#TITRE</a></b> </BOUCLE_rub_soluces> </BOUCLE_verif_soluces></BOUCLE_soluces> </ul> </B_soluces> <B_astuces> <p><b>Astuces
:</b> <ul> <BOUCLE_astuces(ARTICLES){titre_mot=astuces}{par date}{inverse}{0,5}><BOUCLE_verif_astuces(ARTICLES){id_article}{id_mot}> <BOUCLE_rub_astuces(RUBRIQUES){id_rubrique}> <li><b><a href="#URL_ARTICLE">#TITRE</a></b> </BOUCLE_rub_astuces> </BOUCLE_verif_astuces></BOUCLE_astuces> </ul> </B_astuces> <B_news> <p><b>News :</b> <ul> <BOUCLE_news(ARTICLES){titre_mot=news}{par date}{inverse}{0,5}><BOUCLE_verif_news(ARTICLES){id_article}{id_mot}> <BOUCLE_rub_news(RUBRIQUES){id_rubrique}> <li><b><a href="news_jeu.php3?id_rubrique=#ID_RUBRIQUE">#TITRE</a>:</b> </BOUCLE_rub_news> #TITRE </BOUCLE_verif_news></BOUCLE_news> </ul> </B_news> |
Important. Vous noterez ci-dessus que la boucle de vérification est
« collée » à la première boucle (par exemple, entre <BOUCLE_previews(ARTICLE)...> et <BOUCLE_verif_previews(ARTICLE)...>, il n’y a ni espace ni retour à la ligne). En
effet, le texte conditionnel avant de la première boucle (ici, la
mention « Previews ») est activé si la boucle contient au moins un
caractère. S’il y a un espace ou un retour chariot avant l’appel de la boucle
de vérification, alors même si la boucle n’affiche aucun article (car, depuis
trois mois, on n’a publié aucun article de ce type pour cette
machine), cet espace parasite activerait l’affichage du code conditionnel.
Voyons maintenant l’affichage des prochaines
sorties. On peut décider de créer une nouvelle page des sorties, concernant
uniquement la machine sélectionnée, mais nous préférerons ici afficher
directement ces sorties sur notre sommaire spécifique (les sorties n’étant pas
si nombreuses par machines). En appliquant les mêmes méthodes que précédemment,
on remplace le lien « Les prochains sorties » par :
<B_sorties> <b>Les
sorties #TITRE du
prochain mois:</b> <ul> <BOUCLE_sorties(ARTICLES){titre_mot=Date_sortie}{par date}{age < 0}><BOUCLE_sorties_verif(ARTICLES){id_article}{id_mot}> <li>[(#DATE|affdate)]: <BOUCLE_rub_sorties(RUBRIQUES){id_rubrique}> #TITRE </BOUCLE_rub_sorties> </BOUCLE_sorties_verif></BOUCLE_sorties> </ul> </B_sorties> |
Sur le même principe, affichons la liste des jeux
préférés pour cette machine depuis six mois :
<B_notes> <b>Nos jeux
préférés depuis 6 mois:</b> <ul> <BOUCLE_notes(ARTICLES){type_mot=note}{par titre_mot}{inverse}{age<180}><BOUCLE_notes_verif(ARTICLES){id_article} {id_mot}> <BOUCLE_rub_notes(RUBRIQUES){id_rubrique}> <li> #TITRE </BOUCLE_rub_notes> <BOUCLE_lanote(MOTS){id_article}{type=note}> (#TITRE/10) </BOUCLE_lanote>
</BOUCLE_notes_verif></BOUCLE_notes> </ul> </B_notes> |
La seule subtilité pour l’instant est le classement
des articles associés aux mots-clés de type « note » selon le critère
{par titre_mot}{inverse} (fonction apparue dans le version 1.3 de SPIP). En
effet, les mots de type « note » sont de la forme « 01 »,
« 02 »..., « 10 » ; on peut donc demander à les
classer de 10 à 1.
Cependant, cette présentation ne nous convient pas
encore : nous prétendons afficher nos « jeux préférés », alors
qu’il s’agit seulement d’un classement par note. Si un jeu est sorti depuis
moins de six mois et s’est
ramassé une note catastrophique, il sera dans les « jeux préférés »
(en bas de liste, mais présent tout de même) !
Nous devons donc trouver un moyen d’afficher
uniquement les jeux ayant eu une note supérieure à « 07 » (choix
arbitraire). Si vous pensez utiliser pour cela la BOUCLE_notes, en y ajoutant
simplement la mention {titre_mot>07}, cela ne fonctionnera pas : SPIP n’accepte
qu’un seul critère basé sur les mots-clés dans les boucles autres que les
boucles de type (MOTS).
Nous allons utiliser la BOUCLE_lanote (qui affiche
la note), et lui demander de ne sélectionner que les notes supérieures à 7
(puisqu’il s’agit ici d’une boucle de type (MOTS), on peut lui fournir plusieurs contraites sur les
mots-clés). La BOUCLE_rub_notes, qui affiche le titre du jeu, est alors placé
en texte optionnel après de la BOUCLE_lanote :
si
la note est supérieure à 7, la BOUCLE_rub_notes est effectuée ;
sinon
rien n’est affiché.
Attention : il est toujours délicat de placer une boucle dans
le texte optionnel d’une autre boucle (SPIP peut se mélanger facilement
les pinceaux). Pour une raison étrange, cela est possible dans le texte
optionnel après, mais pas dans le texte optionnel avant.
Sachant que nous ne récupérerons que les articles
notés « 08 », « 09 », « 10 », classés du meilleur
au moins bon, nous considérons désormais inutile de rappeler la note elle-même.
La BOUCLE_lanote est donc vide, elle ne sert plus qu’à activer ou désactiver la
BOUCLE_rub_notes.
Enfin, puisque la BOUCLE_lanote devient un nouveau
« filtre » appliqué à la sélection d’articles, il faut supprimer les
blancs et les retours chariot autour de cette boucle, de façon à ne réellement
activer l’expression « Nos jeux préférés » que si au moins un article
est vraiment affiché.
Cela nous donne :
<B_notes> <b>Nos jeux
préférés depuis 6 mois:</b> <ul> <BOUCLE_notes(ARTICLES){type_mot=note}{par titre_mot}{inverse}{age<180}><BOUCLE_notes_verif(ARTICLES) {id_article}{id_mot}><BOUCLE_lanote(MOTS){id_article}{titre>07}{type=note}> </BOUCLE_lanote>
<BOUCLE_rub_notes(RUBRIQUES){id_rubrique}> <li> <a
href="#URL_RUBRIQUE">#TITRE</a> </BOUCLE_rub_notes> </B_lanote></BOUCLE_notes_verif></BOUCLE_notes> </ul> </B_notes> |
Tout cela peut sembler un peu indigeste, mais le
tout est que cela fonctionne, et toujours sans la moindre fonction PHP !
Maintenant que nos pages de sommaires spécifiques
sont presque terminées, nous constatons, en passant de l’une à l’autre, que
certaines pages sont vides. En effet, nous n’affichons ici que des informations
de moins de trois mois (pour les
tests, les news...). Si une machine n’a été concernée par aucun article depuis
trois mois, ou même si une machine n’a encore aucun article du tout (même si
cela est prévu par un mot-clé, il est très possible que personne sur votre site
n’ait encore écrit au sujet des jeux Linux).
Il faut donc modifier la BOUCLE_somm_mac (celle qui
affiche les logos des différentes machines) pour que seules les machines ayant
réellement des articles publiés depuis trois mois soient
affichés. Il suffit pour cela d’ajouter une boucle vérifiant la présence
d’article datés de moins de trois mois associés à ce mot-clé. Ce qui nous
donne :
<BOUCLE_somm_mac(MOTS){type=Machines}{exclus}{par titre}> <BOUCLE_verif_somm(ARTICLES){id_mot}{0,1}{age < 90}> <td> <a
href="sommaire_machine.php3?id_mot=#ID_MOT"><img src='IMG/[(#LOGO_MOT|fichier)]' border=0></a> </td> </BOUCLE_verif_somm> </BOUCLE_somm_mac> |
On pensera à effectuer le même remplacement dans la
page « sommaire.html » du sommaire général (penser à supprimer le
critère {exclus} dans ce cas).
Monter son site consacré aux jeux vidéo, c’est
bien ; mais d’autres y ont pensé avant vous, et une tripotée de sites
existe déjà. Pour enrichir encore l’information présentée sur notre site, nous
allons donc indiquer des articles consacrés aux jeux que nous présentons.
Cela se fait, dans l’espace privé, par le lien
« Référencer un site Web » accessible depuis chaque rubrique. Notre
structure, qui regroupe tous les articles consacrés à un jeu dans une rubrique
dédiée, facilite l’opération ; il suffit de « référencer un site
Web » dans la rubrique qui traite du jeu concerné par le lien.
Tirons à nouveau profit de nos mots-clés. Pour
chaque page référencée sur le Web, nous indiquerons :
la
machine concernée par cet article (la page référencée concerne une version
Playstation, Xbox...) ;
le
type d’article (test, preview...) ; si la page n’entre dans aucune
catégorie, nous n’indiquerons pas de type d’article ;
éventuellement,
la note attribuée au jeu sur ce site extérieur.
Afin d’enrichir encore l’information, nous souhaitons indiquer, le cas
échéant :
qu’il
s’agit du site officiel du jeu ;
que
l’article est en anglais (vous pouvez prévoir d’autres langues si vous le
souhaitez).
En effet, certaines solutions de jeu circulent sur
le Net en anglais bien avant d’apparaître en français.
Pour cela, créons un nouveau groupe de mots-clés,
intitulé « Sites », et deux mots : « En anglais » et
« Site officiel » (on pourra aussi créer « En japonais »,
« En italien »...). Nous attribuons un petit logo pour chacun de ces
mots-clés (ce qui permettra de créer une interface plus compacte). Ce qui nous
donne :
Reprenons notre fichier
« rubrique.html ». Nous ajoutons la boucle suivante à la fin de la
BOUCLE_les_articles :
<B_sites><p>SUR
LE WEB : <ul> <BOUCLE_sites(SYNDICATION){id_rubrique}{doublons}>
<li>[(#LOGO_SITE|#URL_SITE)] <a href="#URL_SITE">#NOM_SITE</a> <BOUCLE_note_sites(MOTS){type=Note}{id_syndic}> #TITRE/10
</BOUCLE_note_sites>
<BOUCLE_type_sites(MOTS){type=Sites}{id_syndic}> #LOGO_MOT
</BOUCLE_type_sites>
<BOUCLE_mac_sites(MOTS){type=Machines}{id_syndic}> #LOGO_MOT
</BOUCLE_mac_sites> </BOUCLE_sites> </ul> </B_sites> |
La BOUCLE_sites affiche le logo et le nom des sites
référencés. Pour chaque site, les trois boucles incluses affichent
successivement :
BOUCLE_note_sites :
la note attribuée au jeu par cet article ;
BOUCLE_type_sites :
s’il s’agit du site officiel, ou si l’article est en anglais ;
BOUCLE_mac_sites :
la machine concernée par le site.
Vous noterez le critère {doublons} dans la BOUCLE_sites. Il interdit d’afficher des
site référencés qui auraient déjà été affichés. Pour l’instant, c’est inutile,
puisque c’est le seul endroit de ce squelette où nous récupérons des sites
référencés.
Complétons cependant notre processus. Puisque nous
nous autorisons, si cela est pertinent, à indiquer pour chaque site référencé
s’il s’agit d’un test, d’une preview, d’une soluce..., exploitons cette
information. Nous allons intégrer, à la suite de nos propres tests, soluces...
les liens vers les pages référencées de ce type.
Juste après la BOUCLE_tests, nous allons recopier
la boucle précédente (en renommant les boucles), et légèrement la modifier,
pour n’afficher que les sites référencés auxquels nous avons attribué le type
« Test » :
<B_sites_tests><p>Des tests sur
le Web : <ul> <BOUCLE_sites_tests(SYNDICATION){id_rubrique}{titre_mot=Test}{doublons}> <li>[(#LOGO_SITE|#URL_SITE)] <a href="#URL_SITE">#NOM_SITE</a> <BOUCLE_note_sites_tests(MOTS){type=Note}{id_syndic}> #TITRE/10 </BOUCLE_note_sites_tests> <BOUCLE_type_sites_tests(MOTS){type=Sites}{id_syndic}> #LOGO_MOT </BOUCLE_type_sites_tests> <BOUCLE_mac_sites_tests(MOTS){type=Machines}{id_syndic}> #LOGO_MOT </BOUCLE_mac_sites_tests> </BOUCLE_sites_tests> </ul> </B_sites_tests> |
Nous reproduisons cela pour les previews, les
soluces et les astuces.
Le critère {doublons} devient utile : chaque type de sites étant
affiché successivement (d’abord les tests, puis les previews...), notre toute
dernière boucle (BOUCLE_sites) n’affiche plus que les sites référencés qui ne
sont d’aucun type. Par exemple, le site officiel d’un jeu, ou le site d’un fan
du jeu, ne peut pas être décrit comme uniquement un test ou une solution ;
ils seront donc affichés par la BOUCLE_sites.
Pour terminer l’exploitation des sites référencés,
recopions ces nouvelles boucles dans « article.html » (où nous
affichons déjà les autres articles concernant le même jeu).
Notre site n’autorise pas, pour l’instant, les
visiteurs du site à participer. Or ce genre de site se prète particulièrement
bien aux forums ouverts aux visiteurs :
d’abord
parce que sur ce genre de sujet, les utilisateurs aiment à donner leur
avis ; les forums de jeux vidéo sont très fournis...
parce
que c’est un élément indispensable au contenu éditorial du site : il est
en effet impossible de prévoir à l’avance toutes les questions concernant un
jeu (trucs, astuces, bloqué à tel niveau, comment reconfigurer la carte
graphique RadeTI 2525 de son PC...) ; les forums sont le lieu
indispensable pour ce genre de questions/réponses.
Avant d’intégrer des forums sur notre site, il faut
d’abord définir où et comment les intégrer.
Première
question : où ?
Avec les squelettes fournis en standard avec SPIP,
on a pris l’habitude d’installer les forums directement sous chaque article.
Or, ici, notre structure éditoriale est totalement différente : tous les
articles concernant un jeu sont regroupés dans une rubrique. Nous
pourrions certes continuer à installer les forums sous chaque article, mais
cela serait sans doute peu efficace : plus qu’une réaction à un article
précis, le visiteur voudra certainement discuter du jeu « en
général ».
Nous décidons (encore un choix éditorial
arbitraire !) que les forums ne concerneront pas chaque article (chaque
test, chaque preview, etc.), mais le jeu dans son ensemble. C’est-à-dire la
rubrique du jeu. Dans chaque article, nous ferons un lien vers une page commune
affichant le forum de la rubrique.
Deuxième
question : comment ?
La présentation du forum est importante :
faut-il tout afficher d’un seul coup (c’est toujours très pratique), ou bien
afficher d’abord une liste des titres des messages, et une page spécifique pour
chaque message.
Sur un site de jeux vidéo, nous pouvons prévoir des
forums très actifs, avec de nombreux messages, certains très longs (certains
visiteurs vont certainement poster la critique complète d’un jeu, une soluce
interminable...). Impossible dès lors d’afficher tout le contenu de tous les
messages sur une seule page.
Nous choisissons donc de présenter d’abord la liste
des messages, avec uniquement leur titre ; puis nous réaliserons une
seconde page affichant chaque message spécifique.
La page qui affichera la liste complète des
messages d’un forum sera donc la page « forum_jeu.php3 ». Cette page
est appelée avec un numéro de rubrique (puisque c’est la rubrique qui contient
tous les articles du jeu).
Commençons par intégrer le lien vers cette page
dans la navigation de notre site.
Sur la page « article.html », ajoutons le
lien vers le forum du jeu. Insérons (par exemple après l’affichage des #NOTES) :
<p><b><a
href="forum_jeu.php3?id_rubrique=#ID_RUBRIQUE">Le forum de ce
jeu</a></b> |
Contentons-nous pour l’instant de ce seul lien de
navigation. En effet, pour réaliser un affichage plus complet (nombre de
messages notamment), nous avons besoin de créer des messages de forum afin de
tester notre interface, et pour l’instant ces forums sont totalement vides.
Créons donc notre squelette des forums...
Commençons, comme d’habitude, par le fichier
d’appel : « forum_jeu.php3 » :
<? $fond = "forum_jeu"; $delais = 24 * 3600; include
("inc-public.php3"); ?> |
Créons maintenant le fichier
« forum_jeu.html ». Pour l’instant très simple :
<html> <title>[#NOM_SITE_SPIP] <BOUCLE_titre(RUBRIQUES){id_rubrique}>#TITRE</BOUCLE_titre></title> </head> <body> <a href="index.php3">#NOM_SITE_SPIP</a> <blockquote> <BOUCLE_principale(RUBRIQUES){id_rubrique}> <BOUCLE_hierarchie(HIERARCHIE){" : "}> <a href="#URL_RUBRIQUE">#TITRE</a> </BOUCLE_hierarchie> <h1>FORUM: <a
href="#URL_RUBRIQUE">#TITRE</a></h1> </BOUCLE_principale> </blockquote> </body> </html> |
Ce premier squelette très simple affiche :
le
retour à la page d’accueil du site ;
la
hiérarchie menant à ce jeu ;
le
titre du jeu.
Grâce à la BOUCLE_principale, nous sommes bien dans
la rubrique qui concerne ce jeu.
Pour l’instant, notre forum est totalement vide.
Avant de créer l’affichage prévu (afficher uniquement la liste des messages),
créons une interface permettant de créer un forum complet. Grâce à lui, nous
pourrons « alimenter » notre forum, et ainsi créer l’interface
ensuite.
Insérons le lien qui nous permettra de poster notre
premier message :
<h3>[<a href="forum.php3?(#PARAMETRES_FORUM)">Poster un
message</a>]</h3> |
Automatiquement, #PARAMETRES_FORUM indiquera
qu’il s’agit de messages liés à une rubrique, puisque notre BOUCLE_principale
est bien de type (RUBRIQUES).
Affichons le titre de ces premiers messages :
<B_thread>
<ul>
<BOUCLE_thread(FORUMS){id_rubrique}{par date}{inverse}> <li>#TITRE
</BOUCLE_thread>
</ul>
</B_thread> |
Ajoutons la possibilité de répondre à ces
messages :
<B_thread>
<ul>
<BOUCLE_thread(FORUMS){id_rubrique}{par date}{inverse}> <p><li>#TITRE <p
align="right"><a href="forum.php3?#PARAMETRES_FORUM">répondre à ce message</a> </BOUCLE_thread>
</ul> </B_thread> |
De cette façon, nous pouvons répondre aux messages
de « premier » niveau (ce qu’on nomme les « threads »,
c’est-à-dire les messages qui lancent une nouvelle discussion), mais nous ne
les affichons pas.
Affichons les réponses :
<B_thread>
<ul>
<BOUCLE_thread(FORUMS){id_rubrique}{par date}{inverse}> <p><li>#TITRE <p
align="right"><a href="forum.php3?#PARAMETRES_FORUM">répondre à ce message</a> <B_reponses> <ul> <BOUCLE_reponses(FORUMS){id_parent}{par date}> <p><li>#TITRE <a
href="forum.php3?#PARAMETRES_FORUM">répondre à ce message</a> </BOUCLE_reponses> </ul> </B_reponses>
</BOUCLE_thread>
</ul>
</B_thread> |
Nous affichons désormais les réponses aux threads,
il est possible de répondre à ces réponses, mais sans affichage. Pour afficher
ces réponses, nous allons désormais ajouter une boucle récursive,
c’est-à-dire que la BOUCLE_reponses va s’appeler elle-même, ce qui nous
permettra d’afficher d’un seul coup l’intégralité des messages.
Modifions la BOUCLE_reponses ainsi :
<B_reponses>
<ul>
<BOUCLE_reponses(FORUMS){id_parent}{par date}> <p><li>#TITRE <a href="forum.php3?#PARAMETRES_FORUM">répondre à ce message</a>
<BOUCLE_rep_messages(boucle_reponses)></BOUCLE_rep_messages>
</BOUCLE_reponses>
</ul>
</B_reponses> |
Nous avons ajouté à l’intérieur de la
BOUCLE_reponses une BOUCLE_rep_messages, qui appelle la BOUCLE_reponses. Ce qui
permet d’afficher les réponses aux messages de la BOUCLE_reponses, de manière
récursive (on exécute cette boucle jusqu’à ce qu’il n’y ait plus aucune
réponse).
Arrivé à ce stade, pour les besoins de notre
développement, il faut faire une pause, et consacrer un peu de temps à créer de
nombreux messages dans un forum, avec plusieurs fils de discussion (threads),
des réponses à des réponses... de façon à simuler un forum complet. Cela nous
permettra de créer plus logiquement notre interface graphique.
Après cette étape, pendant laquelle nous avons
alimenté notre forum avec une tripotée de messages, nous allons recommencer
notre mise en page, cette fois dans l’optique de ce que nous avions prévu au
départ : la page « forum_jeu » n’affichera que les titres des
messages, et une autre page affichera chaque message.
Comme nos boucles précédentes n’affichaient pas d’informations, les
modifications sont peu importantes :
il
faut afficher le #TITRE en lien
hypertexte vers la page de ce message (nous décidons que nous utiliserons une
page intitulée « message.php3 » pour cela) ;
il
faut afficher le #NOM de l’auteur
du message, et la #DATE d’envoi du
message ;
il
faut supprimer la mention « répondre à ce message ».
Nous en profitons pour modifier la présentation
graphique. Les <ul> et <li>
suffisent pour présenter la structure logique, mais graphiquement ça n’est pas
très joli. Nous les remplaçons donc par quelques feuilles de style très
simples.
Finalement, notre code devient :
<BOUCLE_thread(FORUMS){id_rubrique}{par date}{inverse}> <p>
<div style="border: solid black 1px; background-color: #CCCCCC; padding: 3px;
width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div>
<B_reponses> <div style="margin-left: 15px"> <BOUCLE_reponses(FORUMS){id_parent}{par date}>
<div style="border-left: solid black 1px;
border-bottom: solid black 1px; border-right: solid black 1px; padding: 3px;
width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div> <BOUCLE_rep_messages(boucle_reponses)></BOUCLE_rep_messages> </BOUCLE_reponses>
</div> </B_reponses> </BOUCLE_thread> |
Remarque sur les styles. Nous avons inséré ici les styles directement dans
la déclaration des <div>. On pourra préférer les regrouper dans des feuilles de style en début
de fichier. Cependant, pendant le développement de la page, il est toujours
pratique de pouvoir les modifier directement à l’endroit où se trouve
l’information. Par ailleurs, l’usage des styles pose des difficultés de
compatibilité avec Netscape 4.7 : non seulement celui-ci n’utilise
pas l’intégralité des styles, mais en plus certains styles provoquent des bugs
d’affichage. Dans l’exemple ci-dessus, nous avons choisi des styles qui ne
provoquent pas ces bugs.
Notre page d’affichage de tous les messages d’un
forum est terminée. Dans le cadre d’un véritable site, on gagnerait à afficher
de plus les liens vers les articles de cette rubrique (les tests, les previews,
un rappel des dates de sortie) ; comme cela a déjà été réalisé par
ailleurs, nous laissons ce soin au lecteur.
Il nous faut désormais afficher le texte de chaque
message, avec la possibilité d’y répondre. Comme nous avons créé les liens sur
la page précédente, nous savons que cela se fera avec un couple de
fichiers : « message.php3 » et « message.html »,
appelés par un « id_forum » (id_forum étant le numéro de chaque message
du forum).
Le fichier « message.php3 » :
<? $fond =
"message"; $delais = 24 *
3600; include ("inc-public.php3"); ?> |
Le fichier « message.html » contient le
squelette :
<html> <title>[#NOM_SITE_SPIP] <BOUCLE_titre(FORUMS){id_forum}>#TITRE</BOUCLE_titre></title> </head> <body> <a
href="index.php3">#NOM_SITE_SPIP</a> <blockquote> <BOUCLE_principale(FORUMS){id_forum}> <h3>#TITRE</h3> [(#DATE|affdate)][, par <A
HREF="mailto:#EMAIL">(#NOM)</A>] [<BR><A HREF="#URL_SITE">(#NOM_SITE)</A>] <p>#TEXTE
</BOUCLE_principale> </blockquote> </body> |
Cette première version affiche :
le
titre de la page (dans <title>...</title>) ;
le
lien vers la page d’accueil du site ;
le
titre, le texte, la date, l’auteur et un site Web de ce message.
Du côté de la navigation dans le site, tout reste à
faire... Nous allons afficher la mention du jeu concerné par ce message. Dans
la BOUCLE_principale, juste avant le #TITRE du message,
ajoutons l’indication du titre du jeu (avec un lien vers la rubrique du jeu) et
un lien vers la page affichant tous les messages :
<BOUCLE_larubrique(RUBRIQUES){id_rubrique}> <h3>forum du jeu:
<a href="#URL_RUBRIQUE">#TITRE</a></h3> afficher <a href="forum_jeu.php3?id_rubrique=#ID_RUBRIQUE">tous les messages</a> </BOUCLE_larubrique> |
Nous recopions notre traditionnelle
BOUCLE_hierarchie permettant d’indiquer la hiérarchie des styles de jeux :
<BOUCLE_larubrique(RUBRIQUES){id_rubrique}>
<BOUCLE_hierarchie(HIERARCHIE){" : "}> <a
href="#URL_RUBRIQUE">#TITRE</a> </BOUCLE_hierarchie> <h3>forum du jeu:
<a href="#URL_RUBRIQUE">#TITRE</a></h3> afficher <a
href="forum_jeu.php3?id_rubrique=#ID_RUBRIQUE">tous les messages</a> </BOUCLE_larubrique> |
Nous désirons maintenant afficher la hiérarchie des
messages qui mènent à notre message (s’il s’agit d’une réponse à un autre
message, nous voulons afficher le lien vers ce message « parent »).
Nous insérons (après le lien « afficher tous les messages », et avant
le #TITRE du message
actuel) :
<BOUCLE_parents(FORUMS){id_enfant}> <br><a
href="message.php3?id_forum=#ID_FORUM">#TITRE</a>
[| (#NOM)] | [(#DATE|affdate)] </BOUCLE_parents> |
Note : le critère {id_enfant} appliqué aux boucles (FORUMS) a été introduit dans la version 1.3 de SPIP. Ce critère permet d’appeler le message
auquel le message actuel répond. (Un critère similaire existe pour les boucles
(RUBRIQUES), nous l’utilisons d’ailleurs dans
« article.html » pour « remonter d’un cran » dans la
hiérarchie des rubriques. Curieusement, nous avions oublié ce critère dans les
boucles des forums...)
Nous affichons ici le message auquel le message de
la BOUCLE_principale répond. Cela ne nous suffit pas, nous voulons afficher
toute la succession des messages jusqu’à notre message principal (si le message
affiché grâce à la BOUCLE_parents est lui-même une réponse, nous voulons encore
remonter d’un cran, et ainsi de suite jusqu’au premier message du thread).
Pour cela nous utilisons tout simplement une boucle
récursive, comme nous l’avons fait avec la BOUCLE_reponses de
« forum_jeu.html ». Nous inversons cependant la logique, puisqu’au
lieu de « descendre » la hiérarchie des messages, nous la
« remontons ». Pour que la présentation soit cohérente, nous plaçons
l’appel de la boucle récursive avant l’affichage du #TITRE du message
(les message « parents » doivent s’afficher avant le titre de leur
réponse) :
<BOUCLE_parents(FORUMS){id_enfant}>
<BOUCLE_par_parents(boucle_parents)></BOUCLE_par_parents> <br><a
href="message.php3?id_forum=#ID_FORUM">#TITRE</a>
[| (#NOM)] | [(#DATE|affdate)] </BOUCLE_parents> |
Cette boucle suffit à afficher la navigation et la
structure logique dans les messages. Cependant, graphiquement cela ne nous
convient pas. En effet, pour bien marquer le fait qu’il s’agit d’un
enchaînement de réponses successives, nous voulons rétablir le petit décalage
vers la droite à chaque réponse (comme sur la page
« forum_jeu.html »).
Nous allons donc utiliser un style provoquant, à
chaque appel de la boucle récursive, un décalage vers la gauche (de 15 points,
puisque c’est le décalage utilisé dans la page « forum_jeu.html »).
Nous en profitons pour afficher la #TITRE du message
dans la même style que sur cette page (liseret à gauche et en dessous) :
<B_parents> <div
style="margin-left:-15px"> <BOUCLE_parents(FORUMS){id_enfant}> <BOUCLE_par_parents(boucle_parents)></BOUCLE_par_parents> <div style="border-left: solid black 1px;
border-bottom: solid black 1px; border-right: solid black 1px; padding: 3px;
width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div>
</BOUCLE_parents> </div> </B_parents> |
L’affichage devient plus cohérent, avec le décalage
vers la gauche et les liserets, mais cela n’est pas encore parfait : ce
décalage rentre dans la marge gauche de la page, puisque l’on décale vers la
gauche, sans avoir auparavant décalé l’ensemble de la page vers la droite (si
l’on considère une valeur de marge, on peut ainsi considérer que la marge
gauche devient « négative » : au départ une marge égale à 0,
puis -15, puis -30...).
Nous allons donc devoir décaler l’ensemble vers la
droite. Nous ne pouvons pas le faire à l’intérieur de la BOUCLE_parents,
puisque nous décalerions, à chaque récursivité, une fois vers la gauche, et
immédiatement une fois vers la droite ; les décalages d’annuleraient à
chaque fois.
Nous allons donc créer une nouvelle boucle, avant
la boucle d’affichage des parents, dont le seul but sera d’afficher des <div> destinés à provoquer l’affichage vers la droite.
L’ensemble de la page sera décalé vers la droite
(s’il y a trois messages avant d’arriver au message principal, tout sera décalé
de 45 points vers la droite). Les messages parents partiront donc de cette
valeur pour se décaler vers la gauche : le premier message parent sera
décalé vers la gauche, avec donc une marge global de 30 points vers la droite
(45 - 15), le second sera à 15 points, puis 0 points.
Notre code devient :
<BOUCLE_decaler_droite(FORUMS){id_enfant}> <div style="margin-left: 15px"> <BOUCLE_rec_decaler_droite(boucle_decaler_droite)></BOUCLE_rec_decaler_droite> </BOUCLE_decaler_droite>
<B_parents> <div style="margin-left:-15px">
<BOUCLE_parents(FORUMS){id_enfant}> <BOUCLE_par_parents(boucle_parents)></BOUCLE_par_parents> <div style="border-left: solid black 1px;
border-bottom: solid black 1px; border-right: solid black 1px; padding: 3px;
background-color: #CCCCCC; width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div> </BOUCLE_parents>
</div> </B_parents> |
La BOUCLE_decaler_droite est encore une boucle
récursive, similaire à celle destinée à afficher les messages parents. La
différence est ici dans le contenu : à chaque message parent, au lieu
d’afficher le titre du message, on affiche uniquement un <div> provoquant le décalage vers la droite.
Puisque nous avons provoqué un décalage vers la
droite, il faut ensuite réaliser l’opération inverse en fermant
tous ces <div...>.
Cela se fait par la même boucle, contenant cette fois les balises </div>. Mais où placer cette boucle ? Il nous semble
logique d’afficher le texte du message principal avec un décalage vers la
droite : il apparaîtra ainsi très clairement comme une réponse au dernier
message affiché par la BOUCLE_parents.
C’est donc juste après la #TEXTE du message
principal que nous plaçons le code suivant :
<BOUCLE_decaler_gauche(FORUMS){id_enfant}> </div>
<BOUCLE_rec_decaler_gauche(boucle_decaler_gauche)></BOUCLE_rec_decaler_gauche> </BOUCLE_decaler_gauche> |
Nous voulons maintenant afficher les réponses au
message principal. De cette façon, nous pourrons nous seulement
« remonter » la hiérarchie (avec la BOUCLE_parents), mais aussi la
« descendre ».
Pour cela, il nous suffit de recopier la
BOUCLE_reponses récursive de la page « forum_jeu.html ». Nous
insérons ce code juste après le #TEXTE du message
principal, et avant le décalage vers la gauche (il est logique que ces réponses
soient décalées à droite du message principal) :
<B_reponses> <div style="margin-left: 15px"> <BOUCLE_reponses(FORUMS){id_parent}{par date}>
<div style="border-left: solid black 1px;
border-bottom: solid black 1px; border-right: solid black 1px; padding: 3px;
width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div> <BOUCLE_rep_messages(boucle_reponses)></BOUCLE_rep_messages> </BOUCLE_reponses>
</div> </B_reponses> |
Enfin il nous reste à afficher les réponses situées
au « même niveau » hiérachique que le message principal
(c’est-à-dire : si notre message principal est une réponse à un message,
nous voulons afficher les liens vers les autres réponses à ce message).
Affichons toutes les autres réponses, en insérant
ce code juste avant le #TITRE de notre
message principal :
<BOUCLE_niveau(FORUMS){meme_parent}{par date}{exclus}> <div
style="border-left: solid black 1px; border-bottom:
solid black 1px; border-right: solid black 1px; padding: 3px;
width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div> </BOUCLE_niveau> |
Avec le décalage que nous avons créé précédemment,
tout cela est du plus bel effet...
Améliorons encore notre présentation : nous
allons afficher au dessus de notre message principal uniquement les messages
postés avant ce message. Pour cela, nous ajoutons un critère à notre
BOUCLE_niveau :
<BOUCLE_niveau(FORUMS){meme_parent}{par date}{age_relatif>0}{exclus}> |
Le critère {age_relatif} (apparu dans SPIP 1.3)
est similaire au critère habituel {age}. Mais, là où {age} compare la date de l’élément (article, message de
forum, etc.) à la date actuelle (aujourd’hui), {age_relatif} compare cette date à la date de l’élément
courant : dans notre cas, puisque nous sommes dans la BOUCLE_principale
qui affiche le message principal, nous sélectionnions les autres messages en
comparant leur date à la date du message principal. Avec {age_relatif>0}, nous récupérons donc uniquement les messages plus
anciens que le message principal.
Fort logiquement, nous créons une boucle avec le
critère d’age relatif
opposé, après les messages de BOUCLE_reponses.
<BOUCLE_niveau_apres(FORUMS){meme_parent}{par date}{age_relatif<=0}{exclus}> <div style="border-left:
solid black 1px; border-bottom: solid black 1px;
border-right: solid black 1px; padding: 3px; width:100%"> <a href="message.php3?id_forum=#ID_FORUM">#TITRE</a> [| (#NOM)] | [(#DATE|affdate)] </div>
</BOUCLE_niveau_apres> |
Il ne nous reste plus qu’à retravailler un peu la présentation
du message principal (nous le plaçons lui aussi à l’intérieur d’un liseret
noir), et à ajouter le lien « Répondre à ce message » :
<div style="border-left:
solid black 1px; border-bottom: solid black 1px; border-right: solid
black 1px; padding: 3px; width:100%"> <h2>#TITRE</h2> [(#DATE|affdate)][, par <A HREF="mailto:#EMAIL">(#NOM)</A>] [<BR><A HREF="#URL_SITE">(#NOM_SITE)</A>] <p>#TEXTE <p align="right"><b>[<a href="forum.php3?(#PARAMETRES_FORUM)">Répondre à ce message</a>]</b> </div> |
Nos deux squelettes permettant de gérer les forums
d’un jeu sont terminés. Tout cela peut paraître un peu compliqué, mais il faut
bien considérer que nous avons décidé de fignoler la présentation de la
structure. Nous aurions pu nous contenter d’une interface de navigation
beaucoup plus spartiate.
Reprenons le référencement de ce forum dans les
autres pages du site.
Dans la page « article.html », modifions
notre lien et ajoutons une boucle :
<p><b><a
href="forum_jeu.php3?id_rubrique=#ID_RUBRIQUE">Le forum de ce
jeu</a></b> <BOUCLE_forum(FORUMS){id_rubrique}{plat}> </BOUCLE_forum> (#TOTAL_BOUCLE messages)</B_forum> |
La BOUCLE_forum n’affiche rien, nous n’utiliserons
que le texte conditionnel après. Le critère {plat} de cette boucle de forum indique que nous voulons
récupérer tous les messages du forum (sans ce critère, nous ne
récupérerions que les threads ; ici nous récupérons même les
messages qui sont des réponses à d’autres messages). Cette boucle (qui
n’affiche rien) effectuée, nous pouvons afficher en texte optionnel le nombre
total de résultats, grâce à #TOTAL_BOUCLE, c’est-à-dire le nombre de messages dans le forum.
Dans « rubrique.html », cela devient un
peu plus compliqué. En effet, de la même manière que nous avions établit une
différence de présentation entre les rubriques de navigation (par grandes
catégories de jeux) et les rubriques de jeux (contenant des articles), nous ne
voulons afficher un lien vers un forum de discussion que s’il s’agit bien de la
rubrique d’un jeu. Pour cela, nous créons une boucle qui va tester la présence
d’au moins un article dans la rubrique, et notre lien vers le forum ne sera
affiché que si cette boucle (BOUCLE_test_jeu) contient au moins un élément. Ce
qui nous donne, inséré après la BOUCLE_sites et juste avant la fin de la
BOUCLE_les_articles :
<BOUCLE_test_jeu(ARTICLES){id_rubrique}{0,1}> </BOUCLE_test_jeu>
<p><b><a href="forum_jeu.php3?id_rubrique=#ID_RUBRIQUE">Le forum de ce jeu</a></b>
</B_test_jeu> |
Nous supprimons ici l’affichage du nombre de
messages : nous sommes ici à l’intérieur du texte optionnel de la
BOUCLE_test_jeu, et l’insertion d’une nouvelle boucle à cet endroit est
toujours déconseillée (notamment, la valeur #TOTAL_BOUCLE serait
celle de la boucle BOUCLE_test_jeu, et non plus le nombre de messages dans le
forum).
Evidemment, on pourra compléter ce processus en ajoutant
ces liens vers les forums sur d’autres pages. Par exemple le tableau des
annonces des sorties de jeux.
Il y aurait encore beaucoup à faire pour enrichir
la navigation sur notre site, uniquement en utilisant les boucles de SPIP. Mais
ce tutorial est déjà bien assez long... nous en resterons donc là.
L’intégralité des fichiers réalisés dans ce
tutorial sont disponibles sur le site
spip_contrib. Ces fichiers contiennent quelques petits éléments de mise en
page supplémentaires (des tableaux pour les sommaires), mais rien de
fondamentalement complexe.
Si vous voulez bidouiller à partir des exemples
fournis ici, n’hésitez pas, il reste de nombreuses possibilités de navigation
inexploitées dans notre site :
vous
pouvez créer des pages de sommaire par type d’article : toutes les
dernières previews, tous les derniers tests, toutes les soluces...
vous
pouvez vouloir créer des « événements », c’est-à-dire des articles
que vous voulez mettre particulièrement en valeur sur la page d’accueil (ces
articles n’étant finalement remplacés que par un « événement »
suivant). Pour cela, vous pouvez créer un nouveau mot-clé, et effectuer des
sélections supplémentaires (notamment sur les pages de sommaire) en fonction de
ce mot-clé ;
vous
pouvez créer de nouveaux types d’articles (par exemple les « produits
dérivés » tels que les figurines, les films adaptés des films...) ;
vous
pouvez créer de nouvelles grandes rubriques, destinées à recevoir un contenu
éditorial différent, tel que des analyses générales sur les évolutions des
machines (« faut-il encore acheter une Dreamcast ? », « la
Xbox est-elle une bonne machine ? »...), des comparatifs... là encore
l’utilisation des mots-clés permettra d’enrichir la structure éditoriale de
votre site ; ils suffira de créer des squelettes localisés à ces nouvelles
rubriques pour obtenir des interfaces adaptées à ces nouveaux besoins... il
sera de plus intéressant d’intégrer l’affichage de ces nouveaux types
d’articles dans votre sommaire, en exploitant ou non les mots-clés des machines
(par exemple, un article « faut-il acheter une Dreamcast ? »
serait affiché dans le sommaire spécifique de cette machine) ;
sur
la page d’un article, vous pouvez améliorer l’affichage des jeux de même genre
(les autres jeux de survival horror, les autres jeux de plateforme) : vous
pouvez limiter cet affichage qu’aux jeux ayant reçu une bonne note, ou sortis
depuis moins de six mois ;
vous
pouvez réaliser une navigation de rubrique en rubrique en n’affichant que ce qui
concerne une unique machine (attention, cela devient particulièrement complexe
à réaliser).
Comme vous pouvez le constater, il y a beaucoup à
faire avec les squelettes de SPIP. C’est même le point important à retenir de
ce tutorial : pour exploiter pleinement les possibilités de SPIP, il
faut réaliser ses propres squelettes. On peut dès lors considérer les
squelettes fournis en standard avec SPIP comme un pis-aller : afin que
chacun puisse commencer à exploiter immédiatement un site avec SPIP, nous fournissons
des squelettes ; mais l’intérêt de SPIP, justement, réside dans la
réalisation de ses propres squelettes, adaptés à la structure éditoriale dont
on a besoin.
#
#BIO...................................................... 176
#CHAPO........................... 168, 218, 223, 355
#CHARSET...................................... 70, 195
#COMPTEUR_BOUCLE.............. 162, 208
#DATE 69, 75, 84, 168, 172, 174, 179, 184, 202, 203, 204, 207, 211,
212, 213, 214, 223, 259, 355, 362, 364, 365, 366, 367, 370, 373, 375, 376, 379,
381, 382, 395, 405, 406, 407, 408, 409, 410, 411, 412, 413
#DATE_MODIF........................ 69, 168, 211
#DATE_NOUVEAUTES................. 75, 211
#DATE_REDAC............................ 168, 211
#DESCRIPTIF 168, 172, 180, 183, 188, 204, 206, 336,
337, 351, 387, 393
#EMAIL......... 70, 176, 179, 184, 195, 407, 413
#EMAIL_WEBMASTER.................. 70, 195
#EMBED_DOCUMENT 188, 324, 325, 326, 327, 328
#ENV....................................... 166, 190, 196
#EXPOSER............. 7, 79, 166, 214, 215, 216
#FORMULAIRE_ADMIN............... 70, 196
#FORMULAIRE_ECRIRE_AUTEUR 65, 70, 176, 198
#FORMULAIRE_FORUM 169, 173, 175, 179, 197
#FORMULAIRE_INSCRIPTION......... 198
#FORMULAIRE_RECHERCHE 65, 197, 200
#FORMULAIRE_SIGNATURE.... 169, 198
#FORMULAIRE_SITE.................. 173, 198
#HAUTEUR................................... 188, 206
#ID_ARTICLE............ 94, 168, 179, 184, 336
#ID_AUTEUR................................ 176, 332
#ID_BREVE................................... 174, 179
#ID_DOCUMENT................................ 188
#ID_FORUM 178, 406, 408, 409, 410, 411, 412
#ID_GROUPE................................. 70, 181
#ID_MOT......................... 180, 390, 391, 397
#ID_RUBRIQUE 168, 172, 175, 179, 183, 366, 367, 385,
389, 394, 402, 408, 414
#ID_SECTEUR....................... 168, 172, 183
#ID_SIGNATURE................................ 184
#ID_SYNDIC................................. 179,
183
#ID_THREAD.................................. 93,
178
#INTRODUCTION....... 65, 85, 169, 172, 175
#IP........................ 29, 137, 141, 179, 232, 305
#LANG......... 172, 175, 176, 195, 259, 260, 262
#LANG_DIR..................... 195, 259, 260, 262
#LANG_LEFT......................... 195, 260, 262
#LANG_RIGHT...................... 195, 260, 262
#LARGEUR................................... 188, 206
#LESAUTEURS..................... 169, 218, 355
#LOGIN_PRIVE................................... 198
#LOGIN_PUBLIC.................... 70, 199, 200
#LOGO_ARTICLE 65, 89, 164, 170, 206, 321, 324, 325,
327, 332, 355, 387, 393
#LOGO_ARTICLE_NORMAL. 65, 170, 321
#LOGO_ARTICLE_RUBRIQUE 65, 170, 321, 355, 387, 393
#LOGO_ARTICLE_SURVOL. 65, 170, 321
#LOGO_AUTEUR........................... 76, 177
#LOGO_AUTEUR_NORMAL........ 76, 177
#LOGO_AUTEUR_SURVOL........ 76, 177
#LOGO_BREVE............................. 65, 175
#LOGO_BREVE_RUBRIQUE...... 65, 175
#LOGO_DOCUMENT......................... 188
#LOGO_MOT 181, 362, 364, 365, 367, 370, 373, 379, 381, 382, 387, 390,
391, 392, 397, 399, 400
#LOGO_RUBRIQUE 65, 170, 173, 205, 356, 358, 361, 368,
370
#LOGO_RUBRIQUE_NORMAL... 65, 173
#LOGO_RUBRIQUE_SURVOL... 65, 173
#LOGO_SITE.................. 183, 195, 399, 400
#LOGO_SITE_SPIP............................. 195
#MENU_LANG................................ 78, 261
#MENU_LANG_ECRIRE............... 78, 261
#MESSAGE.......................................... 184
#n
BALISE.............................................. 165
#NOM 86, 90, 169, 175, 176, 179, 183, 184, 195, 331, 336, 337,
355, 358, 370, 378, 381, 386, 392, 399, 400, 402, 405, 406, 407, 408, 409, 410,
411, 412, 413
#NOM_SITE 86, 169, 175, 176, 179, 183, 184, 195, 355, 358, 370, 378,
381, 386, 392, 399, 400, 402, 407, 413
#NOM_SITE_SPIP 195, 355, 358, 370, 378, 381, 386, 392,
402, 407
#NOTES 169, 172, 175, 177, 218, 251, 277, 355, 358, 363, 370, 372,
401
#PARAMETRES_FORUM 94, 169, 173, 175, 179, 403, 404, 413
#PETITION............................................ 169
#PGP........................................ 176, 286, 303
#POINTS.......................................... 76, 201
#POPULARITE............. 7, 169, 209, 210, 211
#POPULARITE %......................... 210, 211
#POPULARITE_ABSOLUE................. 210
#POPULARITE_MAX........................... 210
#POPULARITE_SITE........................... 210
#PS..................... 168, 314, 349, 355, 370, 372
#PUCE............................................. 69, 196
#RECHERCHE.......................... 7, 200, 201
#SELF.............................................. 94, 196
#SOUSTITRE.................. 168, 218, 355, 362
#SPIP_CRON........................................ 197
#SURTITRE......... 89, 163, 164, 168, 218, 355
#TAILLE................................................ 188
#TEXTE 76, 90, 165, 168, 172, 174, 179, 180, 204, 205, 206, 208,
215, 218, 220, 221, 223, 314, 355, 358, 370, 407, 411, 413
#TITRE 60, 70, 79, 90, 159, 162, 163, 164, 165, 168, 172, 174, 179,
180, 181, 188, 190, 192, 194, 203, 205, 206, 209, 211, 213, 214, 215, 216, 217,
218, 219, 220, 221, 259, 320, 324, 325, 328, 331, 332, 333, 334, 336, 355, 356,
357, 358, 359, 360, 361, 363, 364, 365, 366, 367, 368, 370, 372, 373, 375, 376,
378, 379, 381, 382, 383, 384, 385, 386, 387, 389, 392, 393, 394, 395, 397, 399,
400, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413
#TOTAL_BOUCLE 162, 205, 208, 334, 335, 414
#TYPE.......... 156, 157, 158, 181, 188, 208, 336
#TYPE_DOCUMENT........................... 188
#URL_ARTICLE 169, 170, 203, 206, 213, 214, 215, 216,
220, 222, 259, 260, 273, 331, 332, 334, 359, 361, 363, 364, 365, 367, 373, 379,
380, 383, 384, 385, 387, 393, 394
#URL_AUTEUR.............................. 79, 177
#URL_BREVE............................... 175, 273
#URL_DOCUMENT...................... 188, 264
#URL_FORUM.......................... 93, 94, 178
#URL_LOGOUT...................... 70, 199, 200
#URL_MOT........................................... 181
#URL_RUBRIQUE 172, 222, 273, 357, 358, 360, 361, 366,
368, 370, 381, 386, 389, 397, 402, 408
#URL_SITE 86, 169, 175, 176, 179, 183, 184, 195, 399, 400, 407, 413
#URL_SITE_SPIP................................ 195
#URL_SYNDIC.................................... 183
#VISITES.............................................. 169
A
a,b............................................ 185, 193, 194
a/b......................................................... 194
ad_email....................................... 184, 306
affdate 69, 202, 203, 204, 211, 223, 259, 355, 364, 365, 366, 367,
370, 373, 375, 376, 379, 381, 382, 395, 406, 407, 408, 409, 410, 411, 412, 413
affdate{'Y-m'}................................ 202, 203
age 59, 75, 191, 192, 212, 213, 214, 333, 366, 380, 381, 382,
392, 393, 394, 395, 397, 412
age_relatif............ 59, 75, 192, 212, 213, 412
aligner_droite.............................. 201, 223
aligner_gauche................................... 201
annee 75, 191, 202, 203, 204, 207, 211, 213, 214
attribut_html...................................... 206
autostart=true........................ 63, 128, 188
B
BOUCLE(ARTICLES) 59, 69, 77, 78, 89, 157, 159, 161, 162,
163, 164, 165, 166, 171, 185, 189, 190, 191, 192, 193, 194, 195, 198, 201, 203,
210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 259, 260, 261, 314,
319, 320, 324, 325, 331, 332, 333, 334, 336, 355, 356, 359, 360, 361, 362, 363,
364, 365, 366, 367, 368, 370, 373, 375, 376, 377, 379, 380, 381, 382, 383, 384,
385, 387, 389, 393, 394, 395, 397, 414
BOUCLE(AUTEURS) 6, 78, 157, 169, 175, 195, 196, 198,
261, 330, 331, 336
BOUCLE(BREVES) 6, 78, 157, 173, 195, 201, 212, 261
BOUCLE(DOCUMENTS) 7, 63, 84, 186, 187, 193, 324, 325, 326,
327, 328
BOUCLE(FORUMS) 6, 79, 177, 178, 197, 209, 334, 335,
403, 404, 406, 407, 408, 409, 410, 411, 412, 414
BOUCLE(HIERARCHIE) 6, 93, 184, 185, 356, 357, 358, 370,
402, 408
BOUCLE(MOTS) 6, 70, 174, 179, 181, 182, 336, 362,
364, 365, 367, 370, 372, 373, 375, 376, 378, 379, 381, 382, 384, 385, 386, 387,
390, 391, 392, 393, 395, 396, 397, 399, 400
BOUCLE(RUBRIQUES) 78, 79, 157, 161, 164, 165, 170, 171,
184, 185, 193, 195, 198, 201, 212, 220, 221, 261, 319, 331, 334, 356, 357, 358,
359, 360, 361, 366, 367, 368, 370, 379, 380, 381, 382, 386, 387, 389, 393, 394,
395, 397, 402, 403, 408
BOUCLE(SIGNATURES)......... 6, 183, 193
BOUCLE(SITES)................ 6, 181, 182, 193
BOUCLE(SYNDIC_ARTICLES) 70, 79, 181
C
centrer.......................................... 201, 292
couper{5}................................................ 79
D
debut_.......................... 65, 76, 193, 277, 280
doublons 54, 85, 186, 187, 193, 194, 214, 324, 325, 326, 331, 332,
362, 363, 366, 367, 368, 399, 400
E
entites_html....................................... 206
exclus.. 168, 172, 192, 260, 392, 397, 411, 412
extension 34, 35, 71, 75, 122, 167, 171, 187, 206, 237, 238, 242, 281,
282, 285, 288, 289, 290, 309, 329
extension==jpg|png|gif.................... 187
H
heures 29, 30, 34, 135, 151, 202, 211, 228, 339
I
id_article 80, 92, 93, 94, 149, 150, 161, 167, 176,
177, 178, 180, 183, 185, 186, 187, 190, 192, 193, 195, 196, 209, 210, 213, 214,
215, 217, 218, 219, 221, 222, 271, 272, 302, 305, 306, 307, 324, 325, 326, 327,
328, 335, 336, 355, 356, 362, 364, 365, 367, 370, 372, 373, 375, 376, 379, 380,
381, 382, 384, 385, 387, 393, 394, 395, 397
id_auteur 79, 157, 167, 176, 177, 303, 305, 307, 330, 331, 332
id_breve...... 174, 177, 180, 186, 222, 303, 305
id_enfant.... 171, 178, 357, 408, 409, 410, 411
id_forum 177, 178, 180, 305, 406, 407, 408, 409, 410, 411, 412
id_groupe... 167, 171, 174, 178, 180, 181, 182
id_mot 167, 171, 174, 178, 180, 182, 304, 376, 377, 379, 380, 384,
385, 390, 391, 392, 393, 394, 395, 397
id_parent 171, 177, 178, 209, 301, 305, 359, 360, 361, 368, 386, 389,
404, 406, 411
id_rubrique 58, 59, 64, 77, 159, 160, 161, 162, 163,
164, 165, 167, 171, 174, 177, 180, 182, 185, 186, 189, 192, 194, 211, 215, 216,
220, 222, 254, 255, 301, 302, 303, 304, 305, 319, 320, 327, 328, 331, 332, 333,
336, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 370, 373,
375, 376, 377, 379, 381, 382, 383, 384, 385, 387, 389, 393, 394, 395, 397, 399,
400, 402, 403, 404, 406, 408, 414
id_secteur 167, 171, 178, 182, 186, 190, 191, 192,
301, 302, 304, 334
id_signature................................. 183,
306
id_syndic...... 70, 177, 180, 182, 304, 399, 400
id_syndic_article.......................... 70, 304
INCLURE 9, 64, 74, 75, 79, 89, 159, 164, 185, 254, 255, 279
inverse 77, 78, 93, 118, 144, 157, 167, 182, 189, 203, 211, 213, 214,
220, 259, 261, 270, 275, 320, 324, 325, 331, 334, 338, 339, 344, 361, 366, 367,
370, 372, 373, 378, 379, 380, 387, 389, 393, 394, 395, 396, 397, 403, 404, 406,
410
J
jour 2, 3, 15, 24, 25, 30, 31, 35, 44, 45, 46, 47, 48, 56, 57, 59,
61, 65, 66, 67, 68, 71, 72, 74, 75, 80, 81, 82, 84, 85, 86, 94, 95, 98, 136,
141, 142, 144, 145, 151, 165, 202, 207, 209, 210, 211, 212, 213, 214, 222, 233,
236, 238, 240, 242, 255, 256, 263, 275, 284, 300, 301, 308, 339, 346, 352, 366,
367, 374
justifier 165, 201, 220, 221, 223, 355, 358, 370
L
liens_ouvrants.................................... 204
M
majuscules 157, 165, 189, 201, 214, 223, 274, 331
math................................................ 92, 291
meme_parent... 171, 172, 178, 366, 411, 412
minutes.... 44, 71, 86, 202, 210, 211, 221, 373
mode 61, 62, 68, 69, 90, 93, 94, 96, 106, 118, 139, 140, 144, 147,
186, 187, 196, 199, 215, 257, 273, 293, 303, 325, 326
moderation.......................................... 182
mois 25, 26, 29, 30, 31, 32, 33, 34, 35, 57, 60, 75, 89, 104, 138,
191, 192, 202, 203, 204, 211, 213, 214, 346, 367, 380, 392, 395, 396, 397, 415
N
nom_email.................................... 184, 306
nom_jour....................................... 202, 211
nom_mois................. 202, 203, 211, 213, 214
P
par hasard... 93, 185, 189, 221, 327, 328, 331
par num..................... 60, 189, 190, 204, 320
par points................... 78, 201, 261, 275,
334
plat................................... 178, 316, 335, 414
PtoBR.................................................... 204
Q
quality=high................................... 63,
128
R
recherche 3, 5, 7, 9, 10, 11, 17, 18, 22, 23, 27, 30, 55, 64, 73, 74,
76, 78, 79, 85, 93, 106, 110, 112, 130, 143, 144, 168, 171, 174, 197, 200, 201,
209, 222, 224, 229, 241, 253, 261, 273, 275, 276, 294, 307, 315, 334, 336
reduire_image{130}........................... 206
S
saison..................................... 202, 211, 223
secondes...... 34, 151, 202, 211, 221, 247, 275
sinon{............................................... 76, 205
supprimer_numero................ 60, 204, 320
supprimer_tags..................... 204, 206, 337
syndication 18, 29, 33, 51, 54, 55, 56, 57, 64, 73,
74, 84, 94, 131, 132, 133, 137, 151, 182, 183, 197, 209, 234, 236, 255, 298
T
taille_en_octets........................... 188, 204
texte_script.................................. 205,
206
textebrut.............................................. 204
titre_mot 59, 167, 171, 174, 178, 182, 363, 364, 365, 366, 367, 370,
373, 375, 376, 377, 379, 381, 382, 383, 384, 385, 387, 389, 393, 394, 395, 396,
397, 400
type_mot 59, 167, 171, 174, 178, 182, 363, 395, 397
U
unique{ici}............................................ 204
[1] Note de bas de page
2 En plaçant le texte de la note entre crochets.
23 En indiquant le numéro de la note entre les symboles « < » et « > ».
* En
plaçant simplement une astérisque entre les symboles « < » et
« > ». En n’indiquant rien entre les symboles « < »
et « > ».
Rab François Rabelais.
1 Si article.html n’existe pas, le fichier « dist » est pris à la place. Lire à ce propos « Qu’est-ce que les fichiers « dist » ? ».
[2] Précision : n’oubliez pas le cas échéant, l’underscore “_” initial dans le nom de la boucle.
[3] #ENV et #EXPOSER
[4] Si on utilise un critère avec un nom ({doublons unnom}), celui ci n’exclura pas les documents intégrés dans le texte de l’article.
[5] le premier résultat est numéroté 0, donc le 200e résultat représente réellement la 201 e signature
[6] le format MySQL.
[7] Non ? Il devrait...
[8] Pour les spécialistes, il s’agit en fait d’un include PHP du fichier correspondant, permettant d’exécuter du code depuis le cache...
[9] On peut appeler ça un « pipeline »...
Notons que certains filtres de présentation peuvent être avantageusement remplacés par des feuilles de style. Ainsi |majuscules est équivalent à l’attribut CSS « text-transform: uppercase », et |justifier à « text-align: justify ».
[10] Voir à ce propos l’article « Les versions occitanes de SPIP : pourquoi autant de « òc » ? »
[11] De nombreux hébergeurs de sites proposent de gérer de telles listes en même temps qu’ils hébergent votre site, et de nombreux services - marchands ou non - proposent des systèmes de listes de diffusion.
[12] Les mots de passe sont chiffrés par SPIP, mais gardez bien à l’esprit qu’aucune protection n’est inviolable.
[13] Rappelons que la variable $delais définit la périodicité de mise à jour du
cache. Voir la section « Le fichier .php3 » dans « Principe général ».
[14] On précise ici que dans la
configuration livrée d’origine, SPIP reste monolingue, afin de ne pas
compliquer du tout l’interface.
[15] Si l’on veut au contraire un
affichage vide, il faut créer explicitement une première partie vide avec un
nom de langue quelconque.
[16] Théoriquement le HTML devrait
régler tous ces détails automatiquement, mais le résultat n’est pas toujours à
la hauteur, surtout lors des passages à la ligne ou si l’on mélange des langues
utilisant un sens d’écriture différent.
[17] Malheureusement, les instances
de normalisation semblent pour l’instant ignorer le boustrophédon, ce
qui empêche son utilisation en HTML.
[18] Tous, ou presque tous, nous vous laissons découvrir si votre mise en page présente des cas particuliers...
[19] Remarque : les versions
précédentes de SPIP incluaient le fichier inc-urls.php3
à la racine du site s’il était présent ; cette méthode est encore valable
mais est considérée comme obsolète...
[20] Si, donc, vous avez mis tous les $delais à zéro, ou si votre site n’est pas visité (site de test), l’indexation n’aura pas lieu.
[21] Ce fichier titre son nom de l’article W3C go home!, publié sur sur uZine, qui critiquait l’acharnement des prophètes de la compliance à emm... les webmestres qui se contentent de faire des pages Web ; l’essentiel, rappelons-le, est de publier sans se casser la tête. Si en plus on peut le faire de manière conforme, tant mieux, et c’est l’objet de cette passerelle SPIP-Tidy.
[22] Cascading Style Sheets : littéralement, « feuilles de style en cascade »
[23] Que les amateurs de liens
ouvrants ne se réjouissent pas trop vite : il est impossible, dans une
feuille de style, de spécifier qu’un lien doit s’ouvrir une nouvelle fenêtre...
Raté !
[24] Et même les boutons d’administration qui s’affichent en bas des pages lorsque vous êtes connecté.
[25] Notons cependant que certains
navigateurs imposent leurs propres boutons stylisés et ne vous laisseront pas
en changer l’aspect.