- Ne pas afficher le formulaire de selection d'un serveur de base de donnée si l'on a renseigné _INSTALL_SERVER_DB
- Cacher les paramètres de connexion (adresse, user, pass) au serveur si SQLite est prédéfini dans _INSTALL_SERVEUR_DB
- Utiliser la constante _ECRIRE_INSTALL dans sqlite plutot que _request('exec')=='install' afin de pouvoir faire des installations automatiques avec le plugin 'mutualisation'.

[10968] suite: bonne idée d'interroger le charset distant, mais il faut s'assurer que c'est un site sous SPIP, sinon ça déclenche une erreur faussement inquiétante. Et utiliser à fond les fonctions d'abstractions, ça gagne du code.

faire sauter la limitation des filtres_images aux seules images de IMG/, local/ et images/
Toute image peut maintenant passer dans un filtre_image (sauf si elle a ../ dans son nom de fichier, par precaution)"

image_typo n'est pas comme les autres fonctions images_qcch (yaquoi). il faudrait un jour se trouver des conventions de nommage évitant ce genre de bug.

ne pas passer directement l'include_once() dans charger_fonction : devrait permettre de resoudre #1201 (patV), et unifie un peu plus

Page des statisques d'un article avec pétition: on affiche également l'évolution du taux de signatures quotidien et mensuel, en détournant les fonctions de statistiques pour les visites. Manque de bouton de navigation mais ça viendra. Par ailleurs, il faudrait finir d'abstraire correctement ces fonctions, elles pourraient servir à n'importe quelle table munie d'un champ date et devenir des filtres. A creuser.

dans le cas d'un serveur distant, on interroge sa spip_meta pour connaitre le charset de connexion qui peut etre different de celui du serveur local
en l'abscence on ne fait rien a la connexion, comme le faisait spip 1.9.2 et anterieures
Permet d'interroger un spip 1.9.2 distant en connexion latin1 avec un spip 1.9.3 en connexion utf8
a condition d'ajouter a spip_meta du 1.9.2 la meta 'charset_sql_connexion' valeur='latin1'

Simplification de la compilation des filtres d'image: tout filtre commençant par image_ ou _couleur_ se compilent par un appel de filtrer(), qui est supposé n'appeler que ces fonctions, ce qui supprime le besoin de la matrice. L'optimisation de find_in_path permet à présent de ses dispenser d'une statitique sur l'inclusion qui doublonnerait celle de find_in_path. L'idéal toutefois serait de déporter l'inclusion dans le code compilé à l'extérieur de la boucle. A suivre, on ne sait quand.

Accélération de include_spip, qui se réduit à appeler find_in_path et ignore donc les .php3. On aurait pu l'évacuer entièrement mais on restreint finalement cette deuxième étape à ce minimum par souci de lisibilité. 

Accélération de include_spip+find_in_path: ces deux fonctions vont être fusionnées afin d'éviter des redondances de tests et des allocations de chaînes à chaque appel. Première étape: traitement des cas particuliers.

ATTENTION: les .php3 ne sont plus pris en compte à partir de maintenant.

Permettre aux boucles SPIP de ne pas raler si la table demandée est introuvable. Pour cela, il faut ajouter un ? juste avant la fin de parenthèse : <BOUCLE_nom(TABLE?)>, <BOUCLE_nom(TABLE jointure?)> ou encore <BOUCLE_nom(TABLE ?)>

Cela permet aux squelettes qui utilisent un plugin optionnel ayant créé table X de ne pas signaler par une erreur l'absence de cette table dans une boucle si le plugin n'a pas été installé.

<BOUCLE_plugin(X ?)>#BALISE</BOUCLE_plugin>
</B_plugin>
Texte affiché si X n'est pas présent ou si la boucle n'a pas d'élément
<//B_plugin>

Il était déjà possible d'obtenir à peu près le même comportement (sauf le texte sur l'absence d'élément) en utilisant la balise plugin et une noisette :
[(#PLUGIN{prefixe_plugin}|?{' ',''})
  <INCLURE(fond=squelette_contenant_la_boucle)>
]

Il faut renvoyer le résultat lors de trace_query_end() et non les erreurs, et l'objet PDO de SQLite3 n'aime pas être pris pour une chaine de caractères !

- SQLite2 ne prenait pas en compte (ADD|RENAME) column !
Il faut sous sqlite2 comme pour DROP, MODIFY ou CHANGE, créer une autre table qui contient les changements.

- Les opérations sur DROP, MODIFY, CHANGE, aunsi que pour SQLite2 ADD et RENAME se font maintenant de manière transactionnelle (BEGIN TRANSACTION; les requetes; COMMIT;) de tel sorte que si une erreur survient au cours d'une des requetes, aucun changement ne sera pris en compte.

Au lieu de faire 2 copies entière de la table à modifier pour réaliser une opération DROP ou CHANGE column, il n'y en a plus qu'une :
1) créer une table temporaire qui tient compte des changements à réaliser sur la table ALTERée
2) copier dedans le contenu table altérée (long sur les grosses bases ?), 
3) supprimer la table altérée,
4) renommer la table temporaire avec le nom de la table altérée.

Avec 2 statiques, find_in_path retourne immédiatement si le fichier demandé a déjà été examiné. Du coup, son non appel dans filtrer() est superflu. A noter qu'il serait bon de cloner include_spip sur la signature de charger_fonction, ça éviterait des allocations de chaines superflues.

Incrustation automatique d'une pièce jointe lorsque l'article est vide et la pièce jointe est unique (images mises à part). Autrement dit, afficher le contenu d'un document sous SPIP peut se faire simplement en publiant un article auquel on associe le document, sans avoir à apprendre la syntaxe des modèles.

Permettre à SQLite de faire des requetes qu'il ne connait pas : ALTER TABLE table (DROP|CHANGE|MODIFY) column

Pour cela, la seule solution est : 
A) découpage de la requete en autant de sous requete s'il y a (cas des referers qui ont 3 modifications DROP, CHANGE, ADD dans une seule requete), puis 
B) executer la sous-requete, sauf pour des sous requetes DROP, CHANGE ou MODIFY :
1) créer une table temporaire avec le contenu table à modifier (long sur les grosses bases ?), 
2) supprimer la table à modifier,
3) recréer la table en tenant compte des changements
4) copier les contenus qui correspondent de la table teporaire à la table recrée (long?)
5) supprimer la table temporaire

Du coup, au vu du risque sur ces requetes pour les grosses bases lors d'une mise à jour de SPIP, je ne saurais que trop conseiller de ne pas oublier de faire un DUMP avant ! (Il est fréquent que les mises à jour de SPIP utilisent ALTER TABLE ... DROP|CHANGE|MODIFY ...

Les modèles ''audio'' et ''video'' permettent maintenant d'incruster directement les documents ayant relevant de ces deux types MIME. Attention, PHP ne sait pas toujours calculer les dimensions d'un document vidéo, penser à remplir les champs width / height du formulaire de légende de documents, sinon on ne voit rien.

Modèle ''text'' (amélioration [10948]):  pour les autres sous-types MIME que ''csv'', convertir les chevrons et entourer la pièce par la balise ''pre''. Et utiliser ''_dist'' pour permettre la surcharge.

http://www.spip-contrib.net/Creer-de-grands-tableaux-dans-SPIP,24
remarque qu'il est malcommode de transformer en article SPIP un texte issu d'un tableur. En conséquence, le modèle ''emb'' voit son domaine étendu. Le squelette se réduit à présent à inclure un autre squelette, portant le nom du type MIME principal du document, officiellement au nombre de 5 pour les types simples: ''application, audio, image, video, text''. Pour les quatre premiers, le squelette fait la même chose que la version précédente du squelette ''emb'', mais leur écriture en est simplifiée (et pourrait certainement l'être encore plus);

Pour le type ''text'', le comportement de ''emb'' est à présent d'insérer le contenu du document dans la zone de texte où est utilisé ce modèle (auparant il ne faisait rien). Il suffit donc, pour faire apparaitre le contenu d'un tel fichier (txt, html etc) dans le corps d'un article, d'écrire {{{<embNNN|>}}} où NNN est son id_document. De plus, ce squelette applique, s'il existe, le filtre {{{filtre_text_}}}''sous_type'' sur le contenu en question. En particulier, est fourni le filtre {{{filtre_text_csv}}} qui transforme les ";" en "|", et permet ainsi de visualiser sous forme d'une table HTML mise en page par SPIP, le contenu d'un fichier fourni par un tableur au format CSV.

A noter que sont donc implicitement fournis les modèles ''application, audio, image, video, text'' dont l'usage direct est un peu plus rapide que ''emb''. 

Prospectives:

- on pourrait convenir dans le squelette standard qu'un article sans texte mais muni d'un pièce jointe de type text utilise ce modèle;

- il faudrait fusionner les fonctions charger_fonction, filtrer, chercher_filtre et appliquer_filtre qui font presque la même chose.

Mettre un lien vers soi-même dans les messages de forum privé, afin de faire apparaitre le 'copier ce lien' offert par les navigateurs (suggestion finale de #1191 pour améliorer [10930]).

Faire le même traitement de spip_sqlite_create() que spip_sqlite_alter() pour enlever les UNSIGNED et autres déclarations que n'apprécie pas SQLite aussi dans les alter.

Il y a un problème avec la gestion des reférers qui font quotidiennement un ALTER TABLE ... DROP... CHANGE ... ADD ; mais sqlite ne sait pas faire le DROP column (ni le ALTER column)... Comment faire donc ?

Il arrive que sql_fetch() se sqlite3/PDO renvoie aussi le nom de la table comme sqlite2 au lieu de simplement le nom du champ; il faut l'enlever.