probleme lors de la creation d'article sans preciser id_rubrique : l'insertion du nouvel article se faisait bien dans le premier secteur, mais la suite donnait a l'article une langue vide (Reda)

Pour faire un plugin qui gere la restauration propre de tout dump d'une ancienne version
(scratch des tables, creer_base selon v 0.97?, upgrade jusqu'a version cible, restauration, puis upgrade final)

petit detail sur les mots-cles : ne pas proposer de creer un mot et l'associer, ca alourdit l'interface dans le cas general, et sert peu souvent, d'autant que le bouton en question est repete au-dessous

resoud les bugs graphiques du formulaires_mots + unifie ajax et non ajax sur les liens GET (pas encore POST, c'est plus complique). #518

API: plus besoin de passer les donnees qu'on ne veut pas changer en <input type='hidden'> ; devrait permettre d'utiliser action/editer_article a partir d'un formulaire reduit (qui ne toucherait que le titre et descriptif, par exemple)

L'agenda intègre la mise en page générale du site (entête et pied de page). Ça déborde encore...

- une classe générale (agendagrrr, qu'on renommera mieux ensuite ;-)
- qui permet simplification des noms des class enfants

Passage en Ajax des messages de forums attachés en interne à un article. Ce passage devait pouvoir facilement s'opérer aussi dans les autres scripts utilisant la fonction afficher_forum, apres plus grande généralisation du script discuter.php. 

A noter qu'il devient évident qu'il faut supprimer tous les "echo" dans les scrips exec, afin que chacun d'eux puisse potentitellement etre inséré dans un autre grace à Ajax.

La mention 'agenda' l'emportant sur celle de 'calendrier' (dans les noms de fichiers, filtres et compagnie), homogénisons !

Formulaire_mot en Ajax, et migration dans exec/mots_tous des fonctions de inc/mots ne concernant que ce script. Au passage, retrait des redondances de requetes SQL et de redirections contenues dans ce script. Pour passer ce script en Ajax, il faudra unifier avec tranches_requetes qui l'utilise aussi.

L'aspect graphique du formulaire_mots s'est un peu dégradé, en ce qu'une action Ajax en GET ne fera  plus apparaitre le curseur Main, mais le curseur d'insertion. En fait il  faudrait un curseur spécifique pour toutes les actions Ajax, GET ou POST, ce serait l'idéal.

Il reste encore des formulaires que l'on pourrait passer en Ajax dans le script exec/articles, mais pour la plupart il faurait changer la présentation afin qu'une seule zone de la page soit concernée par l'impact des écritures SQL du script exécuté (ou alors rédiger des Ajax plus complexes mais ça ne me parait pas souhaitable).

admettent les memes arguments afin qu'il soit plus facile de passer en mode Ajax lorsque la partie correspondante du DOM est configurée pour.

Idéalement il faudrait aussi qu'elles retourne le meme genre de résultat (un formulaire ou un <A href=X>clic</A>) mais ça impose de revoir menu_langues, icone et icone_horizontale.

Aussi: explication de la variable d'URL select_groupe sortant auparavant d'on
ne savait où dans le formulaire mot (voir depot suivant).

Ajax_squeeze reconnait à présent les boutons radio, d'où passage en Ajax du formulaire des dates (publication / rédaction) d'un article. Plus nettoyages divers, notamment pour  le dépot suivant.

Sécurité Ajax: depuis que les formulaires sont appelables par des scripts autonomes, il faut revérifier les droits du connecté sur l'objet sur lequel s'applique le formulaire. Autrement les simples rédacteurs et les admins restreint peuvent se fabriquer un formulaire modifiant les annexes (pièces jointes, forums, pétition etc) d'un objet qu'il n'administre pas.

- nouvelle date_interface qui affiche 'il y a xxx minutes' si la date est recente, mais affiche la date complete si plus de 12 heures, permet de restaurer un affichage correct dans le suivi des forums plutot que des tonnes de 'il y a 3 mois'... (Perline) + petouille graphique sur les breves dans l'espace prive