Bonjour,
voici quelques réflexions sur la todo-list actuelle de SPIP.
Je ne conserve que les points que je souhaite commenter, donc j'invite
chacun à lire la version complète pour tout savoir ... 
Bugs
----
- vérifier le fonctionnement des dates "floues"
Explication de ce point ?
- faire qqch pour le error_reporting= E_ALL. Soit changer le réglage
à la volée dans SPIP (facile et de nature à faire hurler les
ayatollahs :-)), soit éliminer la cause des warnings (plus long !).
Je ne suis pas un "ayatollah", c'est clair, mais j'aimerais bien que
SPIP supporte tout type d'environnement PHP, que ce soit le
register_globals, le error_reporting, le short_open_tag, le safe_mode,
les magic_quotes_*, et j'en passe ...
- restauration d'une sauvegarde : comparer la version du dump avec
la version courante. Si différente, afficher un avertissement.
Peut-être trouver un moyen d'intégrer les données tout de même,
puisqu'on sait à priori ce qui change d'une version à l'autre.
Structure
---------
- centraliser les requêtes MySQL.
C'est fait pour les query, mais pas du tout pour le reste. Je mets à
disposition à qui veut notre script qui tranforme la version CVS de
SPIP en version PEAR DB.
Premier chantier pour permettre ensuite l'utilisation de différents
SGBD.
- Authentification cookie/session_id en sus de l'auth. PHP.
Supprimer l'auth. par htaccess. Eventuellement, se servir de la
nouvelle auth pour des articles en accès restreint (??)
Pour ça, voir les travaux en cours de Fil, que je commenterais à part.
- Les admins restreints : c'est n'importe quoi, [...]
Manque de sécurité, sans doute, mais le principe est bon.
Voir si on peut ajouter des restrictions à certaines rubriques de
droit d'écriture pour les auteurs, sur le même modèle. C'est
fréquemment demandé, et ça évite aux admins de devoir reclasser les
articles proposés aux mauvais endroits.
- il reste pas mal d'endroits ou on parle de vieilleries : par ex,
les statuts "1comite" et "2redac" pour les auteurs... seul "1comite"
est utilise pour les redacteurs.
Pourquoi conserver ces "1comite" et autres, plutôt que de simples id
numériques ?
Voir d'autres réflexions sur l'auth en général dans SPIP, dans un
autre mail.
Espace privé
------------
- Messages d'erreur plus clairs et joliment présentés lors de
l'naalyse de boucles. (via inc_presentation...)
C'est de l'espace public, ça, non ???
- Nettoyer l'espace privé de toutes les horreurs qui traînent.
Précisions ?
- des htmlspecialchars dans les fichiers xxxxxxx_edit.php3 empêchent
de gérer des textes en alphabets non latins. supprimer ? Ou
remplacer par une fonction dédiée...
Discussions et tests en cours sur différents alphabets, il me semble.
+ mettre le charset utilisé dans spip_meta (pour le japonais ou le
cyrillique)
Attention, il peut y avoir besoin d'un charset par article, donc ne
pas le mettre dans spip_meta ...
- un système de timestamp pour repérer les collisions sur les
articles "sortis pour edition"
Système de verrou, plutôt, le timestamp n'en étant qu'un paramètre.
Espace public
-------------
- un système plus simple de gestion multipages : par exemple un
filtre |page, qui agit sur le #TEXTE mais aussi sur le #NOTES (!),
et gère #NAVIGATION_PAGES.
C'est compliqué : peut-être aurait-on intérêt à gérer le multipages
dans propre() directement ?? Mon idée (Fil) est de stocker tout dans
un seul fichier cache, avec des bouts de code php qui interprète le
?page=2 passé en paramètre.
Je verrais plutôt un moyen d'associer une liste d'articles comme pages
d'un unique article.
Un article maître, qui est la première page, et des articles "pages
suivantes" qu'on lui associe. Ces derniers ne sont pas pris en compte
dans les listes d'articles de la partie publique, et ont une interface
de publication allégée dans la partie privée.
- réintégrer proprement le code de enlettres.php3 (question de
nomenclature, dixit Antoine)
???
- passer des parametres aux fonctions
(exemple : [(#TEXTE|couper(500, "...")|justifier)]
appelle justifier(couper($texte, 500, "...")). )
Meilleure (?) idée de syntaxe : |filtre{50,"..."}
-> filtre($texte,50,"...")
Je verrais plutôt [(#TEXTE|couper;500;"...")] qui serait sans doute plus
simple à gérer.
- inclusions de squelettes : c'est déjà compatible, il faut
maintenant installer la syntaxe nécessaire
A priori : <INCLURE (squelette.php3) {id_rubrique} {id_auteur=5}>
où {...} définit les variables à passer dans le contexte
Attention aux chemins relatifs des fichiers pour ceux qui mettent les
squelettes ailleurs qu'à la racine de SPIP.
- exécution de code lors du calcul de page et non lors de l'appel de
cache : ajouter une syntaxe dédiée <PHP>....</PHP>. Le code est
alors simplement recopié dans le skel_machin.php3 généré, à
l'endroit adéquat.
+1
Filtres
-------
- proposer en standard un filtre qui renvoit un logo par defaut
quand on lui passe une chaine vide (si non vide, renvoit la chaine
qu'on lui passe). Utilisation : [(#LOGO_AUTEUR||logo_auteur_defaut)]
Généraliser à tout type de contenu, remplacé si vide, et utilisable
"en cascade".
Syntaxe proposée par exemple pour gérer l'intro d'un article :
[(#DESCRIPTIF|filtre1)|(#CHAPO|filtre2)|(#TEXTE|filtre3|filtre4)|...]
On gagne ainsi une souplesse énorme ...
Améliorations mail
------------------
- envoyer un mail à l'admin quand un nouveau rédacteur s'inscrit ?
Oui, mais selon choix de(s) l'admin.
- faire que ecrire/ connaisse les inc-urls, pour que les mails
soient plus jolis
Pourquoi pas.
- Pour les mails, changer d'optique : chaque rédacteur décide, dans
sa config perso, s'il reçoit par mail (choix dans un menu) [...]
+1
Au lieu d'envoyer tout de suite les mails, spip procèderait comme
suit [...]
+1
- pouvoir personnaliser les mails automatiques
Par l'usage d'un squelette, ça ne doit pas être trop compliqué, à
priori.
- utiliser (en dernier recours ???) la classe smtp.inc pour envoyer
le mail via SMTP plutôt que via la fonction mail()
+1
N'importe quand
---------------
- Dans l'exécution des squelettes, si une requête échoue, faire un
SELECT(*) FROM table et si échec, faire un REPAIR TABLE table.
Attention aux spécificités MySQL. Plutôt envoyer un mail à l'admin.
- dans les squelettes, plus grande souplesse dans l'utilisation des
minuscules et des majuscules.
Non, trop de liberté complique les traitements et ralenti l'ensemble.
Un peu de fermeté dans ce domaine ne gène pas.
- classer par popularité, popumix....
Et gestion de "notes" attribuées aux articles par les visiteurs, donc.
Fonctionnalités importantes à étudier
-------------------------------------
- Internationalisation.
Attention, deux chantiers ici :
- internationalisation de l'interface de publication
- possibilité de gérer des sites en toute langue, voir plusieurs
- Possibilité d'uploader des fichiers XML pour mettre à jour les
articles
+1
Voilà pour l'instant ...
-Nicolas