MAJ 2.6 problème chez Gandi Simple Hosting
by Patrick Olivier
Salut,
On dirait que le problème est revenu :
Une erreur est survenue durant la mise à jour automatique : Can't create
table 'dotclear.#sql-33_7d2b' (errno: 121) (1005)
Je corrigerai ça manuellement ce soir…
--
Patrick
10 years, 5 months
Build de la 2.6 - tests clearbricks
by Bruno
Hello,
Apparemment le script de build n'exclut pasdu zip les tests unitaires
clearbricks (inc/libs/clearbricks/tests, et les composer* et atoum* à la
racine de clearbricks). Il faudra peut-être l'enlever à la mano pour la
2.6, en attendant :)
--
Bruno
10 years, 5 months
CR de la réunion IRC du 12/11
by Bruno
21:00 : début de la réunion
== Revue des tickets de la 2.6 ==
RAS
== Sortie de la 2.6 ==
Demain matin, il faut soudoyer le chef de Franck pour qu'il ait le temps de
le faire
En attendant, le hg est gelé, pas touche!
== Tickets de la 2.7 aka démarrage de la foire à l'empoigne ==
# Discussion sur les templates par défaut
Plusieurs thèmes :
* proposer plusieurs jeux (dont l'actuel)
* intégrer les mécanismes d'héritage entre templates
* ne pas casser les thèmes actuels
Ticket #1216 (bibi) : le nom "legacy" convient à la majorité pour le
templateset par défaut
# Problèmes de versions jquery
Problématique : gérer les version de jquery entre les thèmes et les plugins
: lequel charger ?
blowup propose actuellement la 1.4.2, jquery est disponible en 1.9/1.10
voire 2.0
* nikrou propose de passer en 1.10.2 pour la 2.7 avec éventuellement le
plugin de migration
* mega a remis la main sur son tutu en béton armé, et propose de recoder
dotclear en JSP
* Beaucoup de monde est réticent à autoriser le chargement de 2 versions de
jquery (via noconflict) : dans tous les cas, difficile à appliquer, peut
imposer de modifier les plugins (dans ce cas, autant les rendre compatibles
1.10 directement)
* lipki propose de passer d'emblée à jquery 2, qui ne supporte plus IE6/7/8
Conclusion provisoire : difficile de passer autrement que par l'imposition
de jquery >= 1.10 et rester vigilant sur les incompatibilités engendrées.
22:03 Beu² arrive, et on revient aux débuts de linuxfr, la tribune, les
c01n², multideskos, windowmaker et j'en passe. Anne a du mal a recentrer le
sujet. Je propose de mettre en place les tickets #1216 et #1217 pour la fin
de semaine prochaine.
Tomek constate qu'une màj de dotclear 2.3.1 vers 2.6 fonctionne encore chez
free, malgré son dinosaure PHP 5.1.3RC4.
10 years, 5 months
[dev][2.7]Brainstorming versioning des templates
by Bruno
Yo,
J'alimente le moulin coté devs sur le versioning des templates du core.
En l'état, c'est assez simple à mettre en oeuvre : presque tout est dans
inc/public/prepend.php : ce dernier fixe le chemin tpl par défaut , par
ordre de priorité décroissante à :
* chemin du thème / tpl
* inc/public/default-templates
Il suffit donc de changer le dernier par celui qui serait défini dans le
_define.php du template (et voir les cas particuliers pour les héritages
entre thèmes), en prenant inc/public/default-templates par défaut si non
défini.
Je propose qu'on déplace les templates par défaut actuels dans
inc/public/default-templates/<nouveaunom>, et qu'on crée alors les autres
templates par défaut dans des répertoires à coté.
Reste maintenant à trouver le nom du futur-ancien jeu de templates, et
celui du/des prochains :)
Coté thème, je propose d'ajouter la propriété "tplset" qui contiendra
uniquement le nom du jeu de templates hérité.
--
Bruno
10 years, 5 months
[dev][2.7]Fwd: Héritage de templates suite
by Bruno
Dans la série "je déterre le sujets", pouf information les échanges évoqués
par Anne. :)
---------- Message transféré ----------
De : Dsls <dsls(a)morefnu.org>
Date : 28 juin 2011 13:06
Objet : Héritage de templates suite
À : Dotclear Bazar <bazar(a)list.dotclear.net>
Je reprends depuis le début. Oubliez le thème blowupRevisited tel que
je l'ai proposé, c'était une erreur d'approche de ma part, j'aurais du
discuter sur le fond avant de montrer la forme.
On commence par les thèmes actuels, et comment les thémeurs les réalisent :
1. On crée un fichier de layout global, dont on extrait un _top, un
_footer, un _head, une éventuelle sidebar
2. On crée à partir de ces éléments un home.html, intégrant les
fichiers ci-dessus
3. On duplique home.html en category.html, qu'on adapte un peu
4. On duplique home.html en tags.html, qu'on adapte un peu
5. On duplique home.html en search.html, qu'on adapte un peu
...
153. On duplique home.html en post.html, dont on enlève la boucle, on
adapte un peu plus
153. On duplique post.html en page.html, qu'on n'adapte presque pas
154. On duplique home.html en 404.html, tags.html et autres fichiers
spécifiques, on enlève la boucle qu'on remplace par le contenu qu'on
souhaite
Maintenant, je veux ajouter une class au div content ? J'adapte
home.html, puis category.html, puis tag.html, puis ...
Je trouve ça très con. 90% du même code html se retrouve dans tous les
fichiers template. Qu'on ajoute des include ou pas, le squelette de la
page apparaît dans chaque template.
Alors que, une page, c'est dans l'ordre:
1. Un squelette, définissant ou on va mettre le contenu (listes,
billet, tags, ...), et les gadgets autour (widgets, top, header,
footer, liens, ...)
2. un contenu, type liste d'éléments dans la zone correspondante du
squelette
3. un contenu, type billet dans la zone correspondante du squelette
4. un contenu, type "libre" dans la zone correspondante du squelette
Et je pense que dans cet ordre, c'est globalement ce que font les
designers de thème.
D'où ma proposition :
* On définit un "layout.html" qui présente le squelette de la page
* On définit un "list.html" qui va présenter le squelette des pages
avec pour contenu liste
* On définit un "single.html" qui va présenter le squelette des pages
avec un simple contenu
list.html va dire : "reprends la même chose que layout.html", mais
remplace la zone "contenu" par ça
single.html va dire : "reprends la même chose que layout.html", mais
remplace la zone "contenu" par ça-bis
Ensuite :
* category.html va hériter (puisque c'est vraiment le terme) de
list.html, en décrivant uniquement le contenu qu'elle spécialise
* et de même pour toutes les pages liste
* post.html va hériter de single.html
* ...
Pour définir les zones du squelette, twig utilise la notion de bloc,
que j'avais reprise dans blowupRevisited. Chaque bloc est nommé, il
suffit alors à la page fille de redéfinir le contenu d'un bloc ayant
un nom donné.
--
Bruno
10 years, 5 months
[dev] Ordre du jour de demain, my wishlist
by Kozlika
Salut les gens,
J'imagine que demain on commencera à parler de la 2.7.
J'aimerais que figure à l'ordre du jour le passage au versionning des
templates dans les trucs à faire sans trop tarder. Comme ça on pourrait
enchaîner derrière sur la réflexion et la concrétisation du nouveau jeu de
templates (je parle plus de la mécanique que de la DTD ou des CSS là).
Une discussion s'était engagée là-dessus il y a de longs mois, il y a des
pistes (Bruno, Franck et moi avions lancé des idées, notamment, différentes
mais pas contradictoires). Si on veut que ce soit dans la 2.7 il va falloir
ne pas trop traîner à faire avancer ce sujet.
J'ai mis un embryon ici
http://fr.dotclear.org/documentation/brainstorming/nouveau-jeu-de-templates
--
Anne / Kozlika
10 years, 5 months
Aides contextuelles, on fait le point
by Kozlika
Plop.
Il reste des pages à faire, d'autres où quelqu'un a dit "je prends" mais ne
les a pas encore faites.
Qui a des pages sur le feu, qui ne pourra finalement pas s'occuper des
pages qu'il avait "réservées", qui veut bien en prendre ?
(Objectif : sortie RC dans le week-end)
--
Anne / Kozlika
10 years, 5 months
