Attention ne pas prendre à la lettre la page indiquée (Attention aux versions de la galerie).
Dans Piwigo, le Plugins Manager est devenu obsolète par exemple (le menu des Plugins permet d'activer et d'installer un grande majorité de plugins de façon "automatique").
Cela ne se fait pas tout seul toutefois, cela reste au webmaster de choisir (donc sous contrôle).
En effet, elle est telement simple que ça ne me donne pas goût de reprendre cette page.
Question peut être simple: comment installer le plugin ?
Le config_local n'est pas là, par anticipation on peut le créer vide.
Dans le cas présent, l'utilisateur le trouvera et il ajoutera :
$conf['use_exif']=false;
$conf'show_exif]=false;
Et là, plusieurs possibilités:
- Il peut se planter dans la syntaxe et ... la galerie ne marche plus. (extension:144 évite ce pb.)
- Il peut se poser des questions sur les éventuels autres paramètres. (extension:144 donne la liste des valeurs par défaut dans le lien vers l'affichage du config_default)
- Il peut aussi se dire comme $conf['use_exif'] et $conf'show_exif] ne sont pas là, et qu'ils sont dans le config_default, je vais faire ma modif là-bas (Evidemment extension:144 évite ce pb).
Pour éviter tout ça, la solution complémentaire (au test d'existence du config_local) consiste à intégrer en standard extension:144
Maintenant quand l'utilisateur arrive avec des préjugés sur le forum post:120145, le "Teckel joyeux" passe à côté le fait d'intégrer le support des EXIF dans sa version de php.
Il rate donc une partie des fonctionnalités et de l'intérêt de Piwigo.
Si on facilite l'ajout des =false, l'utilisateur ne viendra pas sur le forum.
Pourtant, si nous en savions un peu plus sur "étant installé en réseau local", on pourrait conseiller plus utilement:
--enable-exif
Votre PHP doit être compilé avec l'option --enable-exif.
Les utilisateurs Windows doivent s'assurer que les bibliothèques DLL php_mbstring.dll et php_exif.dll sont spécifiées dans le fichier php.ini.
La bibliothèque php_mbstring.dll doit être chargée avant la bibliothèque php_exif.dll : pensez à ajuster votre php.ini.
Sachant des choses, on aime bien les partager !
Bien sûre VDigital que l'on en parle de partout, que l'on recommande le plugin qui va bien, mais justement, ça fait beaucoup couler d'encre ces fichiers qui ne sont pas présents systématiquement et ça perturbe sérieusement les personnes qui n'ont pas le réflexe de se dire:
"Ha mais je suis bête et discipliné, le fichier mentionné n'existe pas, il doit y avoir un problème. Et si j'allais éplucher le site de Piwigo en quête d'informations à ce sujet."
Au lieu de se reposer sur des acquis, on peut toujours améliorer sans cesse les procédés pour que l'utilisateur devienne le plus fainéant possible (Ca me vient d'une déformation professionnelle ^^) et donc ça laisse plus de temps à l'équipe de Piwigo pour faire autre chose.
Plus Piwigo s'ouvre au grand publique et plus il est nécessaire de simplifier les choses. Car le monde informatique n'est pas à la portée de tous alors que pourtant, c'était soit disant une révolution qui devait simplifier la vie...
@Teckel joyeux:
C'est grâce à des retours comme le tiens que l'on se remet en question et que l'on peut juger de la pertinence des informations données et de la facilité (ou pas) d'utilisation de Piwigo :-)
Au moins ça aura eu pour mérite de remuer la vinaigrette, en attendant merci à toi Oh grand Sach(ant)em !
Gotcha a écrit:
Je vois mieux dit comme ça.
En effet, lors d'une MAJ on écrase systématique les fichier qui sont à livrer. Du coup, si un fichier local est livrén, bah il va se faire excraser aussi. Pas glop :-(
Et on ne pourrait pas imaginer alors que lors de l'installation (ou lors d'une migration), on puisse générer ce fichier local ?
Genre:
if not exist config_local.inc.php copy install/config_local.inc.php.bak include/config_local.inc.php
(A transposer en PHP évidement)
Oui, je sais que la solution passe par là et c'est déjà en place pour les local-layout.css
Mais...
J'en reviens au point de départ quand tu écris "config_local" est-ce que tu le fais volontairement ou est-ce une erreur de ta part?
Pourquoi le wiki parle du "config_local" un peu partout?
Pourquoi le fichier n'existe pas?
Cela ne mérite pas une recherche sur le forum ou le Wiki?
Je suis certain qu'on en parle et qu'on recommande extension:144
C'est peux être un peu ce compliquer la vie, il suffit d'utiliser le plugin qui va bien et les fichier locaux sont généré sans erreur et au bon endroit
Je vois mieux dit comme ça.
En effet, lors d'une MAJ on écrase systématique les fichier qui sont à livrer. Du coup, si un fichier local est livrén, bah il va se faire excraser aussi. Pas glop :-(
Et on ne pourrait pas imaginer alors que lors de l'installation (ou lors d'une migration), on puisse générer ce fichier local ?
Genre:
if not exist config_local.inc.php copy install/config_local.inc.php.bak include/config_local.inc.php
(A transposer en PHP évidement)
Je reformule.
Quand tu fait une mise à jour, tu écrase les fichier d'origine par les fichiers de la nouvelle version.
Si dans ta nouvelle version tu as un fichier local vide tu va écraser ton fichier personnalisé par le vide et tu aura perdu toutes tes modifications
Honnêtement j'ai du mal, car j'ai un fichier local et ça ne gène en rien les MAJ... donc je ne comprends pas...
Un fichier local n'est jamais mis à jour (c'est le principe même de ces fichiers de surcharge) mais si celui ci est vide, son incidence est donc nul...
Navré si je fait le boulet mais pour le coup, j'aimerai bien connaître l'origine de ce dénis de fichier local.
;-)
[EDIT]
Ce que je comprends dans ton explication c'est que la simple présence de config_local.inc.php bloquerai la mise à jour de config_defaut.inc.php ?!
C'est le cas ???
Gotcha a écrit:
Il pourrait contenir que des lignes misent en commentaires... non ?
Relis un coup ce que je viens d'écrire...
Il pourrait contenir que des lignes misent en commentaires... non ?
Gotcha a écrit:
Ca veut quand même dire que l'on a pas était assez clair quelque part. Car en effet, si on parle de config_local.inc.php et que l'utilisateur ne le trouve pas, je me met à sa place et je prends le premier qui y ressemble. Et pour moi, un exemple c'est "juste" un exemple autrement dit, un brouillon.
Du coup, sur un brouillon on a des ratures etc et là c'est le drâme !
Je serais donc partisan de livrer un vrai fichier d'exemple config_local.inc.php
Ca serait plus simple pour beaucoup de monde je pense. Même dans les explication dans le wiki, ça enlève un conditionnel que tout le monde à du mal à saisir.
Bien entendu, vous n'êtes pas obligés de me croire.
Si ce fichier n'est pas inclus pas défaut, c'est bien qu'il doit y avoir une raison, non?
En effet, tout l'intérêt des fichiers locaux, c'est de pouvoir écraser les paramètres pas défaut sans modifier le fichier d'origine. Et pour une mise à jour, les paramètres modifiés ne seront pas écrasés... Ce qui ne serait pas le cas si le fichier local était présent.
Ca veut quand même dire que l'on a pas était assez clair quelque part. Car en effet, si on parle de config_local.inc.php et que l'utilisateur ne le trouve pas, je me met à sa place et je prends le premier qui y ressemble. Et pour moi, un exemple c'est "juste" un exemple autrement dit, un brouillon.
Du coup, sur un brouillon on a des ratures etc et là c'est le drâme !
Je serais donc partisan de livrer un vrai fichier d'exemple config_local.inc.php
Ca serait plus simple pour beaucoup de monde je pense. Même dans les explication dans le wiki, ça enlève un conditionnel que tout le monde à du mal à saisir.
Bien entendu, vous n'êtes pas obligés de me croire.