En fait toutes les méthodes se valent et aboutissent à la même chose à partir du moment où les photos sont gérées dans des catégories virtuelles.
Exemples :

1 - La méthode "à l'ancienne".
Vous pouvez utiliser un outil local de mise en forme pour vos photos (génération des miniatures et des tailles intermédiaires + formatage de l'architecture des dossiers) et envoyer le tout sur votre dossier ./galleries/ via FTP. Vous pouvez tout charger dans un seul et même dossier à condition de conserver la structure de dossiers minimale requise : Dossier "thumbnails" pour les miniatures et, éventuellement, "pwg_high" pour les HD si souhaitées.
Ensuite, après avoir synchronisé votre dépôt sur votre galerie, vous créez les albums virtuels selon la structure que vous envisagez et vous y associez vos photos comme vous le voulez depuis le dépôt physique.

Avantages :
* On garde la maîtrise des noms de fichiers puisque le stockage physique est géré par le webmaster (pratique si on veut pouvoir récupérer un jour les photos avec leur nom d'origine).
* En cas d'hébergement sur un serveur mutualisé et restrictif sur les ressources, pas de problème pour les opérations de génération des miniatures et tailles intermédiaires des photos puisque fait en amont, sur votre PC.
* Le changement d'hébergeur ou la restauration de la galerie.

Inconvénients :
* Seul le webmaster peut faire ce genre de chose et "déléguer" l'accès webmaster ainsi que l'accès FTP au serveur peut être dangereux.
* Il faut savoir jongler entre album physiques (issues de la synchronisation des photos physiques) et les albums virtuels qui cohabiteront.
[HS]Ceci dit, nos politiques l'ont fait, la cohabitation, et ce n'était pas si ma finalement ;-))[/HS]
* Dans l'avenir de Piwigo, cette méthode, bien qu'intéressante par certains côtés, pourrait devenir obsolète.

2- La méthode d'ajout via l'interface web (sur le site ou via pLoader).
Par défaut, les administrateurs d'une galerie peuvent ajouter de nouvelles photos et créer des albums virtuels en passant par le module d'ajout dans le panneau d'administration. Les photos ainsi chargées sont positionnées uniquement dans des albums virtuels. Les photos physiquement stockées sur le serveur sont dématérialisées et "perdent" leur nom d'origine qui est stocké dans la base de données.
Grâce au plugin Community, les utilisateurs inscrits et autorisés par l'administrateur peuvent faire la même chose.

Avantages :
* Les administrateurs ne sont plus les seuls à pouvoir ajouter des photos.
* L'ajout de photos est simplifié pour permettre l'accès au plus grand nombre.
* La structure des dossiers est entièrement virtuelle.
* C'est la solution privilégiée dans l'avenir de Piwigo.

Inconvénients :
* Les photos ne sont plus stockées dans le dossier ./galleries/ mais dans ./upload/ et sans leur nom d'origine. Il sera très difficile de les récupérer pour une sauvegarde (par exemple) ou pour les restaurer sur un nouvel hébergement.
* Les opérations de redimensionnement des photos sont effectuées par le serveur d'hébergement. Dans certains cas (hébergeurs mutualisés), les ressources autorisées peuvent ne pas être suffisantes pour que le serveur fasse le travail. Ou alors il faudra faire avec des restrictions sur la taille des photos à traiter.

Réponse du Dr Claude :
Cet utilisateur n'a pas tout à fait tort, mais la formulation "on ne peut pas utiliser les deux méthodes" est trop absolue. Techniquement, les deux méthodes aboutissent au même résultat : des fichiers sur disque + des entrées dans piwigo_images et piwigo_image_category. Ce n'est pas deux systèmes incompatibles par nature — d'ailleurs plusieurs retours d'utilisateurs confirment que toutes les méthodes se valent et aboutissent à la même chose à partir du moment où les photos sont gérées dans des catégories virtuelles.

Le vrai risque se situe sur des cas précis, pas sur la coexistence en soi :

1. Exécution concurrente réelle
Lancer une synchronisation pendant qu'un upload web est en cours peut effectivement poser problème : la sync peut tomber sur des fichiers partiellement écrits (thumbnail pas encore généré, fichier temporaire) et créer des entrées incohérentes. C'est un problème de timing, pas de méthode en soi.

2. Renommage/déplacement manuel après upload web
C'est le piège classique. Si une photo a été ajoutée via "Ajouter des photos" (donc son chemin est déjà enregistré en base), et qu'on va ensuite la renommer ou la déplacer manuellement dans ./galleries, la prochaine synchronisation va la traiter comme une SUPPRESSION et un ajout — avec perte des associations (tags, commentaires, droits, catégories) puisque c'est un nouvel image_id. Piwigo

3. Mélange gestion physique / virtuelle sur le même album
Piwigo distingue les albums "physiques" (liés à un dossier dans ./galleries, gérés par sync) et les albums "virtuels" (pas de dossier associé). Ajouter des photos par upload web dans un album physique, puis synchroniser ce même dossier, peut créer de la confusion sur qui "possède" quoi — sans forcément casser la base, mais ça complique le suivi.

En résumé : le risque n'est pas "utiliser les deux méthodes sur une même install", mais plutôt "faire les deux en même temps sur le même contenu, ou manipuler à la main des fichiers déjà gérés par l'une des deux méthodes sans repasser par une synchro cohérente ensuite". Le conseil habituel est de bien séparer dans le temps (finir un batch avant l'autre) et d'éviter de traiter à la main du contenu qui a été ajouté via le formulaire web.