Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

grum
2007-10-07 20:18:29

j'ai fait encore plus simple : tu réorganises, tu synchronises ;)

http://forum.phpwebgallery.net/viewtopic.php?id=11906

sakkhho
2007-10-06 10:04:19

je pense aussi que ton idée est la bonne grum, eviter le max de manip à l'utilisateur. et procédé par etape un peu comme importstat
dans un menu 'réorganiser votre galerie'

L'util reorganise sa galerie (sans syncro apres bien sur !!)

partie plugin :
Etape 1 : Prepa des tables et sauvegarde de la BDD
Etape 2 : Mise à jour de la BDD
Etape 3 : Le plugin compare les tables et la tables backups
Etape 4 : Suppresion des  tables de sauvegarde.

grum
2007-10-05 23:12:38

VDigital a écrit:

Tu passes à coté...

- Pas de synchronisation.
- Pas de synchro (ou uniquement en simulation pour s'assurer qu'on ne fait pas d'erreur).
- Pas de synchro avant, ni après.

8-)

je prends l'option 2, plus sécuritaire :)

VDigital
2007-10-05 23:06:57

grum a écrit:

en fait même si ta solution fonctionne bien, elle nécessite des étapes de réorganisation :
- préparation des nouveaux répertoires
- synchronisation pour les avoir dans la base
- association "virtuelle" de la nouvelle catégorie => délicat ; l'interface utilisateur doit être simple et efficace
- déplacement des répertoires
- synchronisation

cà reste compliqué non ?


