- déc. 12, 2010
-
-
Fil a rédigé
-
- déc. 09, 2010
-
-
cerdic a rédigé
-
- déc. 08, 2010
-
-
cerdic a rédigé
-
- nov. 16, 2010
-
-
denisb a rédigé
-
- nov. 09, 2010
-
-
cerdic a rédigé
-
- oct. 23, 2010
-
-
cerdic a rédigé
La complexite est liee a la compat ascendante, car les vieilles fonctions manipulaient directement des globales. La fonction urls_decoder_url() de inc/urls gere donc tout cela une fois pour toute, en isolant les globales concernees (sauvegarde/restauration) ce qui permet de l'utiliser partout sans precaution. Un flag $assembler par defaut a false permet de distinguer l'appel principal depuis public/assembler, qui accepter une redirection brutale, et necessite de prendre en compte les globales $_SERVER['REDIRECT_url_propre'] et $_ENV['url_propre'] Celles-ci ne sont plus videes par assembler car elles sont gerees proprement par la fonction urls_decoder_url Il serait neanmoins plus prudent d'evacuer aussi ces arguments implicites au profit d'arguments explicites, pour plus de clarete du code. Si les tests sur form_hidden sont exhaustif, on ne casse rien en passant par cette fonction depuis le filtre form_hidden. Si des cas de bugs sont remontes, il faudra completer les tests avant de corriger la fonction ou le filtre.
-
- oct. 18, 2010
-
-
cerdic a rédigé
lorsque la balise <head> contient des attributs, il faut quand meme etre capable de poser un <base...> en urls arbos report de [16480]
-
- sept. 25, 2010
- sept. 20, 2010
-
-
cerdic a rédigé
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.
-
- sept. 13, 2010
-
-
cerdic a rédigé
-
- août 22, 2010
-
-
b_b a rédigé
-
- mai 19, 2010
-
-
Fil a rédigé
-
- mai 05, 2010
-
-
RastaPopoulos a rédigé
Dans les balises dynamiques, le paramètre de contexte "_pipeline" qui permet de passer le HTML produit dans un pipeline reste le même mais devient déprécié. On ajoute à la place un paramètre "_pipelines" au pluriel, permettant donc de passer *plusieurs* pipelines avec une syntaxe légèrement différente : "_pipelines" est un tableau de clé=>valeur, où chaque clé est le nom du pipeline et la valeur les arguments. C'est particulièrement utile depuis CVT. En effet, un plugin peut s'insérer dans le charger() d'un formulaire ayant *déjà* un pipeline de déclaré pour son HTML. Et du coup il ne pourra pas lui-même le faire passer dans un pipeline qui lui serait propre. Maintenant on peut. Ça marche en 2.2 et en 2.1. Là je ne commit que sur le trunk pour l'instant, mais comme ce n'est pas une nouvelle fonctionnalité je demanderais bien un backport. Qu'en pensez-vous ?
-
- mars 17, 2010
-
-
cerdic a rédigé
Report de [14590] [15492] [15494] [15495] [15496] [15497] [15498] [15499] [15500] [15502] [15503] [15505]
-
- mars 13, 2010
- jan. 30, 2010
-
-
cerdic a rédigé
#1849 : plus de fix pour msie qui a deja trop abuse des substances interdites (plus de wrapper.php non plus d'ailleurs)
-
- jan. 04, 2010
- déc. 23, 2009
-
-
esj a rédigé
Correction pour les modèles distants: [12528], en attaquant la problématique du paramètre conditionnel {{{lang}}} dans une balise {{{#INCLURE}}} avait malencontreusement éliminé le paramètre {{{connect}}} dans l'inclusion d'un modèle, ce qui empêchait les modèles sur docuemnts distants d'être pris en compte comme il faut. Quant à [12758], il a simplifié le code sans se demander si cette simplification n'était pas l'indice de quelque chose de perdu. Seize mois plus tard, quelqu'un finit par s'en apercevoir. Merci Maïeul.
-
- oct. 31, 2009
-
-
cerdic a rédigé
introduire une fonction public_produire_page_dist chargee de la production de $page et de la mise en cache si necessaire Cette fonction peut etre surchargee pour personaliser la strategie de gestion du cache, et en particulier renvoyer le contenu du cache et lancer un calcul differe si possible
-
- sept. 03, 2009
-
-
esj a rédigé
Plutôt que de produire dans le code des appels à {{{lang_select}}} qui souvent ne servent pas car {{{recuperer_fond}}} en fait un aussi au départ, communiquer à celle-ci la langue désirée par la balise dynamique, ça supprime un couple d'appel à {{{lang_select}}}. Puisqu'en fait on dispose de tout le contexte de compil lors de la production du l'appel d'une balise dynamique, autant l'envoyer à {{{recuperer_fond}}}, qui pourra ainsi fournir la localisation de l'éventuelle erreur à l'inclusion. -
esj a rédigé
La mention que la variable {{{$contexte_inclus}}} était provisoirement globale pour le débusqueur n'a que trop duré. Cette variable globale n'a aucun intérêt dans le noyau, on supprimer donc cette déclaration mais aussi la production de cette variable intermédiaire qui alourdit le code sans raison. Par ailleurs, à supposer qu'il soit toujours utile de contrôler l'index {{{fond}}} d'un contexte d'inclusion, ce n'est pas la peine de le faire dans {{{inclure_balise_dynamique}}} puisque {{{inclure_page}}} s'en charge. -
esj a rédigé
Tant qu'à virer les vieux flag_* (cf [14451]), cette occurrence de flag_ob est d'autant plus inutile, que public.php ne prend même pas la précaution.
-
- sept. 02, 2009
-
-
cerdic a rédigé
- la fonction nettoyer_url_page renvoie un arg de plus qui est la suite de l'url (pour factorisation avec propre et arbo) - il faut purger les $_SERVER[REDIRECT_url_propre] et $_ENV[url_propre] apres usage sur l'url principale car sinon elles viennent interferer le decodage ulterieur d'urls autres
-
cerdic a rédigé
Retour sur le filtre form_hidden: l'amelioration [13946] de [13939] corrigee par [14444] etait insatisfaisante : il fallait ameliorer la production du contexte dans les types_urls cryptiques: avoir des input name='article884' n'etait pas satisfaisant. Pour ce faire, on complete l'api des fonctions d'url avec l'utilisation du 3eme argument $args pour fournir le contexte lors du decodage d'une url (peut etre fourni sous forme de tableau ou de chaine de get) Les fonctions urls ne font donc plus d'appel direct a la globale $contexte, et peuvent donc etre de nouveau utilise par le filtre form_hidden sur tout type d'url.
-
- août 11, 2009
-
-
esj a rédigé
Bon, il y avait tout ce qu'il faut pour gérer les notes proprement, mais un bout seulement dans plein d'endroits différents, jamais le même. Donc, on enrichit 'l'interface de la fonction surchargeable inc_notes_dist, qui sait empiler et dépiler les contextes à la demande, sans en oublier. Le test unitaire donne la mêmeche qu'en 2.0 (mais n'est pas à jour lui-même).
-
esj a rédigé
Retrait du dernier cas où le fond était passé dans le contexte. Ce paramètre d'URL est donc maintenant comme les autres.
-
- août 10, 2009
-
-
esj a rédigé
Déport des messages 'Il n'y a pas de ''entité'' à cette adresse' dans les squelettes canoniques, le compilateur n'est plus en mesure de les produire à bon escient.
-
esj a rédigé
Effet imprévu de la réorg de [14366]: SPIP distingue maintenant une page vide rendue par un squelette correct ou absent (404) d'un squelette présent mais incompilable (503). En fait, il y a des erreurs où ça donne quand même 404, suite aux besoins du déb usqueur, c'est encore à améliorer.
-
esj a rédigé
Pb 42 (eh oui il en restait un après [11490]) avec [9649] (la disparition du FEED_GLOBALS): en cas d'erreur 404, on ne donnait plus la précision: aucun_article / aucune_rubrique etc quand elle était disponible.
-
- août 09, 2009
-
-
esj a rédigé
Lors d'une inclusion par {{{#INCLURE}}}, le débusqueur donne à présent le squelette incluant et le numéro de ligne où cette balise utilise le fond fautif. Particulièrement utile lorsque plusieurs {{{#INCLURE}}} sont susceptibles d'être responsable de l'erreur. Pour parvenir à ça, il a fallu retarder la dénonciation de squelette inconnu, qui n'est plus assurée par public_styliser mais par récuperer_fond. Il s'ensuit que les fonctions public_parametrer et evaluer_fond (sur le trajet entre les deux fonctions susnommées) voient la spécification de leur résultat légèrement changer. Elles retournent: * False si le squellette existe mais a provoqué des erreurs de compilation (déjà signalées au moment de retourner le résultat); * la chaîne vide si le squelette est inconnu (et aucune erreur n'est encore signalée); * la page attendue si tout s'est bien passé (rien de changé ici). Dans le deuxième cas, la fonction recuperer_fond regarde si son troisième argument (les options) contient un index nommé 'compil', qui lui sert alors à localiser l'erreur. Pour l'instant seul {{{#INCLURE}}} fournit cette information. Affaire à suivre.
-
- juin 24, 2009
-
-
cerdic a rédigé
-
- juin 15, 2009
-
-
esj a rédigé
-
- juin 14, 2009
-
-
esj a rédigé
Centralisation du nom de l'extension des squelettes (y compris les modèles) dans la constante _EXTENSION_SQUELETTES, plutôt que d'avoir '.html' à tous les coins de rue.
-
- avr. 11, 2009
-
-
Fil a rédigé
-
- fév. 25, 2009
-
-
Fil a rédigé
-
- fév. 18, 2009
-
-
Fil a rédigé
debug et complement pour l'API d'urls : separer la detection du type et la modification du fond ; permet de respecter un ?page=xxx indique dans le .htaccess ; au passage on se debarrasse enfin de l'affreux ?page=type_urls (mais compat ascendante assuree)
-
