eviter de detecter a tort un modele dans du html/code/cadre .... pour l'association de document avec un objet

evacuer une exception de nommage dans les invalideurs en les normalisant sous la forme "objet/$id_objet"
L'utilisation de objet_type() assure la retrocompatibilite avec les appels de la forme "id_article/23", le seul cas non suivi etant le "varia/pet23" qui doit etre remplace par deux invalideurs "signature/xxx" et "article/yyy"

permettre de passer plusieurs invalideurs a inc/modifier pour gerer les objets lies dans les invalidations

Prise en compte de la copie du nom du groupe dans la table spip_mots dans le plugin «mots» ( http://zone.spip.org/trac/spip-zone/changeset/41097)

trouver_table('spip_articles') recherchait la table reellement nommee spip_articles en base, sans changer le prefixe, ce qui obligeait, le cas echeant, a gerer le prefixe en amont de l'appel.
Ce comportement est incoherent avec le reste de l'api SQL car si on est sur une base avec prefixe 'truc_' et qu'une table 'spip_articles' est trouvee par trouver_table, la requete sql que l'on essayera de faire juste apres sur cette table sera en fait realisee sur truc_articles, puisque toutes les sql_xx renomment le prefixe automatiquement (sauf sql_showtable qui dispose d'un argument pour activer ce renommage, par defaut a false).

On introduit donc un argument $table_spip sur trouver_table, en 3eme position pour ne pas changer la signature, par defaut a true, ce qui correspond a l'usage general.
trouver_table('spip_articles') trouvera donc 'truc_articles' dans une base avec prefixe truc.
Pour trouver la vrai table spip_articles, il faut faire, le cas echeant trouver_table('spip_articles','',false);
Sachant qu'il n'est de toute facon pas possible de faire un sql_select sur cette table par l'api SQL, sauf peut etre en quotant le nom de la table avec les `spip_articles`

Ce changement risquant d'introduire des petits bugs, on le fait des maintenant pour avoir le temps de les detecter.

Corrolairement, dans une <BOUCLE_xx(spip_articles)>, c'est toujours la table principale qui est prise en compte, avec renommage du prefixe, idem pour les jointures.

[15357]  était une bien mauvaise idée. sql_updateq ne retourne jamais false même si aucun update n'est effectué. il faut donc tester aussi sur la non pré-existence du lien pour que le insert soit lancé (kent1)

éviter le warning mysql "Duplicate entry for key 'PRIMARY'..." ou postgresql "duplicate key value violates unique constraint...".

ecrire_acces() disparait, la generation du htpass pour la methode 'spip' etant du ressort de auth_spip_synchroniser_distant
Cette derniere regenere tous les acces, mais il y aurait moyen de faire mieux en ne mettant a jour que l'acces modifie qui est passe en arg.

Legere modification de l'api auth_synchroniser_distant qui peut etre appelee sans argument pour forcer une resynchro de toutes les methodes et acces
apres une operation en base.

preparation du redecoupage des fonctions dans editer_auteur pour etre conforme aux autres action/editer_xx, et passer par l'api auth

Restent :
- les meta de config a deplacer dans le plugin forum
- quelques jointures explicites mais conditionnees a la presence du plugin"

Dépot obtenu par:

{{{
for i in $(grep  -l '(c) 2001-' * */* */*/* 2> /dev/null)
do
sed 's/(c) 2001-2008/(c) 2001-2009/' $i > /tmp/x
mv /tmp/x $i
done
}}}

un charger_fonction manquant, et une generalisation autour de marquer_doublons_documents et traiter_modeles :
la fonction traiter_modeles permet de reperer d'autres types d'objets que les documents
avec la syntaxe
traiter_modeles($champs['chapo'].$champs['texte'],array('des_trucs'=>array('truc','machin')))
qui remplira la 
$GLOBALS['doublons_des_trucs_inclus'] pour tous les modeles <trucXX> ou <machinYY> presents dans le texte ou le chapo

aucun impact sur les appels existants avec le $doublons=true qui repere par defaut les documents

revision de la fonction de suppression des documents : on peut desormais transferer un document d'un article a un autre, la suppression effective ne se faisant que lorsqu'il ne reste plus un seul lien dans spip_documents_liens ; introduction (optionnelle car pas terminee) d'une interface unifiee images/documents (#483, #1505)

ce qui la rend extensible et utilisable par les plugins pour tout type d'objet
l'upgrade devrait se faire a partir de la table spip_documents_liens precedente ou des anciennes tables spip_documents_xxx selon le point de depart

tous les points d'entree sont la pour gerer intregralement ceux ci dans un plugin

au passage les champs articles, rubriques,breves,syndic de spip_groupes_mots sont fusionnes en un seul champ "tables" contenant les noms des tables separes par des virgules
le code plus generique devrait permettre l'extension a d'autres tables sans surcharge (plugin agenda, mots partouts ...)
petites corrections stylistiques des formulaires
les <legend> sont remplacees par des <h3 class='legend'>

unification de la table de jointure des documents avec 'autre chose', quel qu'il soit ; et affichage des docs de forum dans le contrle_forum

Permettre le fonctionnement de #FORMULAIRE_EDITER_RUBRIQUE lorsque l'on souhaite créer une nouvelle rubrique ;
Correction notamment de la fonction marquer_doublons_documents qui ne doit pas demander un champ 'chapo' si celui-ci n'existe pas dans la table sql

Utiliser systématiquement sql_fetsel plutôt que sql_fetch quand c'est possible, afin de profiter de l'optimisation de [11738], qui évite en particulier des opérations bêtement interdites par SQLite à cause de son compteur de références.

pour editer un article
charge, verifie (par md5, en renvoyant sur le meme formulaire avec message si erreur), traite
La balise ne fait pas de gestion de droit, c'est a la charge du squelette appelant de decider si l'auteur peut editer l'article
etape suivante : utiliser ce formulaire dans l'espace prive

Erreur si revision_forum était appelée avec un seul arg depuis [11350]. Tant qu'à faire, réduire les requêtes SQL au minimum.

gerer les NULL et les extra dans le controle md5 ; et, quand on peut vider le champ extra, on le fait

gestion d'un controle md5() des champs modifies via l'espace prive sur les articles, rubriques, breves, mots-cles, auteurs et sites.

Le scenario est le suivant : supposons que Alice et Bob ouvrent en meme temps le meme article en edition ; ensuite chacun renvoie ses modifs. Les situations sont diverses :
- Alice a modifie le titre, Bob le texte : on accepte les deux modifs, le titre de Bob (inchange) n'ecrase pas le titre d'Alice
- Alice modifie le titre, Bob aussi :
-- ils ont mis le meme titre => pas de probleme
-- le titre differe => on previent Bob, on lui montre son titre, celui qui est stocke' dans la base, la difference entre les deux, et un formulaire pour copier/coller ses modifs

Ces choses sont traitees champ par champ independamment : ainsi s'il y a conflit sur le titre mais pas sur le chapo, le chapo est enregistre, et le message d'erreur ne porte que sur le titre

C'est, evidemment, compatible avec les crayons