Déplacement des déclarations de bases, autorisations, taches périodiques des disparus, boucles et recherche dans le plugin sites. (http://zone.spip.org/trac/spip-zone/changeset/41117)

Suite au début de migration des mots en plugin (http://zone.spip.org/trac/spip-zone/changeset/41050), on se déleste des fichiers et parties intégrées (telles quelles)

Encore des réécritures pour les alias de tables. Attention, cette version de développement devient très instable, avec bientôt des incompatibilités inévitables pour assurer le portage en Oracle. Sauvegarder vos bases avant toute mise à jour.

Changement d'arguments pour le pipeline "optimiser_base_disparus" qui envoie maintenant les valeurs de durée d'attente et de date de péremption en plus du nombre de suppression.

$n = pipeline('optimiser_base_disparus', array(
			'args'=>array(
				'attente' => $attente,
				'date' => $mydate),
			'data'=>$n
));

Restent :
- les meta de config a deplacer dans le plugin forum
- quelques jointures explicites mais conditionnees a la presence du plugin"

Dépot obtenu par:

{{{
for i in $(grep  -l '(c) 2001-' * */* */*/* 2> /dev/null)
do
sed 's/(c) 2001-2008/(c) 2001-2009/' $i > /tmp/x
mv /tmp/x $i
done
}}}

ce qui la rend extensible et utilisable par les plugins pour tout type d'objet
l'upgrade devrait se faire a partir de la table spip_documents_liens precedente ou des anciennes tables spip_documents_xxx selon le point de depart

le genie de l'optimisation effacait tous les liens de documents, car il tombait sur les documents lies a id_rubrique=0, ce qui lui donnait en fait dans le nouveau modele tous les documents lies a autre chose que des rubriques... etc. Bonne analyse de RealET, et solution mediocre de ma part : je vire cette 'optimisation'

unification de la table de jointure des documents avec 'autre chose', quel qu'il soit ; et affichage des docs de forum dans le contrle_forum

rand() avec deux parametres pour faire plaisir a certains, mais le manuel dit qu'un seul doit suffire - http://news.gmane.org/find-root.php?message_id=%3c47986767.9030602%40hoizey.com%3e

une periode de flou autour de 4h du mat, histoire de ne pas plomber un herbergeur ayant plein de sites spip

Le standard SQL précise qu'une chaîne avec apostrophe se code avec une double apostrophe et non un \ ce que SQLite fait aussi, contrairement à MySQL et PG. 
En prévision des portages utilisant cette réprésentation, l'interface s'enrichit de la fonction {{{sql_quote}}}, qui s'ajoute à celles définies dans [10707] [10667], [10433], [10131], [10146], [10154] et [10113]

{{{
quote => fonction d'abstraction de la citation d'une constante SQL
}}}

Pour MySQL et PG, cette fonction est donc équivalente à {{{_q()}}} qui reste disponible, mais doit être considérée comme obsolète. Le présent dépôt a été obtenu par le script ci-dessous, dont on peut faire usage pour ses extensions personnelles:

{{{
for i in $(grep  -l '_q(' [bigpeau]*/*p)
do
	sed 's/_q(/sql_quote(/g' $i > x
	mv  x $i
done
}}}

Un ajustement manuel a été nécessaire pour le critère "=", le compilateur testant si le code qu'il a produit contient la fonction de citation.

La fonction {{{calcul_mysql_in}}} doit finalement elle aussi être abstraite à cause des valeurs hexadécimales qui peuvent s'y trouver. Pour éviter des problèmes de compatibilité, cette fonction reste sous ce nom dans le coeur de SPIP, mais il faut la considérer comme obsolète et lui préférer:

{{{
in => fonction d'abstraction du test de la présence d'une valeur dans une liste.
}}}
Cette fonction s'ajoute à celles définies dans [10667], [10433], [10131], [10146], [10154] et [10113].

Par ailleurs, les fonctions récemment introduites {{{test_sql_int}}} et {{{test_sql_date}}} se nomment finalement {{{sql_test_int}}} et {{{sql_test_date}}}: bien qu'elles n'abstraient actuellement rien, il est vraisemblable que ce soit le cas lors d'autre portages, on unifie donc tout de suite les nommages.

Ce dépot a remplacé les occurrences de {{{calcul_mysql_in}}} dans {{{ecrire/}} avec:
{{{
for i in $(grep -l calcul_mysql_in [pige]*/*.php)
do 
sed s/calcul_mysql_in/sql_in/g $i > x
mv x $i
done
}}}

Abstraction de l'instruction de destruction de table SQL, grâce à  une nouvelle fonction d'abstraction, qui s'ajoute à celles définies dans [10154][10131][10146][10113] et [10371] (corrigé par [10515]):

{{{
'drop_table' => fonction d'abstraction de la destruction d'une table
}}}

Abstraction de tous les appels {{{ spip_query("DELETE ..... WHERE ... }}} pour que les champs de type Date dans la clause WHERE soient transformé pour Postgres.

Dépot obtenu par: 

{{{
for i in $(grep -l 'spip_query..DELETE FROM' */*php)
do
sed 's/spip_query..DELETE FROM *\([^ \t].*[^[[ \t]\) *WHERE */sql_delete("\1", "/;s/"" \.//' $i > x
mv x $i
done
}}}

et suppression manuelles de qq lourdeurs syntaxiques résultantes.

Encore une amélioration à la gestion du cache des metas: le fichier n'est pas détruit mais seulement anti-daté. Spip le reconstruira lorsqu'il verra qu'il est anti-daté, mais cela permet aux informations considérées comme pérennes d'être accessibles même lorsque la base ne l'est pas pour une raison (panne) ou pour une autre (accès conditionné par la base elle-même). Cette stratégie tempère le défaut d'un cache qui ne fait pas dans le détail des meta (on n'est pas au niveau du Hard, faut faire avec) et pourrait encore être améliorée: les appels de lire_meta() provoquent une relecture complète SQL, c'est excessif (quelques uns sont éliminés avec ce dépot).

Le fichier inc/meta étant à présent systématiquement chargé dans inc/utils, toutes ses inclusions disparaissent, ainsi que deux appels à l'antique lire_meta().

Plutot que d'espérer qu'on n'oubliera jamais d'appeler ecrire_metas après un appel de ecrire_meta ou effacer_meta il est beaucoup plus sûr et efficace de détruire le fichier de cache dans ces deux fonctions: le script en cours n'a plus besoin de ce fichier ni de relire tout la table SQL, et encore moins de faire tout ça plusieurs fois s'il y a plusieurs appels a ecrire_metas au cours de son exécution. C'est le prochain script exécuté qui recréera ce fichier à l'entrée de inc/utils (et en cas d'installation il ne faut meme pas chercher à le créer).

Toutes les occurrences de ecrire_metas ont été retirées, et elle passe en vieilles_def comme ne faisant rien. Pour les quelques occurrences où ecrire_metas n'était pas explicitement précédée de ecrire_meta ou effacer_meta, son ancienne définition a été insérée, mais je doute que cela soit utile.

#209: PG n'a pas d'instruction OPTIMIZE, on neutralise cette tâche dans son cas. Du coup, introduction de l'index type dans le tableau décrivant la connexion afin de connaître le type du serveur à tout moment.

SPIP peut à présent se connecter à plusieurs serveurs SQL (MySQL ou PG) en utilisant systématiquement la fonction '''spip_connect_db''' appelée dans le fichier créé à l'installation, qu'il s'agisse de la base principale (contenant notamment la table des auteurs) ou d'autres bases, gérées par SPIP ou non. Un des intérêts de cette nouvelle interface est qu'il suffit de copier le fichier '''connect.php''' d'un site A dans le répertoire '''config''' d'un site B, en lui donnant le nom '''connect'''A'''.php''' pour que le site B ait accès aux tables du site A, en utilisant dans les squelettes de B la forme
{{{<BOUCLE(A:T)...}}}.

Cette possibilité appelle quelques remarques.

* dans le cas de sites dont on gére soi-même la mutusalisation des sources, il est alors opportun de prendre un seul répertoire '''config''' commun à tous les sites A B ... et de changer le nom du fichier de connexion (indiqué par la constante '''_FILE_CONNECT'''') en '''connnect'''A'''.php''', '''connnect'''B'''.php''' ... pour que l'installation d'un site suffise à en faire une base secondaire des autres, sans plus avoir besoin de copier ces fichiers.

* dans le cas de sites distants, le multi-base est possibile si le serveur SQL du site secondaire accepte les connexions du serveur Http du site principal, ce qu'en général les hébergeurs ne font pas spontanément. S'ils en sont d'accord,  il faudra veiller à mettre dans la copie du fichier de connexion l'adresse IP effective du serveur SQL, pas '''localhost''' ou '''127.0.0.1''' comme c'est souvent le cas dans l'original du fichier.

* rien n'indique si une base secondaire est gérée par SPIP ou non, aussi la compilation de squelettes contenant des {{{<BOUCLE(A:T)...}}} ne bénéficie pas des abréviations usuelles du site principal: il faut écrire le préfixe de table (donc {{{A:spip_articles}}} et pas {{{A:ARTICLES}}}), les jointures implicites ne fonctionneront pas (pas de critère '''id_article''' dans une boucle de documents etc) et autres facilités ('''id_secteur''' pour '''id_rubrique''' dans une boucle de brèves, les boucles SITES et HIERARCHIE ne seront pas comprises etc). On peut envisager un nouveau travail sur le compilateur de squelettes pour prendre en compte le cas, voire permettre la compilation d'un squelette local avec une directive générale indiquant que les tables concernées sont ailleurs. L'usage dira ce qu'il sera opportun de développer.

* la mise en oeuvre du multi-base telle que décrite sur [http://www.spip-contrib.net/MultiBase spip-contrib] est obsolète. Cette interface (qui remontait en fait à SPIP 1.8) obligeait à écrire plusieurs copies des mêmes fonctions (dans le cas d'un même serveur), mettait les identifants de connexion dans un répertoire non protégé par un Htacces (pas catastrophique, mais tout de même peu prudent) et obligeait à programmer soi-même la connexion à la base secondaire.

''Compatibilité'': pour ceux qui n'utilisaient ni les préfixes de tables, ni les connexions multiples, cette nouvelle interface sera transparente, sans nécessité de réinstallation. Pour les sites où le préfixe de table est égal au nom de la base également. Pour d'autres utilisations du préfixe de table, détruire le fichier '''connect.php''' et réinstaller. Pour les sites utilisant le multi-bases ancienne manière, lire ce qui suit.

Afin de permettre plusieurs connexions simultanément, les globales '''$table_prefixe, $spip_mysql_db, $spip_mysql_link, $db_ok''' perdent leurs rôles. Une nouvelle globale '''$connexions''' est introduite. C'est un tableau indexé par des noms conventionnels désignant les bases (noms qu'on utilisera dans les boucles des squelettes et comme suffixe du fichier '''connect''' correspondant), la base principale étant à l'index 0. Chacune des entrées de ces tableaux est elle-même un tableau ainsi formé:
{{{
	'db' => nom de la base SQL
	'prefixe' => préfixe des tables dans cette base
	'link' => Ressource indiquant la connexion persistance
	'count' => fonction d'abstraction du comptage de lignes dans 
	'countsel' => fonction d'abstraction pour l'opération COUNT(*)
	'create' => fonction d'abstraction pour la création de table
	'delete' => fonction d'abstraction pour la destruction de lignes
	'errno' =>  fonction d'abstraction pour le numéro d'erreur
	'error' =>  fonction d'abstraction pour le message d'erreur
	'fetch' =>  fonction d'abstraction pour l'extractation
	'fetsel' => fonction d'abstraction pour sélection puis extractation
	'free' => fonction d'abstraction pour la libération
	'insert' => fonction d'abstraction pour l'insertion
	'listdbs' => fonction d'abstraction pour lister les bases accessibles
	'multi' => fonction d'abstraction pour la balise multi
	'query' => fonction d'abstraction pour requête SQL standard
	'replace' => fonction d'abstraction pour remplacement
	'select' => fonction d'abstraction pour la sélection
	'selectdb' => fonction d'abstraction pour choisir une base
	'showtable' => fonction d'abstraction pour décrire une table
	'update' => fonction d'abstraction pour modifier une ligne
	'updateq' => idem, avec valeurs brutes (apostrophes rajoutés au besoin)
}}}
Ainsi, '''$GLOBALS['connexions'][0]['prefixe']''' est l'équivalent de l'ancien '''$table_prefix'''.

La fonction '''spip_connect_db''' admet à présent un argument supplémentaire, le préfixe des tables dans la base, qui par défaut est pris égal à la base. Elle est invoquée à l'installation et dans le fichier '''connect.php''' qui passe pour cette raison en version 0.6. Les fonctions '''spip_query''' et '''spip_connect''' conservent leur signatures, mais réalisent un travail figurant auparavant dans ''base_db_mysql_dist''' qu'il n'est ainsi plus nécessaire de recopier. A l'inverse, la fonction '''abstract_sql''' délègue la connexion à '''spip_connect''', ce qui impose de renommer les éventuels fichiers '''inc-connect'''X'''.php''' présents dans '''SPIP_PATH''' en '''connect'''X'''.php''' dans '''config''', mais l'essentiel de leur contenu (clône du fichier db_mysql.php) est à remplacer par un appel de '''spip_connect_db''', indiquant notamment le type du serveur (MySQL ou PG actuellement) le tableau ci-dessus dispensant de redonner ces fonctions.

En rendant surchargeable dans [9890] la fonction '''spip_cron''' avec reprise du nom '''cron''' (à l'étymologie incompréhensible d'ailleurs) j'ai introduit une confusion entre la fonction '''cron''' et la fonction '''inc_cron'''. Depuis le temps que je dis que l'anglais ''daemon'' se traduit par ''génie'' (qui exauce les souhaits) et pas par ''démon'' (traduction de l'anglais ''demon''), c'est le moment! La vieille '''spip_cron''' est donc finalement remplacée par '''charger_fonction('genie', 'inc')''', le répertoire '''cron''' introduit en [9894] est renommé '''genie''', et les fonctions qui s'y trouvent sont donc préfixées par '''genie'''. On appréciera en particulier le génie du ma''i''l.

Renommage de toutes les fonctions '''spip_abstract_''' en '''sql_''', c'est plus court et plus parlant puisqu'il s'agit des fonctions d'interfaces avec un serveur SQL. De nouveau attention il faut vider le cache (en fait seulement celui des squelettes: tmp/cache/skel) car ce sont des fonctions que le compilateur place dans le code compilé.

En conséquence, l'annonce de [9852] est modifiée: '''spip_fetch_array''' est remplacée par '''sql_fetch'''. Rien de modifié en revanche en ce qui concerne le fait que spip_fetch_array avec un deuxième argument égal à SPIP_NUM n'a pas d'équivalent et doit être réécrit si on éviter le recours à vieilles_def.php.

Dépot obtenu par le script suivant:
{{{
grep  -v '// http://doc.spip.org/@spip_abstract_' base/abstract_sql.php > b
mv b base/abstract_sql.php 

for i in $(grep -l "spip_abstract_" */*p|grep -v vieilles_def)
do
sed "s/spip_abstract_/sql_/g" $i > x; mv  x $i
done
}}}

et intervention manuelle sur vieilles_def.php.

Permettre la surcharge des fonctions appelées par '''cron'''. Création d'un répertoire '''cron''' accueillant les fonctions '''cron_*''' dont le nom se terminent maintenant par '''_dist''' et sont définies dans le fichier homonyme. La fonction '''cron''' accepte un argument supplémentaire décrivant le tableau des tâches, transmis à '''inc_cron''', ce qui permet de reconfigurer ponctuellement l'ordonnancement des tâches en profitant des verrouillages.

#209: Afin que les plugins utilisant '''SPIP_NUM''' ou '''SPIP_ASSOC''' dans les appels de '''spip_fetch_array''' continuent à fonctionner sans perturber le portage en PostGres, cette fonction passe en vieille_def avec une définition appellant explicitement '''mysql_fetch_array'''. Elle est remplacée dans tout le code de SPIP par '''spip_abstract_fetch''' auparavant utilisée seulement par le compilateur de squelettes. Les plugins voulant tourner en PostGres à terme sont invités à renommer cette fonction, et à ramener à un seul argument tous ses appels.

Ce dépot résulte donc du retrait des deux définitions de '''spip_fetch_array''' présentes dans source:spip/ecrire/base/db_mysql.php et source:spip/ecrire/base/db_pg.php (qui peuvent donc être chargés simultanément à présent si nécessaire) et de l'application du script suivant dans le répertoire '''ecrire''':

{{{
for i in $(grep -l spip_fetch_array */*p|grep -v vieilles_def)
do 
sed s/spip_fetch_array/spip_abstract_fetch/g $i > x
mv  x $i
done    
}}}

Réécriture de l'optimisation des tables, pour supprimer les occurrences de SPIP_ASSOC. En définitive, il s'est avéré que les requêtes d'optimisation n'étaient pas optimsées, d'où réécriture importante. Ce serait encore plus optimal en MySQL >= 4, mais pour respecter la compatbilité MySQL3 on s'est contenté de contruire un DELETE avec IN, chaque élément du IN pouvant en supprimer plusieurs (construction admise par MySQL3.23,49 testée). 

A noter qu'en MySQL => 5 et en PG tout ce code PHP pourrait etre remplacé par une cascade.

* introduction de {{{define('_RENOUVELLE_ALEA', 3600 << 2);}}} qui détermine la validité de l'alea pour les cookie, avec conséquence automatique sur l'option "rester connecter qq jours". A n'allonger que dans des contextes où la sécurité est assurée par des voies externes mais encore plus fiables.

* migration du code en ligne danc inc/meta dans la fonction spip_initialisation de inc/utils: c'est donc cette dernière qui garantit que les meta ont été lues et l'alea est valide (sauf grosse acrobatie dans mes_options, ce changement devrait etre transparent).

* révision générale des include(inc/meta), qui n'interviennent plus que si les fonctions lire_meta, ecrire_meta ou ecrire_metas sont nécessaires dans le code qui suit.