Piwigo.org

nicolas · 2006-04-21 10:11:10

rvelices a écrit:
Moi j'en ai 3 dans la vue calendrier mensuel (le "joli" tableau). 1 je sais comment corriger (il manque <tr>). Pour les 2 autres:
- <table align="xxx" - c'est quoi la regle pour remplacer ca ? il faut mettre la table dans un div ?

il faut utiliser une classe particulière soit pour ce cas, soit générique du genre:

Code:

.left {
   text-align: left;
}

rvelices a écrit:
- <style> non permis dans body - je devrais tout mettre inline ?

Il faut que tu modifies la feuille de style css pour y ajouter les styles que tu as défini. Il faut éviter aussi d'utiliser des styles inline (attribut style) et plutôt définir un style.

VDigital · 2006-04-21 11:40:24

nicolas a écrit:
rvelices a écrit:
Moi j'en ai 3 dans la vue calendrier mensuel (le "joli" tableau). 1 je sais comment corriger (il manque <tr>). Pour les 2 autres:
- <table align="xxx" - c'est quoi la regle pour remplacer ca ? il faut mettre la table dans un div ?
il faut utiliser une classe particulière soit pour ce cas, soit générique du genre:
Code:
.left {
   text-align: left;
}

Ce qui est assez rarement utilisé au niveau de <table class="left">
mais par contre <td class="left">
8-)

nicolas a écrit:
rvelices a écrit:
- <style> non permis dans body - je devrais tout mettre inline ?
Il faut que tu modifies la feuille de style css pour y ajouter les styles que tu as défini. Il faut éviter aussi d'utiliser des styles inline (attribut style) et plutôt définir un style.

style= ne devrait jamais être utilisé (en tout cas pas sur <body>.

Sur les autres balises, il peut l'être pour faire par exemple:
<form id="xyz" {optstyle}>
et par defaut optstyle = '';
sauf si la $conf par exemple incite à ne pas proposer la form et dans ce cas
opstyle = 'style="display: none;"';

Je n'ai pas l'impression qu'on utilise pour l'instant cette technique...
8-)

mathiasm · 2006-04-21 14:24:28

mathiasm a écrit:
VDigital a écrit:
mathiasm a écrit:
chez free cette nuit, synchro sans problème de 149 photos en une passe!
Avec ou sans la solution de contournement ? 8-)
Sans. Ma base a déjà été migrée en 5.0.19. Pas d'impact chez moi...
A suivre.

Tiens, elle est passée en 5.0.21-nightly-20060409 d'un coup!

Donc Free en 5.0.21 => si ça corrige le pb référencé dans l'annonce, c'est bien.

VDigital · 2006-04-21 14:50:57

Tu as de la chance moi c'est encore la 5.0.19...

La 5.0.19 comptait encore plus de 130 bugs référencés.
La 5.0.21 compte déjà 31 bug dont 11 en sévérité 2.

Il y a des chance que cela remarche mais... à suivre.
Surtout, vérifier sa version MySQL avant toute chose.

rub · 2006-04-21 15:01:54

VDigital a écrit:
Tu as de la chance moi c'est encore la 5.0.19...

Moi aussi, 5.0.19...
D'habitude, ils mettent combien de temps pour changer la version de MySql sur tous les serveurs?

VDigital · 2006-04-21 15:09:21

Faudrait déjà qu'ils décident de changer tous les serveurs...
Je pense qu'ils testent pour voir si cela marche mieux sur quelques serveurs puis ils doivent cloner les serveurs.
Une question de semaines certainement.

plg · 2006-04-21 15:15:05

