Toujours charger les fonctions generer_url_OBJET. Mais les fichiers urls/*.php ont en fait une double raison d'etre (coder / decoder), c'est pas satisfaisant comme  manière de résoudre le problème.

Multibase, suite de [10183]: les modèles doivent se compiler en communiquant au compilateur la connexion qui les concerne (indiquée par leur boucle englobante, ou par la variable d'URL '''connect'''. Ce dépot corrige le bug pour les balises utilisant explicitement les modèles (#MODELE et #PAGINATION) mais pas encore pour les modèles figurant à l'intérieur de la base de données (genre {{{<doc123|center>}}}). Ce dernier point exige un remaniement de code assez important dans la fonction '''typo'''. A compléter donc.

appliquer aussi le fix MSIE de mister-pixel http://www.mister-pixel.com/#Content__state=is_that_simple

une methode plus moderne pour fixer les png ; evite de prendre 50 hits dans la tete parce qu'on a 50 png ; TODO: refixer les png apres une modif du DOM

Ah la la, les exceptions dans les noms: les critères externe pour la boucle syndic_articles, ''alias syndication'', ne marchaient plus. Pardon Mathieu.

Simplication des URLs propres (suite de [10203] et [10209]). Les marqueurs de types d'URL sont totalement évacués, car en fait ils n'étaient pas inclus dans la chaîne stockée dans la table SQL, on ne gaspille pas de place dans cette table en les évacuant et l'URL est alors plus agréable à lire. On continue en revanche à les retirer dans les URLS demandées au serveur HTTP afin d'assurer le service pour les anciens signets.

Le .htacces est donc simplifié et mérite d'être recopié à partir du htaccess.txt fourni. Le titre général du seul paramètre page qui y figure encore est désormais '''type_urls''' pour avoir un message d'erreur plus clair lorsque la variable homonyme n'a pas été affectée dans mes_options.

Enfin, le couteux '''charger_generer_url''' qui cherche d'abord les anciens fichiers '''.php3''' n'est plus appelé dans ce cadre qu'en dernier recours, les différentes définitions de '''recuperer_parametre_url''' étant remplacées par la famille '''urls_propres_dist urls_html_dist urls_page_dist''' etc, avec le '''charger_fonction''' usuel. Pour ceux qui ont leur '''type_urls''' personnels, la compatibilité est normalement assurée, mais renommer leur  '''recuperer_parametre_url''' leur fera bénéficier de cette amélioration.

Url propres: les marqueurs de type d'URL (- + @ _) n'étant plus nécessaires, réécriture du code pour que leur présence soient conditionnées par un jeu de constantes. En mettant ce qui suit dans '''mes_options''', les marqueurs ne seront plus utilisés:

{{{
define ('_marqueur_rubrique', '');
define ('_marqueur_auteur', '');
define ('_marqueur_breve', '');
define ('_marqueur_site', '');
define ('_marqueur_mot_d', '');
define ('_marqueur_mot_f', '');
}}}

un bug sur le raccourci <code> quand il y a plusieurs sauts de lign consecutifs (cf. test unitaire http://zone.spip.org/trac/spip-zone/changeset/15013)

- un peu plus de padding dans le pied de page (Payet Teddy)

Nouvelles URLs propres. Le système d'URL propres de SPIP avait certaines limitations et reposait sur une implémentation spécifique à MySQL. Puisqu'il était nécessaire de les réécrire pour finaliser le portage de SPIP en PostGres, on en profite pour lever une de leur limitations: SPIP mémorise à présent toutes les URL propres ayant été associéés à un objet depuis sa publication. 

Comme auparavant, une URL propre d'un objet publié est créée le plus souvent lorsque qu'une page qui la référence est visualisée dans l'espace public. Comme auparavant, il est nécessaire qu'un administrateur clique sur "voir en ligne" ou "prévisualiser" pour provoquer un nouveau calcul. En revanche, ce nouveau calcul interviendra systématiquement (plus besoin de dépublier puis republier), et s'il fournit une URL différente, elle n'écrasera pas l'ancienne, mais viendra s'ajouter comme URL la plus récemment introduite. Lors des appels ultérieurs de la fonction de génération d'URL associée, elle sera donc choisi prioritairement. Au cas où une nouvelle modification produit un calcul d'URL retombant sur une ancienne URL propre, la date d'introduction de celle-ci est actualisée afin qu'elle redevienne prioritaire, ce qui permet de respecter la contrainte d'unicité et d'éviter aux indécis de remplir cette table par leurs begaiements.

Ces nouvelles URL profitent du travail pionnier entamé par Toggg sur spip_zonesous le nom d'[http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/urls_libres URLS libres]. L'implémentation en est toutefois différente, afin de satisafaire aux besoins de PostGres. Aussi, elles sont gérées par une table ayant ces valeurs comme clé primaire, ce qui devrait accélérer leur recherche, et permet d'évacuer le dernier verrou spécifique à MySQL.

Remarque: au moment de la mise à jour avec cette nouvelle implémentation, les URLs propre courament dans la base seront recopiées dans la nouvelle table, sans aucune perte.

- des legend en couleur, pour qu'elles ne soient pas bleues-moches sous IE/Win, et sans background :-P

- notes de bas de page plus petites mais pas trop
- pas besoin de font-size pour le code
- indentation

- pas besoin de definir le style de address puisque cette balise n'est pas presente dans les squelettes.
- border: 0; est plus simple a ecrire et on est sur que c'est applique dans IE/Win

-* Deux petits filtres dans la lignée de |reset et |end : |push ajoute un élément à une balise qui est en fait un tableau, èquivalent à array_push et |find qui est un équivalent de in_array (tout ça parce que les fonctions natives de php ne fonctionnait plus)
-* Corrections sur le filtre et la balise #FOREACH, qui avaient eux aussi souffert de la nouvelle balise #ENV.

''Il y a des problèmes avec les index de la table `spip_versions`  La colonne `id_article` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index''

(Philippe Auriol)

Suite de [10189]: id_version était déclaré Unsigned mais MySQL a ramené le négatif à 0 sans rien dire. On passe à bigint pour être certain de ne pas avoir de troncature vu la maniere dont le numero negatif est produit. Par ailleurs, on retire les entrées inachevées.

desole, en [10191] je n voulais pas envoyer tout ca d'un coup, de maniere a pouvoir segmenter les choses...
ce commit revient donc partiellement sur [10039] qui avait introduit des onglets fort peu consensuels (?)
mais aussi des concepts interessants comme le bloc infos en squelette, une ecriture (un peu) plus rationnelle du code de l'espace prive, une reflexion sur le role de divers boutons etc.
J'ai ici retabli tout ce qui avait diverge de maniere un peu trop violente pour moi, et corrige pas mal de petits bugs (les lang_select dans les squelettes, qui faisaient que le bloc statut d'un article s'affichait dans la langue de l'article, par exemple)...
je laisse les onglets dans le code, avec uneconfiguration qu'il faut aller chercher soi-meme ; ca reste un peu trop couteux a mon gout en termes de complexite (double css, doubles definitions a certains endroits dans le code) -- a voir comment on se sort de tout ca.

ajout de commentaires sur spip_style.css et sur habillage.css pour essayer de mieux preciser le role de chaque feuille
j'en profite pour remettre des intertitres centres et gras, similaires dans le prive et le public et plus habituels

#209: Remplacement du verrou MySQL de l'accès concurrent au gestionnaire de versions d'un article, par un verrou SQL géré par SPIP. Méthode

1. on alloue un entrée dans la table des versions, avec un numéro négatif;
2. on s'endort 1 seconde s'il existe une autre entrée négative plus récente
3. au reveil on recommence 2. sauf si 30 secndes se sont écoulées
4. on affecte l'entrée allouée avec le numéro de version definitif

Dans le cas d'une fusion de version, c'est l'ancienne entrée qui est affectée et la nouvelle est retirée. 

Le point 3 correspond à une opération inachevée. On pourrait la retirer.

Dans la série ''le bug était ailleurs que là où c'est difficile'' : en Postgres, False vaut la chaîne "f" qui n'est pas équivalente au False de PHP. 

#209: erreurs dans le simulateur PG du showtable MySQL, en particuleir parce que PG différencie les casses. Du coup on remplace = par ILIKE.

Multibase: #716 ayant prémonitoirement demandé le multi-squelette suggéré dans [10113], le présent dépot (aidé de [10133] et [10138]) le réalise en deux coups de cuillère à Post. A présent, si on appelle une page avec un variable d'URL nommé '''connect''', SPIP considèrera qu'il doit utiliser non pas la base principale, mais celle indiquée par par l'entrée du tableau '''connexions''' indexée par la valeur du paramètre '''connect'''. Rappelons que tout fichier '''config/connect'''X'''.php''' garni l'entrée X du tableau '''connexions'''. Dans cette situation, les boucles des squelettes utilisés pour produire la page seront implicitement préfixées par la connexion demandée: {{{<BOUCLE(T) ...}}} sera vue comme {{{<BOUCLE(X:T) ...}}} quand l'URL comporte {{{&connect=X}}}.

Aspects techniques

La compilation d'un squelette produira autant de fichier dans tmp/cache/skel que d'application à des bases différentes. Il y aurait moyen de faire un plus compact, mais avec une petite chute de performances. On sacrifie donc l'espace au temps, ça ne semble pas un problème vu la taille usuelle d'un squelette compilé.

Les différences entre les compilations d'un même squelettes proviennent des balises #URL_* et assimilées. Il y aura peut-etre une petite réorganisation des fonctions sur les balises et les critères à opérer pour gérer ça plus astucieusement.