et on delegue a trouver_fond la tache de trouver un fond dans le chemin en prenant en compte son extension.

Elle s'enrichit d'un argument optionnel booleen permettant de retourner son resultat sous forme de tableau type pathinfo
dont la valeur 'extension' est toujours renseignee (meme en cas d'echec), et dont la valeur 'fond' contient le nom du fichier sans l'extension.
 
Cela permet d'eviter de mettre l'extension en dur dans styliser.
Les plugins pourront utiliser cette fonction, et continuer a etre compatible avec les anciennes versions de SPIP simplement
en la definissant si elle n'existe pas

La constante _EXTENSION_SQUELETTE qui indique l'extension d'un
sauelette avait beaucoup trop d'occurrences dans le code,
ce qui ne permet pas facilement de mettre en place une strategie
ou plusieurs extensions seraient possibles simultanement.
Il n'y a besoin que d'une seule occurrence en fait,
dans la fonction {{{trouve_modele}}} sur laquelle toutes les autres se
rabattent.

Pour le decompilateur, il faut se baseru sur l'extension du
fichier de depart pour retrouver l'information, et n'avoir
qu'un seul point d'entree poureviter de gerer une valeur par defaut.

Pour le debusqueur, on donne le nom du squelette sans l'extension
puisque justement il est possible qu'il y ait le choix.

Unification de la table des liens auteurs en spip_auteurs_liens qui remplace ainsi les 3 spip_auteurs_articles, spip_auteurs_rubriques et spip_auteurs_messages
et permettra aussi de gerer les liens auteur sur n'importe quel objet. On a en plus un champ vu sur la table de liaison, qui est utilise dans la messagerie.
On pourra avoir plus tard un champ role permettant de distinguer les roles des auteurs.

Ce premier commit met a jour toutes les requetes SQL, et prend en charge l'upgrade de la base.
Mais il n'est pas encore totalement fonctionnel. 
debug a suivre.

il n'est evidemment pas necessaire de decoder le contexte ajax et de faire plein de verification si le form poste n'a pas le meme nom que le form que l'on affiche, pour savoir si celui-ci vient d'etre poste...

faire retourner le nom du serveur en minuscule a la fonction trouver_nom_serveur_distant
et utiliser la fonction dans le traitement generique des #URL_

une fonction trouver_nom_serveur_distant($p) qui renvoie le nom du connect de la boucle en cours si il est defini et n'est pas dans une exception.
Utiliser cette fonction dans la balise #URL_PAGE pour supporter les connect derogatoires (plugins).

Correction d'une régression introduite par [16358]: dans le cas
d'un connect spécifique, il faut bien passer à la fonction
generer_generer_url_xxx les arguments éventuels de la balise
(merci Cerdic de l'avoir remarqué).

C'est tordu tout ça.

Utiliser isset() pour tester l'existence d'une variable, pas defined()
qui est pour les constantes (merci Cerdic).

Quand des arguments sont passés à la balise #URL_PAGE, l'appel à la
fonction generer_url_public() est construit avec un 2e argument.

C'est aussi le cas quand il y a un connect spécifique.

Du coup, quand les deux cas sont vrais en même temps, le connect
passe en 3e argument. On corrige ce cas en construisant la chaîne
d'arguments à part, et on ne la passe à generer_url_public qu'en un
seul point.

(Je veux quand même bien une relecture, car c'est un bout de code
un peu sensible.)

Tenir compte aussi des Plugins mis dans le r\303\251pertoire Auto pour retrouver les infos associ\303\251es.
Et mieux propager l'\303\251ventuel message d'erreur pour qu'il apparaisse \303\240 la place du formulaire.

 * func_get_args n'aime pas etre transmis comme argument de fonction

#LOGO_ : on s'aligne sur le traitement de #LOGO_DOCUMENT comme préconisé par [13550], à savoir {{{#LOGO_RUBRIQUE{200, 0}}}} est equivalent à {{{[(#LOGO_RUBRIQUE|image_reduire{200, 0})]}}}.
report de [15844].

Lorsque les arguments d'un CVT contiennent une url de retour, et que celle-ci est construite par l'appelant sur la base de #SELF, 
celle-ci peut etre polluee par une variable postee dans le formulaire. 
Du coup les arguments changent et la balise #FORMULAIRE ne reconait pas le formulaire responsable du post. La seule solution etait de forcer la prise en compte du POST, ce qui interdit d'avoir plusieurs formulaires sur la meme page.

Pour y remedier, on introduit en sus des 3 fonctionc charger, verifier, traiter, une fonction optionnelle identifier qui est chargee de retourner une signature en fonction des arguments du formulaire, en ignorant ceux qui ne reprensentent pas l'objet saisi.

On aurait pu demander a charger de retourner cette signature dans la table des valeurs, mais ca aurait oblige a faire un double appel a la fonction charger() du formulaire.

Permet par exemple de recuperer dans le plugin forum le titre et l'url de l'objet sur lequel porte le forum, quel qu'il soit (ce que ne permet pas une boucle dont la table doit etre connue a la compilation), avec #INFO_URL{#OBJET,#ID_OBJET} et #INFO_TITRE{#OBJET,#ID_OBJET}

Utilise le filtre generer_info_entite($id_objet,$ojet,$info). Attention, l'ordre des arguments de ce filtre est inverse, par coherence avec la fonction existante generer_url_entite.
Il peut de ce fait aussi etre utilise plus simplement comme filtre : [(#ID_ARTICLE|generer_info_entite{'article','titre'})]


/**
 * Donner n'importe quelle information sur un objet de maniere generique.
 *
 * La fonction va gerer en interne deux cas particuliers les plus utilises :
 * l'URL et le titre (qui n'est pas forcemment le champ SQL "titre").
 *
 * On peut ensuite personnaliser les autres infos en creant une fonction
 * generer_<nom_info>_entite($id_objet, $type_objet, $ligne).
 * $ligne correspond a la ligne SQL de tous les champs de l'objet, les fonctions
 * de personnalisation n'ont donc pas a refaire de requete.
 *
 * @param int $id_objet
 * @param string $type_objet
 * @param string $info
 * @return string
 */
function generer_info_entite($id_objet,$ojet,$info)

Report en spip 2.2 des améliorations du validateur et du débusqueur: [15927], [15928], [15930] (avec [15698]), [15933], [15934], [15935] (inclut [15912]), [15941], [15943], [15944], [15949], [15951], [15952], [15955].

La balise #REMPLIR (ci-devant #FORMULAIRE_CONFIGURER_PLUGIN cf [15846]) se nomme dorénavant #CONFIGURER_METAS.

Complément à l'harmonisation des deux branches pour la réutilisation de code CVT par [15779]: il manquait le fichier {{{formulaire.php}}}. Je remets la version std de {{{existe_formulaire}}} pour éviter toute différence entre la 2.1.0 et la 2.1.1 {{{#REMPLIR}}} peut faire sans. Et une scorie.

       * Identification dans les deux branches de la compilation de #ACTION_FORMULAIRE. L'erreur d'argument manquant n'était pas traitée; vu l'usage quasi général, cette absence est assimilée à un premier argument égal à {{{#ENV{action}}}} ce qui allège l'écriture.

       * renommage dans la branche Dev de la balise de #FORMULAIRE_CONFIGURER_PLUGIN en #REMPLIR, ce qui évite d'y voir des problèmes qui n'en sont pas et permet d'expérimenter.

       * retrait dans la branche 2.1 de ces 4K de code concernant cette balise afin de sortir une 2.1.1; il suffira de copier les deux fichiers {{{ecrire/balise/remplir.php}}} et {{{prive/formulaires/remplir.php}}} de la branche Dev dans une installation de la 2.1.1 pour expérimenter dans cette branche.

Ne pas oublier que {{{existe_formulaire}}}, comme son nom ne l'indique pas, de normaliser le nom (Cedric).

Cette balise ne prend plus qu'un seul argument, un squelette de formulaire. Elle verifie son existence et fournit un trio de fonctions CVT par défaut pour son utilisation. Pour chacune des 3 fonctions, s'il existe une fonction homonyme au nom du squelette, c'est elle qui prend la main. Sinon, le comportement par défaut proposé  consiste à trouver la table des métas associée à ce formulaire pour y lire les valeurs (fonction {{{_charger}}}) et les y écrire (fonction {{{_traiter}}}). Rien n'est fait pour la fonction {{{_verifier}}}).

Le chemin d'accès au squelette détermine la table des métas associée. S'il commence par {{{_DIR_PLUGINS}}} (autrement dit si le formulaire a été trouvé dans un plugin), la table des métas associée est celle du plugin (qui est par défaut le préfixe du plugin, suivi de {{{_metas}}}). Sinon c'est la table des métas standard.

A noter que cette balise ne s'applique plus forcément à un plugin et qu'elle devrait donc changer de nom ({{{#GERER}}} ou {{{#REMPLIR}}} sembleraient plus appropriés). 

A noter aussi que la fonction booléenne {{{existe_formulaire}}} renvoie maintenant le chemin, alors qu'elle renvoyait auparavant son argument initial ce qui n'était pas très utile.

Plutôt que de faire des contorsions dans la compilation de la balise #ACTION_FORMULAIRE, il suffisait de remarquer que la balise dynamique appelante a mis dans l'environnement le nom du formulaire CVT dont #ACTION_FORMULAIRE a besoin. Du coup, #FORMULAIRE_CONFIGURER_PLUGIN met son propre nom, ce qui lui permet de reprendre la main pour les fonctions CVT sans obliger les squelettes qui l'utilisent de l'indiquer eux-mêmes dans le 2e argument de #ACTION_FORMULAIRE.

Y a-t-il des cas où #ACTION_FORMULAIRE est appelé autrement qu'avec un unique argument égal à #ENV{action} ? En tout cas, il semble que ces balises dynamiques devraient plus généralement rajouter elles-mêmes ce que rajoute #ACTION_FORMULAIRE: cette balise incompréhensible pour l'utilisateur serait ainsi éliminée, et le code du compilateur gagnerait en clarté en regroupant en un seul endroit toute la production de ces input-hidden.

#FORMULAIRE_CONFIGURER_PLUGIN: ne pas mettre le chemin en dur, c'est une baisse de fonctionnalités (suite de [15760]).

Introduction de {{{#FORMULAIRE_CONFIGURER_PLUGIN}}}, suite du chantier visant à remplacer CFG (cf [15726] et [15753]).

Cette balise admet au moins un argument, savoir le nom du plugin (donc le nom du sous-répertoire de DIR_PLUGINS) qu'il faut configurer. Ce répertoire doit contenir un sous-répertoire nommé {{{formulaires}}} contenant au moins un squelette. Le nom de celui-ci est donné soit par le 2e argument de la balise s'il est présent, soit est pris conventionnelle égal à {{{configurer_}}}{{préfixe_du_plugin}}}. Le contexte (calculé par une fonction {{{_charger}}}) est égal à la table des métas associée à ce plugins. Le traitement des saisies (fonction {{{_traiter}}}) consiste à écrire dans cette table des metas les valeurs (chaîne vide si abstentes) que {{{$_POST}}} indique pour tous les noms trouvés dans le formulaire, à l'aide d'une RegExp (pas totalement fiable) repérant les attributs {{{name}}} dans le formulaire. Ces deux fonctions sont donc communes à tous les formulaires de configuration de tous les plugins voulant les utiliser. Il n'y a pas de fonction {{{_verifier}}}, faute de savoir que vérifier pour chacun (interface à définir pour arranger ça).

Pour fonctionner correctement, les formulaires référencés (implicitement ou non) par cette balise doivent utiliser {{{#ACTION_FORMULAIRE}}} avec comme deuxième argument le nom du plugin. Voir un exemple dans le [http://zone.spip.org/trac/spip-zone/changeset/38755 plugin Association 2].

Découpage en deux de la grosse fonction {{{balise_formulaire__dyn}}} afin de pouvoir définir une balise dynamique qui ne s'en distingue que par le calcul du nom du squelette.

Au passage, report dans la branche Dev de [15620] fait seulement sur la 2.1, pour corrigeait le mauvais correctif [15401]. 

on continu de sortir les pétitions du core suite de http://zone.spip.org/trac/spip-zone/changeset/38541

Configuration des plugins, report de [15723], [15724] et [15725], plus [15168] pour le style et aussi [14975] déclenchant le debusqueur dans ecrire, qui n'avait pas été reporté.

La page des plugins actifs est construite à présent à l'aide d'un mini-squelette {{{prive/cfg.html}}} qui auparavant se réduisait à des balises A en dur dans le code référençant le plugin Cfg. C'est donc maintenant un vrai squelette, utilisant la balise {{{#URL_ECRIRE{configurer_}}}nom-du-plugin{{{}}}}. Il suffit donc d'avoir un script PHP ainsi nommé dans {{{exec/}}}, ou un squelette ainsi nommé dans {{{prive/exec}}}, pour qu'apparaisse dans le bloc du plugin l'icone de configuration avec un lien sur le configurateur.

Si l'on souhaite donner un autre squelette (pour changer l'icone, inclure en Ajax le configurateur etc), il faut l'écrire dans le répertoire du plugin et indiquer son nom dans la balise {{{config}}} de {{{plugin.xml}}}.

La compatibilité avec Cfg est assurée: si {{{plugin.xml}}} demande d'utiliser Cfg et ne contient pas la nouvelle balise {{{config}}}, c'est le même code qu'auparavant qui est pris.

Au passage, la balise {{{#URL_ECRIRE}}} est améliorée: si son argument lui ferait produire une URL inconnue elle ne retourne rien, ce qui permet des écritures comme {{{[<a href="(#URL_ECRIRE{#SCRIPT})">cliquer ici</a>]}}} qui auparavant étaient vaines. Elle est utilisable même dans le contexte d'une boucle sur serveur distant, qu'elle ignore.

Report de [15514] [15515] [15516] [15517] [15518] [15519] [15528] [15529] [15530] [15531] [15532] [15533] [15535] [15536]

Report de [14590] [15492] [15494] [15495] [15496] [15497] [15498] [15499] [15500] [15502] [15503] [15505]