mon idée :
- réorganiser son répertoire
- synchroniser
çà doit être possible à faire (même sans trigger en demandant une action à l'utilisateur), mais il faut du temps par contre.

Tu passes à coté...

- Pas de synchronisation.
- Pas de synchro (ou uniquement en simulation pour s'assurer qu'on ne fait pas d'erreur).
- Pas de synchro avant, ni après.

8-)

grum
2007-10-05 22:45:47

en fait même si ta solution fonctionne bien, elle nécessite des étapes de réorganisation :
- préparation des nouveaux répertoires
- synchronisation pour les avoir dans la base
- association "virtuelle" de la nouvelle catégorie => délicat ; l'interface utilisateur doit être simple et efficace
- déplacement des répertoires
- synchronisation

cà reste compliqué non ?


mon idée :
- réorganiser son répertoire
- synchroniser
çà doit être possible à faire (même sans trigger en demandant une action à l'utilisateur), mais il faut du temps par contre.

yserver
2007-10-05 22:32:32

Même si le triggers lors de la synchro sont la méthode la plus adapté, il n'est pas possible de faire un plugin beaucoup plus simple?
Je m'explique :
Cela me pose aucun problème de modifier les tables SQL. Je pense que certain si et ne déplacerons par leur dossiers.
Pour leur rendre service, il n'est pas envisageable de faire un plugin du type séléction de la catégorie déplacée et sélèction de la catégorie de destination et le plugin fait les modifs qui s'imposent dans les tables.
Cela présent l'avantage d'être plus simple. Par contre il est clair que sans sauvegarde préalable au minimum de l'entré changé en cas d'erreur de manipulation, c'est ferme et définitif et cela peut avoir des conséquences très désagréable.

grum
2007-10-05 20:48:05

P@t a écrit:

sakkhho a écrit:

Grum te sens tu d'attaque ? Faut bien justifier ton new statut qd meme !! ;-))

Et voila, t'as vu ca grum?
Tu peux fournir autant de plugin que tu veux, ils sont jamais rassasiés!
Non mais sans blagues!

beaucoup de volonté mais pas beaucoup de temps !

faut donc prioriser :
- MyPolls v1.2
- MyPolls v2.0 (voir du coup ne pas faire la 1.2 et passer à la 2.0 directement ?)
- JaiToutDéplacé v1.0-beta => les triggers demandés ici sont presques indispensables pour une gestion automatique via plugin (sinon çà reste en manuel)

Et en même temps, faut que je trouve le temps de plonger dans PWG plus en avant...

P@t
2007-10-05 20:01:10

sakkhho a écrit:

Grum te sens tu d'attaque ? Faut bien justifier ton new statut qd meme !! ;-))

Et voila, t'as vu ca grum?
Tu peux fournir autant de plugin que tu veux, ils sont jamais rassasiés!
Non mais sans blagues!

ddtddt
2007-10-05 18:31:10

sakkhho a écrit:

Grum te sens tu d'attaque ? Faut bien justifier ton new statut qd meme !! ;-))

+1 mdr

sakkhho
2007-10-05 18:13:26

un 'grois point noir' de pwg disparaitrait si il existait un plugin de la sorte....
Grum te sens tu d'attaque ? Faut bien justifier ton new statut qd meme !! ;-))

yserver
2007-10-05 17:28:54

Bon voila,

J'ai poursuivi mes tests, sur d'autres répertoires plus profonds dans l'arboressence avec des sous-dossiers.
Je confirme qu'il faut et il suffit de :
  - déplacer le dossier sur le FTP
  - modifier en SQL uppercats
    1/ si initialement la catégorie était à la racine ==> ajouter l'ID de la nouvelle catégorie physique parente
    2/ si initialement la catégorie parente n'était pas à la racine ==> remplacer la première valeur du champs par l'ID de la nouvelle catégorie physique parente
  - modifier id_uppercat ==> y mettre l'ID de la nouvelle catégorie physique parente
  - synchonizer
  - puis une petite maintenance pour finir le travail

PWG n'y voit que du feu, il remet tous les champs à jours.
L'historique, les commentaires, les droits, les tags... de la catégorie, des sous-catégories et des images sont conserver.

Faut simplement pas se planter dans les modifs SQL. Cependant une simulation lèvera des erreurs en cas de modifications erronées. Donc faites toujours une simulation au préalable pour valider que vous avez procédez correctement.

Au vu des manipulations à faire, il semble envisageable de faire un plugin pour ceux qui n'osent pas. Je pense que cela doit être possible.

Au sujet des plugins :
Malheureusement, je ne peux pas le faire. Pour l'instant, j'ai bien compris dans les grandes lignes comment procéder. Mais je n'ai pas assez de temps à y consacrer pour me lancer de dans. Le code PHP et ce qui va avec je suis ignard en la matière. Je ne sais pas assez bien coder dans ces langages (moi ces plutot le C/C++ et compagnie, pas trops les langages script et Web)

@+

sakkhho
2007-10-04 08:16:37

je suis d'accord avec toi grum .. si ce que tu dis est realisable j'suis preneur !
et je pense que pas mal de personne sont interessé car le sujet et souvent revenu sur le forum

grum
2007-10-03 23:14:55

Ok, après relecture attentive de la manip de yserver, j'ai compris le biniou, et effectivement la synchro n'y vois que du feu !
pas mal comme astuce.

çà nécessite par contre de tripatouiller dans les bases, et de savoir en résumant la manip :
- trouver l'ID de la catégorie à déplacer et correspondant au répertoire physique sur le disque
- trouver l'ID de la catégorie correspondant au répertoire physique sur le disque
- faire les modifs en table avant de déplacer les fichiers
- déplacer physiquement les fichiers
- synchroniser

Pour un utilisateur lambda, c'est pas simple (et même si j'ai pigé le truc je suis pas certain de le faire du premier coup sans me planter quelque part !)

Faire une fonction qui serait capable de traiter tout çà ne serait pas forcément aisée non plus : plusieurs étapes à gérer, des risques pour l'utilisateur de pas tout comprendre..

Moi je suis plus bourrin :
- je déplace des photos comme çà (sans déplacer tout le répertoire)
- je déplace des répertoire dans tous les sens
çà m'arrive pas souvent, mais çà peut arriver.


Mon idée, côté utilisateur, c'est :
- je réorganise mes fichiers sur le ftp
- je clique sur ma synchro => tout est là, bien conservé : les commentaires utilisateurs, ma description sur la photo, mon historique....

la solution de retrouver pour une image le nouvel ID et de réaffecter à ce nouvel ID les caractéristique de l'ancien ID fonctionne, c'est elle qui est (en version light) en place dans l'onglet outil de AStat. mais elle ne sait gérer que la mise à jour de l'historique, et souffre du problème que deux images différentes peuvent avoir le même nom de fichier. mais bon, là aussi des solutions existent (calculer un md5 sur le fichier et le stocker dans la table image : si deux fichiers ont le même md5, il s'agit de la même photo => aucun interet de l'avoir deux fois sur le site ; par contre calculer un md5 sur chaque fichier çà peut être long... ).


bref, moi je suis partisant de l'utilisateur qui n'a pas à se poser de questions :)

yserver
2007-10-03 21:07:36

Concerant l'historique ==> Il est lui aussi conservé.
Tout ce que j'ai pu vérifier indique que la manipulation qui consite simplement à modifier uppercats de la categorie que je viens de déplacer suffit pour permettre de déplacer une catégorie physique, tout en conservant toutes les données qui lui sont rataché.

Le moteur semble tellement bien pensé, que cela peut marcher simplement comme cela.

Je vais poursuivre mes tests sur d'autre catégorie physique qui ne se trouve pas à la racine de la galerie, pour vérifier si cela est généralisable.

Si c'est bien le cas, la procédure pour déplacer une catégorie physique semble très simple finalement ==> Un petit plugin (c'est peut être dangereux)

Bon soirée

grum
2007-10-03 20:54:50

quelque chose m'échappe là :)

bon, je réflexionne et je reviens à la charge après !
(en plus j'ai 15000réponses à faire à propos de mypolls)

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact