les _DIR_xx se referent tous au repertoire courant (racine ou ecrire/), adopter une convention differente pour _DIR_JAVASCRIPT est confusionnant et casse de plus la compatibilite pour rien
a commencer par la formulaire de login qui envoyait le pass en clair depuis [11169]
on ajoute la constante _JAVASCRIPT qui reference le sous dossier javascript/ et peut etre utilisee dans les find_in_path et les #CHEMIN
Du fait de la faille de securite presente dans [11169] et plus, il est vivement conseille d'upgrader a cette version mini.

un cas courant d'appel indirect de url_de_base() dans mes_options est la pose d'un cookie (de langue par exemple) via spip_setcookie
"

Complément à [11901]: la suppression de la table principale dans la requête lorsque celle-ci ne concerne en fait que la jointutre s'étend au cas de plusieurs jointures et non plus une seule.

Application: trouver dans une hiérarchie la rubrique ayant un mot clé d'un certain groupe:

{{{
<BOUCLE2(HIERARCHIE)
		{id_rubrique}
		{tout}
		{type='Squelette'}
		{inverse}
		{0,1}
		{lang_select=non}
}}}
se compile en
{{{
SELECT L1.id_rubrique
FROM  spip_mots_rubriques AS L1 
    INNER JOIN spip_mots AS L2 ON (L2.id_mot = L1.id_mot)
WHERE (L2.type = 'Squelette')
    AND (L1.id_rubrique IN (329,589,645))
GROUP BY L1.id_rubrique
ORDER BY FIELD(L1.id_rubrique, 329,589,645) DESC
LIMIT 0,1
}}}
et non plus en 
{{{
SELECT rubriques.id_rubrique
FROM spip_rubriques AS `rubriques` 
    INNER JOIN spip_mots_rubriques AS L1 ON (L1.id_rubrique = rubriques.id_rubrique)
    INNER JOIN spip_mots AS L2 ON (L2.id_mot = L1.id_mot)
WHERE (L2.type = 'Squelette')
    AND (rubriques.id_rubrique IN (329,589,645))
GROUP BY rubriques.id_rubrique
ORDER BY FIELD(rubriques.id_rubrique, 329,589,645) DESC
LIMIT 0,1
}}}
Il faut le critère {{{ {lang_select=non} }}} autrement le champ lang est mis d'office et empêche la disparition. Il faudrait voir si cette mise d'office e pourrait pas être évitée.

Mettre un ID sur les boutons du formulaire admin, pour pouvoir les changer dynamiquement en Javascript. Et un Oups.

Eclater la fonction produisant les boutons admin pour qu'il soit plus facile d'en changer certains mais pas tous. Et un appel à sql_fetsel qui n'était pas aux normes.

Différencier le message d'installation d'une sauvegarde selon qu'on fait une fusion ou une installation complète, sinon c'est trompeur.
Au final, rediriger vers l'accueil plutot que de l'appeler directement, sinon le '''import_all''' qui reste dans la barre de navigation est malvenue si on veut recharger.
Tant qu'à faire, introduire la fonction '''redirige_url_ecrire''' qui abrège les appels les plus fréquents à '''redirige_par_entete'''.

Small et medium sont dans un bateau... autoincrement pour tout le monde en PG et SQLite aussi. Complète [11193]

l'orthographe de PostgreSQL est assez funky pour qu'on n'aie pas besoin d'en rajouter http://www.postgresql.org/

Introduction d'une globale, {{{liste_des_etats}}}, donnant les états possible d'un article ({{{prepa, prop, publie, poubelle, refuse}}}) et utilisation dans {{{instituer_article}}} qui contenait du code mort. Il faudrait l'utiliser partout pour pouvoir changer globalement le processus éditorial, mais ce n'est pas pour tout de suite. En attendant ça permet d'écrire des extensions qui contrôlent qu'une demande de changement d'état est recevable.

Aussi dans ce dépot: il apparaît que PG n'optimise pas un COUNT sur clé primaire fixée (autrement dit vaudra 0 ou 1 jamais rien d'autre); réécriture en conséquence.

Correction d'un bug sur spip_pg_select_as() qui provoquait la disparition de 'sp' de 'spip_documents' sur la boucle documents joints d'un article.

- un AS majuscule pour le traducteur mysql/PG
- un DATE_SUB + INTERVAL (en secondes ?) à la place d'une soustraction sur une date.

- certains retours de !$requeter étaient mal placés
- un argument de la fonction spip_pg_countsel() n'était pas à sa place

En fait le fichier v019.php n'est plus à modifier depuis que la valeur de spip_version est celui d'une SVN: c'est svn10000.php à présent.

Ne pas vérifier les tables en cas de reinstall, on ne sait pas ce qui est anormal. Et erreur de syntaxe dans une MAJ.

SQLite ajoute maintenant automatiquement sur sql_insert, sql_insertq, sql_replace, sql_update et sql_updateq les champs qui sont déclarés 'timestamp' (s'ils ne sont déjà pas présents dans la requete) afin copier le fonctionnement de mysql. Les champs 'maj' des tables de SPIP se remplissent donc à chaque mise à jour sous SQLite aussi.

N'est géré ici que les champs dont la définition commence par 'timestamp'; 
'defaut current_timestamp' ou 'on update current_timestamp' ne sont pas interprétés.

La correction [11175] pour FROM n'était pas encore suffisante. Reprise du code de calcul_mysql_select_as(). Cette fois les sous requetes et la boucle documents_joints de dist/article.html ne provoquent plus d'erreur sous sqlite.

- un test sur la version de sqlite oublié lors du ménage [11078]
- permettre à sqlite les sous-requetes (un élément de FROM disparaissait) introduites en [11155]

suppression des index qui n'amenent rien en perfo dans le cas d'utilisation, et ralentissent les insertions

- creation d'une table spip_recherches qui stockent les resultats par id/points pour chaque recherche
- les requetes decriees par #1231 et consort disparaissent au profit d'une simple jointure

La portabilite sql est a verifier pour cause :
- d'une fonction HEX() reliquat des vieilles version mysql
- dune jointure implicite ecrite en clause SELECT/WHERE dans le critere recherche

* impossibilite d'uploader une image #1238
* certaines images sont mal converties en mode 'image' et restent en 'vignette' ; pas trouve pourquoi, mais les vignettes devraient de toutes facons etre affichees