Des choses à faire dans SPIP

Avoir un espace pour poser toutes nos idées

Quand on a des idées de choses qui ne correspondent pas à un projet déjà existant (auquel cas on fait des tickets dans celui-ci).

?	Titre	#
	Créer un dépôt "idees" ou "wishlist" sur notre forge, pour l’instant dans Galaxie	#1
	Réfléchir à quelques étiquettes utiles pour classer les idées	#2

Habillage des contenus

Ce plugin pourrait être un nouveau plugin ou une refonte du plugin Fonds d’Arno*.

?	Titre	#
	Configurer une couleur de fond ou un dégradé	#1
	Configurer deux images possibles avant et après l’article	#2
	Configurer quel recadrage en petit écran ?	#3
	Pour chaque image on peut configurer le pourcentage de chevauchement avec l’article	#4
	Pour chaque image, on peut configurer le type de transition et ses détails	#5
	Classiquement permettre au moins un dégradé dont on peut configurer la taille et vers quelle couleur (souvent du transparent vers la couleur du milieu de l’article)	#6
	Ajouter d’autres transitions possible, comme des masques plus bruts : exemple ici dans le bandeau avec un clip-path polygon : https://laviedesidees.fr/Michael-Sandel-La-tyrannie-du-merite.html	#7
	Permettre un mode libre où on colle les attributs CSS qu’on veut ?	#8

Aide en ligne

https://seenthis.net/messages/304770#message309921

?	Titre	#
	Faire un sous-plugin du Compagnon avec une interface pour ajouter des aides dans les zones connus du site (par objets, en haut, en bas, sur le côté, etc)	#1
	Permettre d’exporter et importer ces aides	#2
	Réfléchir à faire encore mieux en permettant de personnaliser les labels et explications de champs précis de tous les formulaires (mais tant que c’est pas fait en Saisies je vois pas comment)	#3

Framework CSS de maquettage

http://wireframes.ldd.fr/examples/

?	Titre	#
	Avoir une grille complexe applicable en classes CSS en dur dans le HTML	#1
	Faire des blocs matérialisés par une ligne autour, avec un label optionnel (qui se place au milieu s’il n’y a que le label)	#2
	Faire des blocs avec une croix à l’intérieur, et un texte au milieu	#3
	Avoir une palette de couleurs harmonieuse avec des classes qui permettent de colorier le fond d’un bloc (genre color—blue ou color—1)	#4
	Avoir une police blocs, que l’on active avec une classe sur un bloc	#5
	Mise à part la grille, préfixer les classes de ce framework (genre wf-box, wf-color…)	#6
	Pouvoir rendre des blocs optionnels avec une croix pour les enlever, en ajoutant une classe dédiée (wf-optional). Et un bouton général pour ré-afficher les choses qu’on a masqué.	#7

Refonte fonctionnelle de Contrib

?	Titre	#
	Transformer Contrib qui est essentiellement une "liste de documentation de plugins" en une liste de "projets". Un projet peut être fini ou pas, en cours de conception, en amélioration, bref : en vie. Cela laisserait la porte ouverte pour rendre visible de multiples projets, pas juste du code. Projet d’ergonomie, projet pour refondre un site, projet qui aura du code mais qui pour l’instant est en conception avec nomenclature, croquis, etc. Tout cela pourra rentrer dans Contrib, pour que plus de monde contribue et montre son travail (pas juste les devs et rédacteurices de documentation).	#1

Installer un plugin en TROIS clics

?	Titre	#
	Permettre d’installer un plugin (fonctionnel, squelette ou thème), depuis plugins.spip ou autre site du même genre (site de thèmes par ex)	#1
	Sur le site, avoir un lien "Installer sur mon site"	#2
	Si c’est la première fois, ouvre une boite pour demander l’URL de mon site et l’enregistre dans un cookie	#3
	Si ce n’est pas la première fois, on connait le site, mais il pourrait y avoir une boite quand même pour afficher le site déjà en mémoire et demander si on veut le changer	#4
	Ensuite quand on valide, ça redirige vers une URL d’admin du site en question, avec en paramètre l’URL du ZIP du plugin (et/ou son préfixe je ne sais pas techniquement, si on veut l’installer par SVN ou Git par exemple)	#5
	J’arrive donc sur mon site à moi (et si je suis pas logué ça me le demande évidemment), et j’ai UN clic à faire sur mon site pour valider que je veux bien l’installer et ça s’installe direct	#6

spip-cli

