Piwigo Bugtracker

Viewing Issue Advanced Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000585 [Piwigo] metadata minor always 2006.11.19 00:53 2007.01.26 23:45
Reporter mko View Status public  
Assigned To rub
Priority normal Resolution fixed Platform
Status closed   OS linux
Projection none   OS Version
ETA none Fixed in Version Alligator 1 Product Version 1.6.1
  Target Version Product Build
Summary 0000585: Problème de mise à jour du champ 'créee'
Description lorsque des images sont rajoutées à la base de données, le champ 'créee' n'est pas renseigné. Cela affecte les renseignements affichés lors de la visualisation de l'image (champ vide). Cela affecté également le calendrier qui n'est plus mis à jour. J'ai constaté ce problème lors du passage direct de la version 1.4.1 à la version 1.6.1
Steps To Reproduce menu catégorie, sous menu 'calendrier' sur la page principal de la galerie. Les nouvelles photos n'apparaissent pas.
Additional Information
Tags No tags attached.
browser any
Database engine and version MySQL: 5.0.27-nightly-20061009
PHP version PHP: 4.4.3-dev
Web server Apache 1.3.x
Attached Files

- Relationships
related to 0000337closedplg Pages warnings 

-  Notes
(0001516)
rub (developer)
2006.11.19 11:32

cf http://forum.phpwebgallery.net/viewtopic.php?pid=48851#p48851 [^]
Extrait du topic:

Moi, j'ai l'impression de ca ne fonctionne pas avec la synchro local mais que ca fonctionne avec la synchro en site distant.
J'utilise PWG depuis la 1.5.x et j'ai toujours du renseigné moi-même mes dates de création et depuis que je suis passé en sites distants, j'ai l'information qui est bien mise à jour.
(0001517)
plg (manager)
2006.11.19 15:37

Dans la description que je lis, je ne vois rien d'innatendu dans le fonctionnement de PhpWebGallery. Le champ "enregistré le" est rempli lors de l'ajout des images, mais pas le champ "créé le". Ce dernier est soit renseigné manuellement, soit rempli par synchronisation des métadonnées EXIF/IPTC si tout est configuré pour cela.

En théorie, pour la synchronisation des sites distants, ce devrait être la même chose : "créé le" n'est rempli que pour la synchro des métadonnées. Mais comme rvelices a beaucoup retravaillé cette partie du code, je ne promet pas qu'une synchro "normale" d'un site distant ne remplit pas le champ "créé le". J'aimerais une confirmation de rvelices sur le sujet.
(0001518)
rvelices (developer)
2006.11.19 16:31

Ca fonctionne bien en local (la preuve demo.phpwebgallery.net).

En remote ca fonctionne aussi (dans le xml il y a un attribut "metadata" qui indique la liste des attributs disponibles pour synchro).
(0001519)
plg (manager)
2006.11.19 16:58

> Ca fonctionne bien en local (la preuve demo.phpwebgallery.net).

Ce n'est pas "normal". "Créé le" est différent de "Enregistré le". On ne peut trouver la date "créé le" que dans les métadonnées EXIF/IPTC ou alors la rentrer manuellement. Donc on ne devrait pas remplir ce champ lors de la synchronisation des fichiers.
(0001520)
rvelices (developer)
2006.11.19 17:05

> Ce n'est pas "normal". "Créé le" est différent de "Enregistré le". On ne peut trouver la date "créé le" que dans les métadonnées EXIF/IPTC ou alors la rentrer manuellement. Donc on ne devrait pas remplir ce champ lors de la synchronisation des fichiers.

Je me suis mal exprime:
- date_available est toujours rempli la premiere fois qu'un element est ajoute.
- date_creation est rempli seulement a la synchronisation des meta-donnees sous certaines conditions
  - site local (fichier config 'use_exif' ou 'use_iptc' avec les bonnes map)
  - site remote (selon le contenu de listing.xml)


PS: Je ne sais pas pourquoi rub a demande aussi vite qu'on mette une fiche. Pour moi c'est un pb. de config utilisateur pas un bug. Je vais suivre sur le forum.
(0001521)
rub (developer)
2006.11.19 18:15

1er point: le bug de paramétrage par défaut
Pourquoi, j'ai demandé si vite une fiche, simplement car je n'ai rien paramétré pour les méta-données, j'ai la config par défaut, et j'ai une comportement par défaut différent avec les sites distants et les sites locaux, ce qui n'est pas normal.

Avant de lire les dernières notes, j'ai fait un test aussi et c'est bien ca.
Le champ date_creation après la synchro fichiers et méta-data est vide pour les sites locaux et renseignés pour les sites distants.

2eme point: Evolution
Vu la fonctionnalité du calendrier présent depuis la 1.6.x, à mon avis, par défaut, la date de création devrait être lu et renseigné par défaut.
(0001522)
plg (manager)
2006.11.19 18:45

> Le champ date_creation après la synchro fichiers
> et méta-data est vide pour les sites locaux et
> renseignés pour les sites distants.

En effet, $conf['use_exif'] est true par défaut dans tools/create_listing_file.php et false dans include/config_default.inc.php, ce n'est pas cohérent. En ce sens, je suis d'accord pour dire que c'est un bug (mais à corriger sur trunk)

> Vu la fonctionnalité du calendrier présent depuis
> la 1.6.x, à mon avis, par défaut, la date de
> création devrait être lu et renseigné par défaut.

