Apprentissage de SPIP
La documentation
- redéfinir le rôle de spip.net, doc.spip et programmer.spip : objectifs ? utilisateurs ? Les mettre à jour ensuite.
- nécessité d’un nouveau site pour démarrer avec SPIP ?
- refondre doc.spip.org pour en faire à terme un véritable manuel de référence des fonctions (à la php.net)
- continuer d’alimenter programmer.spip.org (exemples plus pertinents)
Les sites de la galaxie
- développer le site plugins.spip comme agrégateur des plugins autour de SVP (réalisé pour 3.0 : « http://plugins.spip.net/»)
- faire un état des lieux des sites SPIP. Maintenus ? Utiles ? À revoir ?
- finaliser la boussole de SPIP en peaufinant la liste et le contenu littéral et graphique. Inclure cette boussole comme extensions de SPIP et sur tout les sites de la galaxie(réalisé pour 3.0 : « http://boussole.spip.org/» et « http://zone.spip.org/trac/spip-zone/browser/_plugins_/boussole»)
Les autres médias et évènements
- reprendre la gazette ? Autre chose ?
- Quel est l’état des apéros ? Faut-il lancer un autre concept ?
Les outils pour débuter
- des distributions adaptées aux utilisations / utilisateurs ( voir : Extensions et Distributions )
- proposer un pack basique, simple à comprendre et à personnaliser par un utilisateur néophyte
Image de SPIP
- proposer une vitrine léchée de ce dont est capable SPIP
- Quel prochain évènement SPIP ?
SPIP, un framework
Les fonctions de base
- Finir l’extraction de fonctionnalités et passage en extension :
- breves (réalisé pour 3.0)
- compresseur (déjà réalisé depuis 2.1.0)
- dev (réalisé pour 3.0)
- dist_2007 (réalisé pour 3.0)
- dump (réalisé pour 3.0)
- filtres_images (déjà réalisé depuis 2.1.0)
- forum (réalisé pour 3.0)
- gouverneur (réalisé pour 3.0)
- grenier (réalisé pour 3.0)
- media (réalisé pour 3.0)
- mots (réalisé pour 3.0)
- msie_compat (déjà réalisé depuis 2.1.0)
- organiseur (réalisé pour 3.0)
- petitions (réalisé pour 3.0)
- porte_plume (déjà réalisé depuis 2.1.0)
- revisions (réalisé pour 3.0)
- safehtml (déjà réalisé depuis 2.1.0)
- sites (réalisé pour 3.0)
- statistiques (réalisé pour 3.0)
- themes (réalisé pour 3.0)
- urls_etendues (réalisé pour 3.0)
- vertebres (déjà réalisé depuis 2.1.0)
- Compléter la typo de base de SPIP pour limiter l’ajout des plugins type enluminures
- Ajouter une box de base (réalisé pour 3.0 : extension « mediabox »)
- Ajouter le support de yaml si vraiment le xml donne des boutons ? (réalisé pour 3.0 : extension « textwheel »)
Le développement de l’espace privé / public
- Décider sur l’utilisation de Z et figer les nomenclatures
- finaliser zcore
- Découpage des css pour le public et le privé (réalisé pour 3.0)
- définir un « guide » de l’interface graphique (GUI) du privé
- créer les éléments de base de l’interface privée réutilisables par les plugins : (réalisé pour 3.0 : charte.html)
- harmonisation/rationalisation des liens (interface à 1 clic, onglets ...)
- stabilité des éléments (navigation, actions, repères ...)
- pertinence de l’iconographie et réutilisation d’icônes pour des actions similaires (réalisé pour 3.0 : intégration du jeu d’icones « fatcow »)
- proposer une gestion des thèmes graphiques personnalisables dans le privé (réalisé pour 3.0 : « squelettisation » du privé)
- quel outil de configuration ? (réalisé pour 3.0 : formulaires « CONFIGURER_ »)
- Utilité des fonctions de Bonux ?
- la boucle POUR ou le foreach avec paramètre (réalisé pour 3.0 : « iterateur »)
- la possibilité de conditionner l’appel d’une boucle (réalisé pour 3.0 : critère « si »)
- les tris dans les boucles ? (réalisé pour 3.0 : critère « tri »)
Amélioration et optimisation de SPIP
- intégrer médiathèque comme extension en remplacement de la gestion des documents ? (réalisé pour 3.0 : extension « medias »)
- intégrer STEP et SVP comme extensions en remplacement de la gestion des plugins ? (réalisé pour 3.0 : extension « svp »)
- intégrer textwheel comme extension en remplacement de la gestion typographique ? (réalisé pour 3.0 : « textwheel »)
- renforcer le portage postgresql
- définir une API stable pour les fonctions de date
- simplifier la gestion du multilinguisme (langue d’interface / langue de l’objet affiché ; #MENU_LANG ; $forcer_lang ...)
- terminer la balise #RANG
- simplifier l’utilisation des < doc >, < img > et autres < emb >
- passer les fichiers de langue en utf-8 (réalisé pour 3.0)
- rendre plus pertinents les fichiers de log (réalisé pour 3.0 : extension « dev »)
- paginations ajax et retour page précédente (réalisé pour 3.0)
sur la différenciation des éléments temporaire/de configuration
- tmp/
. actuellement, le répertoire tmp/ rassemble des éléments temporaires : fichiers de cache ou de session par exemple ; des éléments permanents : fichiers de dump, fichiers d’upload, voire de log et, parfois, des éléments de configuration : les fichiers syndic_plug_..., certains éléments des plugins - la table spip_meta
. cette table rassemble des éléments de configuration qui ont vocation à être permaments : charset_sql_base, email_webmaster ; des éléments temporaires : alea_ephemere_..., derniere_modif_...
. de plus elle regroupe des éléments qui concernent spécifiquement spip : type_urls, nom_site mais aussi parfois des éléments spécifiques aux plugins installés (ou activés, ou les deux...) : gestdoc_base_version, svp_categories et autres googlefonts_api
ce qui n’est pas sans poser de problèmes lors des sauvegardes/restoration, ou des désactivation sauvages des plugins
Nouvelles fonctionnalités pour SPIP
- des rôles pour les auteurs
- des niveaux d’erreurs différenciés (réalisé pour 3.0 : extension « dev »)
- boucler sur autre chose que des tables sql (réalisé pour 3.0 : « iterateur »)
quel SPIP pour l’an 2050 ?
– sur les éléments de la syntaxe :
-
<BOUCLE>
-
{critère}
. les critères s’appuient sur les champ sql des tables (id_article, date), excepté une liste précise (par, pagination, tout, branche...) -
#BALISE
. nous avons aujourd’hui une écriture identique pour des fonctionnalités différentes : #STATIQUE (valeur d’un champ sql), #DYNAMIQUE (script de formulaire), #CALCULÉE (url d’objet, appel de modèle), #FONCTION (soit déclarative comme « ARRAY », « SET », « GET » soit exécutive comme « FILTRE », « PIPELINE ») -
#_boucle:BALISE
-
|filtre
-
{arg}
-
[( )]
. crochets et parenthèses sont parfois indispensables (partie conditionnelle d’une balise), parfois interdits (critère de boucle), parfois optionnels (déclaration dans un SET) -
<:idiome:>
-
<multi>
-
<INCLURE>
– sur le nommage
- des fonctions :
. en particuliers des filtres homonymes de fonctions PHP mais retournant un rendu différent (reset, end, foreach, explode, implode ...)
- des constantes :
. préfixées ou pas par _ , en majuscules ou minuscules, voire les deux mélangées (_ID_WEBMESTRES, CONFIRMER_MODIFIER_URL, _separateur_urls_page, _DELAI_CACHE_resultats ...)
- des fichiers :
- des balises :