Yohan, administrateur chez Free, m'a dit qu'il passait MySQL en version 5.0.20 CVS tous les serveurs (il m'a dit ça hier). Cela dit, plus aucun rapport avec "planning de la release 1.6.0"...

VDigital · 2006-04-21 19:54:39

Bon vu les nouveaux temps de réponse... même en 5.0.19.
Je pense que les tests de la 1.6.0RC1 devraient se dérouler sous les meilleurs hospices.

Merci encore à toi, et à Yohan.

plg · 2006-04-21 22:54:08

La 1.6.0RC1 sera dimanche ou lundi soir.

rub · 2006-04-21 23:07:03

z0rglub a écrit:
La 1.6.0RC1 sera dimanche ou lundi soir.

Ok!
Ca tombe bien car il y a encore pas mal de petit bug qui sont détéctés et corrigés.

Sinon, en parlant de bug, c'est plutot concluant l'utilisation faite de Bugtracker pour préparer la RC. C'est pratique, organisé, etc...

chrisaga · 2006-04-22 10:11:59

rvelices a écrit:
Moi j'en ai 3 dans la vue calendrier mensuel (le "joli" tableau). 1 je sais comment corriger (il manque <tr>). Pour les 2 autres:
- <table align="xxx" - c'est quoi la regle pour remplacer ca ? il faut mettre la table dans un div ?

Pour centrer une table, on lui colle :

Code:

margin-left: auto;
margin-right: auto;

Je vais voir d'ailleurs si l'on ne ferait pas mieux de définir toutes les tables comme ça par défaut.
Il faut aussi utiliser les tables uniquement pour des tableaux (ici, un ça paraît assez justifié) pour des listes et de la mise en page, éviter au max.

rvelices a écrit:
- <style> non permis dans body - je devrais tout mettre inline ?

Jamais !
une fois que les styles sont inline dans le code HTML, on ne peut plus y toucher avec une css
En plus c'est contre le principe de séparation entre le contenu et l'affichage que l'on met en place depuis la 1.5
Il faut donc migrer ça vers une css.

Sauf que là, tu es mal parce que tu calcules le style de façon dynamique, et qu'arrivé là tu n'as plus accès au header.
Jusqu'ici, on avait évité cette technique, tu comprends pourquoi <;o)
Bon faut creuser la question.
C'est défini où {calendar.thumbnails.WIDTH} ?

Dernière modification par chrisaga (2006-04-22 10:16:08)

rvelices · 2006-04-22 16:25:04

Merci pour les infos.

chrisaga a écrit:
C'est défini où {calendar.thumbnails.WIDTH} ?

Dans include/calendar_monthly.class.phpm la derniere fonction build_month_calendar (elle est tres longue)

chrisaga · 2006-04-22 17:30:19

La solution pour l'instant est de faire comme pour la taille max des vignettes et de mettre ça dans template-common/default-layout.css avec un commentaire qui dit que les dimentions doivent-être identique à celles qui sont dans $conf[]
Pas terrible, mais je n'ai pas mieux our l'instant.

Je te laisse faire ...

Chris

mathiasm · 2006-04-22 23:01:42

Une piste:
générer en php un css dédié, qui est relié à la taille théorique des miniatures.
Cette génération aurait lieu à chaque synchronisation des dossiers, puisque c'est à partir de ce moment qu'un changement de taille dans les miniatures a un impact.

Edit: Idéalement, l'inclusion ne serait faite que pour les pages au format calendrier. Mais je ne sais pas comment le détecter.

Dernière modification par mathiasm (2006-04-22 23:02:51)

chrisaga · 2006-04-23 22:53:23

mathiasm a écrit:
Une piste:
générer en php un css dédié, qui est relié à la taille théorique des miniatures.
Cette génération aurait lieu à chaque synchronisation des dossiers, puisque c'est à partir de ce moment qu'un changement de taille dans les miniatures a un impact.

C'est probablement la meilleure piste que nous aillons.

mathiasm a écrit:
Edit: Idéalement, l'inclusion ne serait faite que pour les pages au format calendrier. Mais je ne sais pas comment le détecter.

Pour l'instant nous avons le même header dans tout le site, mais ce n'est pas sigrave que ça puisque les css restent en cache et ne sont chargées que la première fois.

Piwigo.org

Annonce

#46 2006-04-21 10:11:10

Re: Plannig de la release 1.6.0

rvelices a écrit:

Code:

rvelices a écrit:

#47 2006-04-21 11:40:24

Re: Plannig de la release 1.6.0

nicolas a écrit:

rvelices a écrit:

Code:

nicolas a écrit:

rvelices a écrit:

#48 2006-04-21 14:24:28

Re: Plannig de la release 1.6.0

mathiasm a écrit:

VDigital a écrit:

mathiasm a écrit:

#49 2006-04-21 14:50:57

Re: Plannig de la release 1.6.0

#50 2006-04-21 15:01:54

Re: Plannig de la release 1.6.0

VDigital a écrit:

#51 2006-04-21 15:09:21

Re: Plannig de la release 1.6.0

#52 2006-04-21 15:15:05

Re: Plannig de la release 1.6.0

#53 2006-04-21 19:54:39

Re: Plannig de la release 1.6.0

#54 2006-04-21 22:54:08

Re: Plannig de la release 1.6.0

#55 2006-04-21 23:07:03

Re: Plannig de la release 1.6.0

z0rglub a écrit:

#56 2006-04-22 10:11:59

Re: Plannig de la release 1.6.0

rvelices a écrit:

Code:

rvelices a écrit:

#57 2006-04-22 16:25:04

Re: Plannig de la release 1.6.0

chrisaga a écrit:

#58 2006-04-22 17:30:19

Re: Plannig de la release 1.6.0

#59 2006-04-22 23:01:42

Re: Plannig de la release 1.6.0

#60 2006-04-23 22:53:23

Re: Plannig de la release 1.6.0

mathiasm a écrit:

mathiasm a écrit:

Pied de page des forums