Oui, c'est important, mais tous les utilisateurs n'ont pas de métadonnées EXIF sur leurs photos. Enfin, avec les appareils actuels, on pourrait dire que $conf['use_exif'] est à true par défaut et que le use_exif_mapping permet de remplir #images.date_creation avec DateTimeOriginal. rvelices, ton avis ?
(0001526)
rvelices (developer)
2006.11.19 23:41

> Enfin, avec les appareils actuels, on pourrait dire que $conf['use_exif'] est à true par défaut et que le use_exif_mapping permet de remplir #images.date_creation avec DateTimeOriginal. rvelices, ton avis ?
Pour moi c'est parfait comme ca - use_exif a true. Je ne pense pas trop qu'on va detruire les dates de quelqu'un qui les a rentre a la main dans 1.6 et ensuite fait une resynchro en 1.7 ... mais c'est quand meme une possibilite.
(0001527)
rub (developer)
2006.11.19 23:52

Il faudra bien préciser lors la nouvelle version du changement de config par défaut, des conséquendes (positif et négatif) et de la façon de configurer pour faire comme avant, non?
(0001545)
rvelices (developer)
2006.11.22 05:51

Je me desassigne
(0001549)
rub (developer)
2006.11.23 23:48

Petit soucis, avec easyphp par exemple, le support EXIF n'est pas activé et on a le message d'erreur "Exif extension not available, admin should disable exif use" avec $conf['use_exif'].

Est-ce que ceci dans le fichier config_default.inc.php, vous choque!

$conf['use_exif'] = true && function_exists('exif_read_data');

Ou préférez-vous, que je rentre plus dans le code au niveau des tests de la fonction.

Ou 3eme cas, que je mette un message plus complet dans la langue par défaut (car pour le moment en dur et en anglais?)
(0001552)
plg (manager)
2006.11.24 01:03

Je projette de faire un plugin (ou pas, je ne sais pas encore) pour écrire la configuration concernant la gestion des métadonnées. Tout ça pour dire que je préfèrerais éviter ce genre d'instruction dans le fichier de configuration.

La solution de switcher $conf['use_exif'] à false si function_exists('exif_read_data') retourne false est une bonne idée, mais l'utilisateur risque de ne rien comprendre : pourquoi ces métadonnées EXIF ne sont pas utilisées alors qu'il a bien fait sa configuration ? Un message d'avertissement dans l'entête d'admin.php serait du meilleur effet, non ?
(0001553)
rub (developer)
2006.11.24 07:30

Donc, je switche $conf['use_exif'] à false si function_exists('exif_read_data') retourne false après lecture de la configuration et si on est dans le partie admin, j'indique par un bandeau (les gris) que l'utilisation des exif a été désactivée, patati, patata....

ou bien, je mets le message dans la partie error (ou warning quand ca sera fait).
(0001554)
plg (manager)
2006.11.24 10:52

> ou bien, je mets le message dans la partie error (ou warning
> quand ca sera fait).

Warning, uniquement sur la page d'accueil de l'admin. Là, ce serait vraiment parfait je pense :-)
(0001603)
rub (developer)
2006.12.28 00:56

[Subversion] r1682

Les warnings n'étant pas encore implémenter j'ai mis le message dans les notes.

- Issue History
Date Modified Username Field Change
2006.11.19 00:53 mko New Issue
2006.11.19 00:53 mko browser => any
2006.11.19 00:53 mko MySQL version => MySQL: 5.0.27-nightly-20061009
2006.11.19 00:53 mko PHP version => PHP: 4.4.3-dev
2006.11.19 00:53 mko Web server => Apache 1.3.x
2006.11.19 11:32 rub Note Added: 0001516
2006.11.19 15:37 plg Note Added: 0001517
2006.11.19 15:38 plg Assigned To => rvelices
2006.11.19 15:38 plg Severity feature => minor
2006.11.19 15:38 plg Status new => feedback
2006.11.19 15:38 plg Category database => metadata
2006.11.19 16:31 rvelices Note Added: 0001518
2006.11.19 16:58 plg Note Added: 0001519
2006.11.19 17:05 rvelices Note Added: 0001520
2006.11.19 18:15 rub Note Added: 0001521
2006.11.19 18:45 plg Note Added: 0001522
2006.11.19 23:41 rvelices Note Added: 0001526
2006.11.19 23:52 rub Note Added: 0001527
2006.11.22 05:51 rvelices Note Added: 0001545
2006.11.22 05:51 rvelices Assigned To rvelices =>
2006.11.22 06:58 rub Status feedback => assigned
2006.11.22 06:58 rub Assigned To => rub
2006.11.23 23:48 rub Note Added: 0001549
2006.11.24 01:03 plg Note Added: 0001552
2006.11.24 07:30 rub Note Added: 0001553
2006.11.24 10:52 plg Note Added: 0001554
2006.11.24 11:00 rub Relationship added related to 0000337
2006.12.28 00:56 rub Status assigned => resolved
2006.12.28 00:56 rub Fixed in Version => Alligator (trunk)
2006.12.28 00:56 rub Resolution open => fixed
2006.12.28 00:56 rub Note Added: 0001603
2007.01.26 23:45 rub Status resolved => closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Contact
Powered by Mantis Bugtracker