?	Titre	#
	Configurer les choses du début (dossiers, htaccess, base de donnée)	#1
	Ajouter une commande qui fait d’un coup télécharger + configuration	#2
	Commandes basique des plugins (dans le core : activer, désactiver, désinstaller, télécharger)	#3
	Commandes complexes des plugins (dans SVP : ajouter un dépôt, installer avec dépendances automatiques en SVN)	#4
	Imaginer un fichier YAML de description d’une distribution (version de SPIP + quels plugins-dist + quels plugins)	#5
	Ajouter une commande qui installe SPIP + tout ce que décrit ce YAML, tout en SVN	#6

Bases de démarrage

?	Titre	#
	Lister des bases de démarrage composées d’une sauvegarde SQLite et d’une description YAML	#1
	Au premier démarrage, sur l’accueil, ajouter un formulaire demandant si on veut installer l’une des bases de démarrage détectée (ou aucune)	#2
	Il faudrait par contre que ça garde l’utilisateur qui a fait l’installation !	#3
	Dans la page de configuration du plugin, toujours permettre après coup de revenir à une autre base de démarrage (attention ça écrase tout)	#4

Guide de style

http://zone.spip.org/trac/spip-zone/browser/_plugins_/styleguide/trunk

?	Titre	#
	Dans une page, intégrer le HTML de test typographique de Tinytypo	#1
	Dans une autre page, faire un système modulaire qui va piocher dans un dossier pour lister des composants HTML, en les affichant comme le guide de Code For America	#2

IntéGraal - le sacre des intégrateurices

?	Titre	#
	Un dossier de projet déjà rangé suivant l’organisation décrite sur Contrib avec trois dossiers, core/squelettes/theme	#1
	Une structure Z	#2
	Un body.html par défaut bien complet, avec des wrappers autour des grandes zones (pour permettre des fonds différents sur toute la largeur par ex) et compatible rapidement avec layoutgala	#3
	Des pages par défaut le plus possible : sommaire, rubrique, article, auteur, plan, organisation, contact, gis, etc	#4
	Utilisation au maximum de plugins génériques pour ne pas faire des bidouilles : menus, formidable, compositions, gis, C&O, sélection éditoriale	#5
	Des compositions pour des cas connus qu’on utilise souvent : galeries, annuaire (avec des Organisations), rubrique "tout en une page", FAQ, etc	#6
	Librairie d’inclusion de squelettes, et de listes pour les composants courant, avec pour chaque composant possiblement plusieurs versions : plusieurs galeries, plusieurs menus, plusieurs listes d’objets (articles, docs joints, événements, etc)	#7
	Chaque morceau HTML doit être le plus sémantique possible, avec des microdata quand il y en a, et surtout SANS lien avec un framework précis : c’est en pré-processeur (Less ou Sass) que l’on appliquera des styles sur ce HTML	#8

Sélection éditoriale

?	Titre	#
	Pouvoir créer autant de sélection que l’on veut, avec chacune un identifiant textuel permettant de l’appeler génériquement dans un squelette (sans lien avec un id SQL quoi) : appeler la sélection "a_la_une" par exemple	#1
	Chaque sélection est une liste contenant des choix éditoriaux, le nombre de choix pouvant possiblement être bloqué dans la config d’une sélection (par exemple "a_la_une" n’aurait que 5 choix maximum)	#2
	Chaque choix est un objet éditorial pouvant contenir : un titre, un petit texte, une image, un lien	#3
	Le lien peut être soit une URL arbitraire, soit un objet SPIP : "article123" ou "evenement456" (essayer de prévoir un sélecteur/navigateur pour aider)	#4
	Pouvoir lier une sélection à un objet SPIP (notamment à une rubrique par exemple)	#5
	Prévoir au moins un, sinon plusieurs, morceau à inclure, qui génère le HTML d’une sélection, pour insérer dans les squelettes du site (sur l’accueil notamment)	#6
	Le plugin ne devrait PAS prévoir de styles graphiques ou JS : c’est aux utilisateurs de faire en sorte de générer un carrousel ou n’importe quoi d’autre suivant leurs besoins	#7

Menus

?	Titre	#
	Définir un format de tableau pour décrire les menus	#1
	Stocker les entrées dans un champ unique sérialisé comme pour les saisies de Formidable	#2
	Utiliser le YAML et Saisies pour décrire les paramètres (en gardant la compat du XML pour ne rien casser)	#3
	Refaire l’interface avec saisies et drag-n-drop	#4
	Ajouter un champ "actif/inactif" pour chaque entrée afin de pouvoir les désactiver sans les supprimer	#5

Saisies

