- déc. 13, 2010
- déc. 12, 2010
-
-
davux a rédigé
Comme le fait remarquer Cédric, certains plugins ont déjà pris en compte que la dev actuelle s'appellera 2.3 dans leurs dépendances. Si elle sort en 2.2, ils ne seront pas contents. Revenons donc à 2.3 pour la future stable issue du tronc.
-
davux a rédigé
Suite à r16666, la prochaine branche stable sera spip-2.2.
-
salvatore a rédigé
-
salvatore a rédigé
-
salvatore a rédigé
-
Fil a rédigé
-
Fil a rédigé
-
Fil a rédigé
critere {{{ {datasource #ARRAY, table} }}} pour la boucle (DATA). Exemple: {{{ <BOUCLE_y(DATA){datasource #CONFIG**,table}{valeur>0}{cle==version}> }}} -
Fil a rédigé
Boucle POUR: ============ <BOUCLE_x(POUR){tableau=#CONFIG**}{valeur>0}{cle==version}> Boucle DATA: ============ <BOUCLE_r(DATA){datasource http://localhost/spip/?page=backend, rss}> <BOUCLE_r1(DATA){datasource http://localhost/spip/rien.json, json}> <BOUCLE_r2(DATA){datasource http://localhost/spip/rien.yaml, yaml}{pagination 5}> <BOUCLE_r3(DATA){datasource TEST.CSV, csv}{valeur==France}> Boucle ENUM: ============ [(#REM) Echiquier ]<B_z> <table> <BOUCLE_z(ENUM){1,8}> <tr> <BOUCLE_y(ENUM){1,8}> <td> [(#_z:VALEUR|plus{64}|chr)]#VALEUR </td> </BOUCLE_y> </tr> </BOUCLE_z> </table> </B_z> [(#REM) Une pagination qui va jusqu'au max possible ]<B_a> [<p class="pagination">(#PAGINATION)</p>] <BOUCLE_a(ENUM){pagination 10}> #VALEUR </BOUCLE_a>
-
- déc. 11, 2010
-
-
Fil a rédigé
un peu de nettoyage et un debut de boucle POUR definie sous forme d'iterateur ; ce que je ne vois pas encore bien comment structurer, c'est la possibilite d'aller chercher un iterateur dans un plugin
-
Fil a rédigé
-
davux a rédigé
En l'absence d'opposition suite à la proposition[1] faite sur spip-dev, le DOCTYPE de l'espace privé passe à <!DOCTYPE html>. La question de la validité (mais qui ne semblait gêner que moi de toute façon donc ça va) n'en est pas vraiment une, car : - Avec l'ancien DOCTYPE, le code n'était déjà pas totalement valide, ce qui ne semblait contrarier personne, dans la mesure où le rendu était néanmoins correct dans tous les navigateurs. - Pour corriger la validité, il faudrait plutôt corriger le code que revenir à un DOCTYPE antérieur, d'autant plus que les éléments maintenant obsolètes étaient déjà dépréciés avec le DOCTYPE antérieur, donc on n'a aucune excuse. [1] http://permalink.gmane.org/gmane.comp.web.spip.devel/58084
-
- déc. 09, 2010
-
-
cerdic a rédigé
et on delegue a trouver_fond la tache de trouver un fond dans le chemin en prenant en compte son extension. Elle s'enrichit d'un argument optionnel booleen permettant de retourner son resultat sous forme de tableau type pathinfo dont la valeur 'extension' est toujours renseignee (meme en cas d'echec), et dont la valeur 'fond' contient le nom du fichier sans l'extension. Cela permet d'eviter de mettre l'extension en dur dans styliser. Les plugins pourront utiliser cette fonction, et continuer a etre compatible avec les anciennes versions de SPIP simplement en la definissant si elle n'existe pas
-
cerdic a rédigé
-
cerdic a rédigé
-
cerdic a rédigé
-
cerdic a rédigé
La constante _EXTENSION_SQUELETTE qui indique l'extension d'un sauelette avait beaucoup trop d'occurrences dans le code, ce qui ne permet pas facilement de mettre en place une strategie ou plusieurs extensions seraient possibles simultanement. Il n'y a besoin que d'une seule occurrence en fait, dans la fonction {{{trouve_modele}}} sur laquelle toutes les autres se rabattent. Pour le decompilateur, il faut se baseru sur l'extension du fichier de depart pour retrouver l'information, et n'avoir qu'un seul point d'entree poureviter de gerer une valeur par defaut. Pour le debusqueur, on donne le nom du squelette sans l'extension puisque justement il est possible qu'il y ait le choix. -
cerdic a rédigé
-
cerdic a rédigé
-
- déc. 08, 2010
-
-
cerdic a rédigé
Le critere age_redac n'etait pas pris en compte pour une base externe (B. Gugger). En fait c'est plus general que ca, c'est vrai aussi pour le titre implicite. Correctif a tester intensivement
-
cerdic a rédigé
-
cerdic a rédigé
-
cerdic a rédigé
Report de r16556. Le find_in_path pour la DTD locale introduit par r15963 n'etait pas assez general car contraint en amont par le prefixe 'prive' Report de r16558 Accepter dans une DTD un element a contenu totalement vide (meme pas EMPTY explicite). Report r16560. Creer le repertoire de cache des DTD (source et compilee) en debut d'analyse, dans le cas d'une DTD locale qu'on ne recopie pas, l'ecriture du cache echoue s'il n'est pas la (Eric).
-
- déc. 07, 2010
-
-
Fil a rédigé
-
davux a rédigé
En théorie, les balises ins et del peuvent contenir des éléments de type "block", et il faudrait donc couper les paragraphes autour. Cependant : - SPIP ne permet pas vraiment ce genre de cas avec les raccourcis typographiques disponibles (sauf <html>) - Dans la pratique, ces balises ne sont pas souvent utilisées ainsi, même dans des contextes non-SPIP. - Jusqu'à maintenant on ne coupait pas et personne ne s'est plaint, donc continuons ainsi. Par ailleurs, il reste possible de surcharger cette liste via le fichier d'options, si des gens veulent le permettre sur leur site. -
Fil a rédigé
une constante _TEST_EMAIL_DEST afin de pouvoir tester les envois de mail en remplacant tout destinataire par ce contenu (si {{{ define('_TEST_EMAIL_DEST', 'fil@rezo.net') }}} c'est fil qui recoit tous les mails, par exemple mails d'inscription etc ) -
davux a rédigé
Ne pas râler si _BALISES_BLOCS a été surchargé dans le fichier d'options (par exemple parce qu'on a beau comprendre la théorie, on trouve ça naze que ins et del provoquent des coupures de paragraphe).
-
Fil a rédigé
-
davux a rédigé
Ajout des éléments HTML suivants à la mal-nommée liste de balises blocs: - applet - del - ins - iframe À l'instar de button, map, object et script, ces balises ne sont ni de type "inline", ni de type "block", mais ont un comportement mixte: si elle contiennent des balises de type block, elles le deviennent aussi, et ne peuvent donc pas apparaître dans un paragraphe, entre autres. Pour déterminer correctement si le paragraphe doit être coupé, il faudrait donc une fonction d'analyse du HTML plus avancée que des expressions régulières (au hasard, un parseur DOM). En attendant, on n'a pas le choix, il faut couper.
-
