cbtitalia a écrit:

Moi pour régler le problème, le nom de fichier de mes photos est écrit de la manière suivante : 2009-03-25_08-51-23_test.jpg (cela se fait avec xnview sans problème.  De plus mon nom de fichier est toujours unique.

Et le tri des photos se fait sur le nom de mes fichiers.

Oui mais du coup tu n'as plus d'autre possibilité de tri.

Personnellement, je réorganise mes images dans un certain ordre que je trouve adapté et qui n'est pas forcément celui de prise de vue.
Je nomme mes fichiers à l'export de mon logiciel avec un numéro qui témoigne de cet ordre.

En revanche, dès que je sors des catégories (recherche par tag, etc...), là je veux les classer par ordre chronologique.

Moi le classement actuel (qui ne tient compte que de la date) me convient la plupart du temps, je préfère même à quelque chose qui tiendrait compte aussi de l'heure, car du coup je peux laisser comme critère de tri : 1.date / 2.nom de fichier.
Et ça convient dans 95% de mes catégories, car comme la date est la même, ça passe direct au critère 2.

Si le tri par date tenait compte aussi de l'heure... ça m'obligerait à changer le critère de tri de toutes mes catégories.
(ce qui ne serait pas non plus un travail phénoménal, pour être honnête)

plg a écrit:

judedie a écrit:

ce bug est affiché comme étant pris en compte et prévu pour la version 2.0.1, par contre je n'ai pas vu de changement le concernant sur la version 2.0.1 sur le change log et il n'apparait pas sur la roadmap de la version 2.0.2.
Est il toujours d'actualité?

La 2.0.1 est sortie essentiellement sortie pour un problème de sécurité, donc nous n'avons pas intégré cette demande.

Cela dit, ce qui m'embête, c'est que cette demande implique un changement dans le format de la base (passage du champ images.date_creation de date à datetime), et du coup ça veut dire que le passage de 2.0.1 à 2.0.2 imposera un "upgrade" en plus de la copie des fichiers modifiés, alors qu'il ne s'agit pas vraiment d'un bug, c'est plutôt une demande de fonctionnalité (enfin, c'est limite).

Je vais voir avec P@t qui prépare un plugin pour gérer les mises à jour directement depuis l'administration de Piwigo si on pourrait intégrer l'appel à "l'upgrade".

Merci pour les précisions, je suivrais avec attention les prochaines mises à jour alors :)

plg a écrit:

Criss a écrit:

Code:

$conf['order_by'] = ' ORDER BY date_creation DESC, file ASC, id ASC';
$conf['order_by_inside_category'] = $conf['order_by'];

Car c'est $conf['order_by_inside_category'] qui est utilisé dans les catégories il semble, et il est défini dans la config par défaut en copie et non par "pointeur".
Donc les modifs apportées à $conf['order_by'] n'ont aucun impact sur lui.


Du reste je suis preneur d'une meilleure explication pour le doublement de ces paramètres de configuration.

Dans Piwigo, on affiche des collections de photos. Cela peut être le contenu d'une catégorie, le résultat d'une recherche, une collection aléatoire, les photos favorites, etc. $conf['order_by_inside_category'] n'est utilisé que lorsque l'on affiche une catégorie.

Merci de cette précision, j'avais zappé les modes recherche et tags. :P

A vrai dire, le plugin est pas vraiment prévu pour tout suite, sachant que je déménage à la fin de la semaine, et que les cartons ont pris du retard ;-)
En plus, je risque d'etre coupé d'internet quelques semaines...

Je ne suis pas franchemennt favorable au changement de base dans une meme branche...
Mais bon, ca devrait pouvoir se faire quand meme.

Criss a écrit:

Code:

$conf['order_by'] = ' ORDER BY date_creation DESC, file ASC, id ASC';
$conf['order_by_inside_category'] = $conf['order_by'];

Car c'est $conf['order_by_inside_category'] qui est utilisé dans les catégories il semble, et il est défini dans la config par défaut en copie et non par "pointeur".
Donc les modifs apportées à $conf['order_by'] n'ont aucun impact sur lui.


Du reste je suis preneur d'une meilleure explication pour le doublement de ces paramètres de configuration.

Dans Piwigo, on affiche des collections de photos. Cela peut être le contenu d'une catégorie, le résultat d'une recherche, une collection aléatoire, les photos favorites, etc. $conf['order_by_inside_category'] n'est utilisé que lorsque l'on affiche une catégorie.

plg a écrit:

Problème bien connu de nos services, mais toujours pas corrigé :-/ je vais changer la priorité du bug dans le bugtracker.

* [Bugtracker] ticket 270
* [Bugtracker] ticket 473
* topic:5544
* post:53350
* topic:8708

(en suivant tous ces liens, il y en a pour une bonne heure de lecture, bonne soirée)

Ok merci de l'info, effectivement ya de quoi lire :)
Je crois que je vais attendre le correctif du bug en fait :)

Problème bien connu de nos services, mais toujours pas corrigé :-/ je vais changer la priorité du bug dans le bugtracker.

* [Bugtracker] ticket 270
* [Bugtracker] ticket 473
* topic:5544
* post:53350
* topic:8708

(en suivant tous ces liens, il y en a pour une bonne heure de lecture, bonne soirée)

Une page à lire dans le wiki

notamment :

// order_by : comment changer l'ordre d'affichage des images dans une    
// catégorie ?
//
// Il y a plusieurs champs qui peuvent servir à ordonner l'affichage :
//
//  - date_available : date d'ajout dans la galerie
//  - file : le nom du fichier
//  - id : l'identifiant unique de l'image
//  - date_creation : la date de création
//
// Une fois que vous avez choisi quels champs utiliser, vous devez choisir
// l'ordre croissant ou décroissant sur chaque champ. Exemples :
//
// 1. $conf['order_by'] = " order by date_available desc, file asc";
//    va ordonner selon la date d'ajout par ordre croissant, puis sur le nom du
//    fichier par ordre croissant
//
// 2. $conf['order_by'] = " order by file asc";
//    va ordonner selon le nom du fichier par ordre croissant
//
$conf['order_by'] = ' ORDER BY date_available DESC, file ASC, id ASC';