Tests avant de faire des define() à la sauvage, ce qui supprime les
causes principales de warning possibles. Il en reste peut-être, mais
du coup on les verra.

On définit 4 constantes qui représentent le pourcentage de qualité à
appliquer lors des traitements d'images :
 - _IMG_QUALITE
 - _IMG_GD_QUALITE (existait deja)
 - _IMG_CONVERT_QUALITE
 - _IMG_IMAGICK_QUALITE

Ainsi, il suffit de surcharger _IMG_QUALITE dans mes_options pour impacter
toutes les valeurs, mais il reste possible de les définir au cas par cas.

La valeur par défaut est 85, sauf pour convert qui utilise historiquement
une qualité de 75. Cette incohérence n'est pas documentée, alors on la
préserve en attendant de savoir si elle est volontaire ou non.

si tester_url_ecrire fait un charger_fonction qui fait une inclusion, alors #URL_ECRIRE dans un squelette provoque des inclusions et des modifications de contexte (ie definition d'une constante en debut de fichier).
On se contente donc de tester le find_in_path() sans inclusion, et sinon on tente un charger_fonction qui va verifier que la fonction est bien la (sans provoquer d'inclusion du coup)

A la demande generale et particuliere, supprimer le prefixe "page-" sur les squelettes Z qui ne sont pas des objets en base.
On choisit donc de ne pas differencier par nommage contenu/accueil et contenu/article par exemple.
Cette distinction avait pour but la possibilite de d'avoir des blocs par defaut pour les pages-xx et d'autres pour les objets editoriaux, mais on peut faire autrement.
On conserve deux squelettes page.html et objet.html a la racine, meme si il font la meme chose en pratique.

Passer le paramètre $rel à true par défaut (génération d'URL relatives)
dans la fonction generer_url_public(), et donc par rebond dans certaines
balises telles que #URL_PAGE. La raison est qu'il est plus facile de
rajouter un filtre |url_absolue que de revenir d'une URL absolue à une
URL relative.

Utiliser _DIR_RACINE pour redescendre d'un niveau quand on appelle
generer_url_public() depuis l'espace privé avec $rel=true.

l'envoi precedent sur tester_url_ecrire etait bien evidemment faux, puisque la fonction doit retourner une info sur l'exec php a executer.
On s'arrete donc au nom qu'on renvoie, charge a l'appelant de faire un charger_fonction() pour avoir le script

lors de la detection de l'existence d'#URL_ECRIRE{xxx} ne pas essayer de charger l'exec si il n'est pas en php, sinon ca declenche son calcul a tort

rangement : les exec qui utilisent une authent FTP par inc/admin et declenchent une action scriptee dans base/xxx s'appellent de preference (et en coherence) exec/base_xxx. A defaut si exec/base_xxx n'existe pas, inc/admin renvoie sur exec/xxx comme avant pour assurer la compatibilite.

On renomme 
- admin_repair en base/repair et exec/base_repair
- delete_all en base/delete_all et exec/base_delete_all
pour s'y retrouver

initialiser a chaque hit la globale $spip_pipelines, qui grossit au fil du temps, a peu d'interet puisque elle n'est vraiment utile que dans inc/plugin lors de la construction des pipelines compiles.
On remplace donc cette declaration globale par la declaration xml dans core.xml. Celu-ci migre depuis prive/ vers ecrire/ puisque c'est le repertoire source d'ou partent les inclusions.
Toutes les fonctions appelees par des pipelines qui etaient dispersees sont regroupees dans deux fichiers inc/pipelines.php et inc/pipelines_ecrire.php

La seule autre utilisation de spip_pipelines concernait la compilation des balises dynamiques lorsqu'un pipeline y etait passe en contexte (CVT). On remplace le test d'existence a cet endroit par un flag dans la fonction pipeline() qui demande d'ignorer silencieucement l'absence du dit pipeline en cas de non existence.

Il reste le cas des declarations || sur le pipeline styliser pour forcer l'appel en queue de pipeline, qui n'est pas couvert par la syntaxe actuelle des plugin.xml. Un point a ajouter dans la DTD en cours de realisation.

Le seul cas que l'on ne couvre plus est la possibilite pour les plugins de surcharger la globale spip_pipeline pour enlever/modifier un appel du core ou d'un autre plugin. Il faudra peut etre ajouter pour cela un pipeline sur la construction des pipelines. On y reviendra si les cas sont vraiment indispensables.

Introduction de styliser_par_z_dist surchargable, qui inclus les mecanismes de ZPIP, actifs pour l'espace prive, activable pour l'espace public par un define('_ZPIP');
la fonction echaffaudable est egalement integree, mais pas la fonction d'echaffaudage. Aucun echaffaudage n'est pour l'instant integre dans l'espace prive

La structure des blocs pour l'espace prive est :
head, barre-nav, hierarchie, navigation, extra, contenu et pied

Structure minimaliste des squelettes, avec une implementation par defaut de chaque bloc. Pour le moment, les squelettes head, barre-nav et pied font appel aux fonctions php pour generer le html comme sur les autres pages, mais il va sans dire qu'a terme on inversera le schema (quelques fonctions sont crees pour atteindre le bon morceau de html, et quelques appels sont rationalises en faisant disparaitre les vieux arguments plus utilises)

La squelettes de l'espace prive sont detectes par la fonction tester_url_ecrire qui aiguille sur exec=fond pour les squelettes Z et exec=fond_monobloc pour les anciens squelettes temporaires mono-fichier balises par des commentaires.

En l'etat, il est possible de creer une page de l'espace prive par un simple squelette contenu/page-xx ou contenu/yyy pour un objet de SPIP (on maintient le distingo entre les deux types de page).

Les plugins pourront le faire de meme, a condition de bien mettre dans un sous dossier prive/squelettes/ du plugin
On integre le modele typo de petronille (merci tetue) et une page-typo pour commencer

objet=syndic -> site
public=1 n'est pas un connect (on n'accepte pas les numerique pur pour connect)

La fonction {{{generer_url_entite}}} ne peut que rendre la chaîne vide si on l'appelle avec un nom d'entité vide à partir de l'espace privé (ce cas ne sert que dans l'espace public pour renvoyer la fonction de passage URL ==> id). Pas la peine de dérouler de longs calculs aboutissant au log inutilement inquiétant {{{generer_url_entite: entite  () inconnue}}}.

Introduction d'un nouveau paramètre de configuration pour indiquer la version de compatibilité HTML à respecter par SPIP.
La valeur peut être 'html4' ou 'html5' (mais si SPIP est encore là dans 10 ans il y en aura peut-être d'autres...).

Ce paramètre est introduit pour fournir un mécanisme de transition douce vers HTML5, utilisable autant par le core que par les plugins, les squelettes, etc.

Pour tester s'il est possible de produire du HTML5, un accesseur booléen est fourni :
- dans les squelettes: balise #HTML5 (renvoyant espace ou chaîne vide)
- dans le code PHP: fonction html5_permis() dans inc/utils

- _chemin()
- liste_plugin_valides()
- ecrire_plugin_actifs()

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]