z0rglub a écrit:
Désolé de répondre avec du retard, mais cette semaine, j'ai très très peu de temps disponible malheureusement.
Desole aussi pour me depecher avec mon commit ...
pour 2 et 3 => l'interet pour moi d'utiliser le nom du fichier est de pouvoir mettre des liens externes simples vers les images sans avoir a chercher l'id de l'image. La raison du .htm a la fin = il est necessaire si on a des noms des fichier numeriques. De toute maniere ce n'est pas le comportement par defaut (mais le code du decodage de l'URL est toujours la).
Ca me fait penser: au nom de la categorie: on laisse toujours /category/123 ou on peut mettre qq chose comme /category/123-vacances ? Ou vacances est le nom de la categorie avec tous les characteres non alphanumeriques transformes en - ou _.
Nickel :-) tu rajoutes un $conf['question_mark_in_url'] = true par défaut ?
Ca sera fait. J'attendais juste la valeur par defaut :-)
Désolé de répondre avec du retard, mais cette semaine, j'ai très très peu de temps disponible malheureusement.
rvelices a écrit:
1. utilisation de la fonction picture_url dans category_default.inc.php (si tu ne l'as encore fait)
Je l'avais fait mais pas commité, donc conflit avec ton commit, mais c'est pas grave :-)
rvelices a écrit:
2. deplacer image_id a la fin de l'url
Alors là, nos opinions divergent. L'important sur picture.php, c'est l'image_id, pas la section. La section ne sert qu'à savoir quels seront les éléments précédent et suivant. Je vois que tu as fait la modif, alors on va la laisser, si d'autres personnes pouvaient donner leur avis, ça nous départagerait.
rvelices a écrit:
3. preparation de code pour pouvoir utiliser le nom de fichier de l'image dans l'url. Par exemple: si image_id=5266 et nom fichier DSC_2345.jpg alors on peut facilement avoir /category/123/5266, /category/123/5266-DSC_2345.htm ou /category/123/DSC_2345.htm. Par defaut on a le premier cas.
Tu l'as également commité. Très clairement, je ne trouve pas cela intéressant personnellement, le nom du fichier. De plus, la présence du ".html" à la fin de l'URL n'a absolument aucun intérêt. En quoi ça intéresse les internautes la technologie utilisée par le site pour afficher les photos ? J'aurai plutôt vue quelque chose du type $image_id.'-'.convert2ascii($image_name). Le convert2ascii étant une fonction à développer, notamment pour la classification par tag sur laquelle je travaille en ce moment.
De même que pour l'opinion précédente, c'est sujet à discussion évidemment.
rvelices a écrit:
4. preparation du code pour pouvoir virer le ? dans l'url. Trois choses a faire: [...]
Nickel :-) tu rajoutes un $conf['question_mark_in_url'] = true par défaut ?
mathiasm a écrit:
Dans le section_init.inc.php, plusieurs questions sur le codage pour pierrick:
- Pour le test du premier token, pourquoi des if else enchainés plutot qu'unCode:
switch ($tokens[$next_token]), qui me parait plus clair. Problème de performance?
Pour la souplesse. Avec switch, je ne peux tester que des chaînes complètes. Avec if, je peux vérifier que la section commence avec "cat", cela pourra donc être "categories" ou "category". C'est moins performant a priori.
mathiasm a écrit:
- De même, ligne 188, le for sans fin; pourquoi pas un
Code:
while (isset($tokens[$i]))
Parce que j'ai commencé à écrire un for et j'ai changé des trucs et je me suis pas rendu compte qu'au final, ça revenait à écrire un while ! Merci de l'avoir fait remarqué.
rvelices a écrit:
Theoriquement c'est possible. En fait c'est automatique si avant d'appeler les fonctions make_xxx_url, t'ecrases la variable $page['root_path'] (par defaut ca sera un chemin relatif) avec le host et cookie_path (il est preferable d'utiliser cookie_path a la place de php_self car php_self ne sera pas toujours ce que tu vois dans ton navigateur).
C'est possible de rajouter ces fonctions dans vos dev en cours?
rub a écrit:
Est-ce que en même temps, on peut définir ces mêmes fonctions, non pas avec un chemin relatif mais avec le chemin complet. Ceci afin de l'utiliser dans des fonctions externes (comme par exemple des liens dans le mail de notification)? Il faut bien sur, ne pas utiliser $conf['gallery_url'] qui permet d'avoir simplement un point d'accés au site (et peut être différent du chemin réel physique) mais en utilisant une fonction du style:
Code:
function get_complete_root() { $host = $_SERVER['HTTP_HOST']; $page = $_SERVER['PHP_SELF']; $address = "http://$host$page"; return dirname($address); }
Theoriquement c'est possible. En fait c'est automatique si avant d'appeler les fonctions make_xxx_url, t'ecrases la variable $page['root_path'] (par defaut ca sera un chemin relatif) avec le host et cookie_path (il est preferable d'utiliser cookie_path a la place de php_self car php_self ne sera pas toujours ce que tu vois dans ton navigateur).
Merci rvelices.
Je viens de relire un peu le topic et j'ai un peu mieux compris la ré-ecriture des url. ;-)
Pour les autres url (ceux qu'on trouve dans admin ou les helps, etc...). Il faudra donc utiliser les nouvelles fonctions (get_root_url(), ect...)
Est-ce que en même temps, on peut définir ces mêmes fonctions, non pas avec un chemin relatif mais avec le chemin complet. Ceci afin de l'utiliser dans des fonctions externes (comme par exemple des liens dans le mail de notification)? Il faut bien sur, ne pas utiliser $conf['gallery_url'] qui permet d'avoir simplement un point d'accés au site (et peut être différent du chemin réel physique) mais en utilisant une fonction du style:
function get_complete_root() { $host = $_SERVER['HTTP_HOST']; $page = $_SERVER['PHP_SELF']; $address = "http://$host$page"; return dirname($address); }
rub,
pour le nbm: tu ne dois plus creer manuellement les liens category.php?cat=123 et picture.php?cat=123&image_id=5266. A la place tu dois appeler les fonctions:
$url = make_index_url( array( 'category' => 123, ) ); $url = make_picture_url( array( 'category' => 123, 'image_id' => 5266, 'image_file' => 'DSC_2345.jpg', ) );
biensur avec les bons parametres.
mathiasm a écrit:
rub a écrit:
De toute façon, je vous demanderais de verifier si ce que j'ai faut est correct...
une vraie perle :-) bravo!
C'est pas bien de se moquer ;-)
rub a écrit:
De toute façon, je vous demanderais de verifier si ce que j'ai faut est correct...
une vraie perle :-) bravo!
Heu, j'ai pas tout suivi dans la reécriture des url.
Mais sans rentrer dans le détails, ca consiste en quoi?
Ce que j'en ai compris:
o utilisation de fonctions pour génerer les URL,...
o supprimer du cat=? pour quelque chose de plus précis
o utulisation des '/' et c'est la que je comprends plus, est-ce par rapport à une norme ou à autre chose? Mais qu'il est bête ce ruru!
Sinon, pour la notification par mail, je suis en plein dedans et bien sur j'utilise l'ancienne norme. Donc, des que ca sera figé, pourriez-vous faire une check-list des trucs à faire pour passer de l'ancienne version de url à la nouvelle (les constantes à supprimer , les fonctions à utiliser). De toute façon, je vous demanderais de verifier si ce que j'ai faut est correct...
Z0rglub,
Comme je vais encoure toucher les url pour la chronologie, j'aimerais apporter quelques modifs au rewriting des url:
1. utilisation de la fonction picture_url dans category_default.inc.php (si tu ne l'as encore fait)
2. deplacer image_id a la fin de l'url
3. preparation de code pour pouvoir utiliser le nom de fichier de l'image dans l'url. Par exemple: si image_id=5266 et nom fichier DSC_2345.jpg alors on peut facilement avoir /category/123/5266, /category/123/5266-DSC_2345.htm ou /category/123/DSC_2345.htm. Par defaut on a le premier cas.
4. preparation du code pour pouvoir virer le ? dans l'url. Trois choses a faire:
a. remplacer $url_self.'&action=add_to_caddie' avec qqchose comme add_url_param($url_self, 'action=add_to_caddie')
b. partout dans le code, ne plus utiliser PHPWG_ROOT_PATH pour les liens, mais une fonction get_root_url() (qui retournera ../../ pour category.php/categories/123)
c. changement dans les templates les liens vers css et images avec qq chose comme {root_url}/template/{themeconf:template}/default-layout.css ...
Dis-moi ce que tu penses et si tu travailles encore dessus pour qu'on se marche pas sur les pieds.
Dans le section_init.inc.php, plusieurs questions sur le codage pour pierrick:
- Pour le test du premier token, pourquoi des if else enchainés plutot qu'un
switch ($tokens[$next_token])
, qui me parait plus clair. Problème de performance?
Question que je répète pour la gestion du $page['section'] (ligne 304)
- De même, ligne 188, le for sans fin; pourquoi pas un
while (isset($tokens[$i]))
Les remarques sur le fond, s'il y en a, viendront après un peu de pratique.
Edit: et le bug 313
voilà, on ne se connecte pas pendant 2 jours et 5 commits dans la vue! Ma BSF est obsolète :-/
Bravo pour le boulot!
Mais je suis pas couché, moi, ce soir ;-))
(qui a dit comme d'hab'?)
rvelices, [Subversion] r1084 corrige les bugs que tu cites sauf celui des metadata.
rvelices, en effet, il reste encore pas mal de choses qui ne marchent pas :-/ J'ai essayé de limiter les dégâts, mais si j'avais voulu être exhaustif dès le premier commit, je n'aurais jamais pu commiter :-/, donc j'ai voulu montrer une espère d'aperçu.
Je continue à bosser dessus, merci pour la notification des bugs, je regarde à partir de ce soir.