Catalogue d’évolutions à partir de SPIP 2.1

, par _Eric_, denisb

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

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 :