?	Titre	#
	Permettre d’activer du multi-étape, en transformant par exemple tous les fieldsets racines en une étape (les champs n’étant dans aucun fieldset racine seraient affichés sur tous les pages)	#1
	Ajouter une configuration pour l’option "afficher_si" de Joseph	#2
	Faire inter-agir "afficher_si" avec le multi-étapes s’il est activé, afin de pouvoir n’afficher des étapes que sous certaines conditions	#3
	Ajouter une entrée de configuration générale dans le tableau de l’API [1]	#4
	Activer/désactiver facilement la possibilité de choisir soi-même le nom des champs	#5
	Pouvoir personnaliser les squelettes de _base et chaque saisie, suivant un identifiant connu lors de l’appel à #GENERER_SAISIES	#6
	Pouvoir passer une liste blanche/liste noire des options qu’on a le droit de modifier dans le constructeur, à la fois globalement, mais aussi possiblement champ par champ. Cela permettrait de mélanger champs extras avec champs déjà existants (qu’on pourrait moins modifier et pas supprimer).	#7

Formidable

?	Titre	#
	Avoir une API d’upload de fichiers générique pour CVT (stockage du fichier dans un dossier temporaire propre au visiteur)	#1
	Ajouter un champ fichier(s) à Saisies, et donc à Formidable	#2
	Importation automatique des formulaires et des réponses depuis F&T (fait par Cédric)	#3

GIS

?	Titre	#
	Refaire la page d’accueil de GIS : mieux lister les points, moins fouillis, triables	#1
	Sur la carte afficher peut-être seulement les points de la page en cours et réactualiser à chaque pagination	#2
	Permettre de filtrer par liaison avec un type d’objet (ex : "Afficher uniquement les points liés à des Organisations")	#3
	Permettre de lister et supprimer les points orphelins, qui ne sont liés à rien	#4
	Dans le nettoyage régulier, supprimer vraiment toutes les liaisons mortes, pas juste les articles et les brèves	#5

Noyau

?	Titre	#
	Ajouter la déclaration du type d’objet parent lors de la déclaration d’un objet	#1
	Écrire un vrai routeur d’URL comme celui de Symfony ou (peut-être) encore mieux : arriver à intégrer leur module tel quel ? (pour réutiliser des composants plutôt que refaire des choses)	#2
	Sortir le compilateur du noyau, en librairie à part, pour pouvoir faire des squelettes sans installer SPIP (comme twig)	#3

Commerce

?	Titre	#
	Passer tous les plugins en SPIP 3 (fait par d’autres)	#1
	Faire un plugin de liaison "commandes_paiements" entre les paiements de Cédric et les commandes	#2
	Faire un plugin de gestion des taxes (TVA ou autres)	#3
	Faire plugin de frais de port	#4
	Idée : une table spip_prix(objet, id_objet, prix, devise) qui permet d’avoir plusieurs prix pour un même objet (mais c’est plus une extension donc dans un plugin en plus)	#5

Autres

?	Titre	#
	Faire un tableau de bord (dashboard) pour remplacer complètement l’accueil de l’admin, avec un système de "blocs" que l’on peut placer où l’on veut et configurer. Ensuite les admins peuvent déterminer l’accueil qu’auront les types d’utilisateurs et soit bloquer, soit permettre à chacun de modifier son accueil à son goût. Ça serait enregistré dans une meta pour les configs par défaut, et dans les prefs de l’auteur si on personnalise : suffit d’un tableau qui décrit la liste des blocs et les options.	#1
	Faire une distribution SPIP de création facile et de partage de cartographie, avec importation depuis un tableur (tentative de détection auto des champs importants) ou depuis des GPX ou KML. Ensuite on peut partager ses cartes librement via un code à copier comme pour les vidéos + oEmbed + JSON, etc.	#2

Des idées pas encore organisées en tâches

Formulaires de filtrage
J’ai souvent besoin d’un formulaire de "recherche ET filtrage" avancé, qui me permet de mettre un texte libre ET choisir dans une ou plusieurs listes, un ou plusieurs filtrage (souvent des rubriques de classement, avec polyhiérarchie ou pas). Je dois développer ces formulaires à chaque fois et souvent j’en ai même besoin de plusieurs différents dans le même site (un pour les actualités, un pour l’agenda, un pour un annuaire, un pour des patates).

Je refais donc tout le temps la même chose, et en plus c’est un peu "en dur" à chaque fois. Je me demande dans quel mesure ça serait généralisable… Générer un formulaire de recherche/filtrage en donnant les secteurs où piocher… Je ne sais pas trop.

Mais c’est énervant et fatiguant de reprogrammer à chaque fois le même type de formulaire, d’un site à l’autre, et encore plus à l’intérieur d’un même site.

Il y a peut-être quelque chose à faire en copiant l’API "configurer" des #FORMULAIRE_CONFIGURER_TRUC, en détectant par exemple tous les #FORMULAIRE_FILTRER_TRUC, et suivant le nom à la fin ("truc") aller chercher une config quelque part, dans une fonction ou un pipeline, qui aiderait à générer le bon comportement.