Etant seul (pour le moment ?) à développer Phyxo, cela n'avance par forcément aussi vite que je le souhaiterais. Mais depuis la création du dépôt, j'ai :
- installé un site pour le projet
- installé un site de démonstration
- installé un site pour les extensions (plugins, thèmes, langages)
Et bien évidemment j'utilise Phyxo à titre personnel, même si je n'ai pas encore migré ma galerie vers PostgreSQL.
Je ne développe pas toujours très assidûment ou très régulièrement mais depuis quelques semaines, j'ai vraiment envie de faire avancer les choses et à force de regarder le code j'ai vraiment envie de le moderniser, d'utiliser les bonnes pratiques. J'ai déjà mis en place composer, initier la création de tests unitaire (en utilisant atoum) ou fonctionnels (en utilisant Behat) mais force est de constater que de nombreuses parties de code sont difficilement testables. Plus grave encore certaines parties de code sont difficilement modifiables sans que cela ait un impact inattendu sur d'autres parties. Il y a de nombreux effets de bords.
Ce qui pose vraiment problème :
- les nombreux include en entêtes de beaucoup de fichiers pour inclure des fonctions qui seront utilisées (ou pas)
- les fonctions qui ont des effets de bord en modifiant des variables globales
- l'utilisation de l'arobase à des endroits inappropriés
- l'utilisation de bibliothèques externes en fin de vie (je pense notamment à Smarty)
- une gestion des URLS à la main et difficilement configurable ou modifiable
1 De Franck -
Suis curieux de voir tes progrès futurs avec Synfony ;-)
Bon courage !
2 De Nicolas -
Ce n'est pas facile de migrer vers du code plus moderne sans rien casser, ni perdre de fonctionnalités.
Et le fait d'être seul n'aide pas.
p.s: chose curieuse sans aucun rapport, tes messages sont marqués comme spam.
3 De Pierrick -
Eh tout doux. "vieille application" toi même ;-)
Tout ce que tu exposes ici et valide, mais cela tient aussi pas mal de "l'exercice de style". L'utilisateur final ne voit pas toute cette mécanique. Il voit le design, la facilité d'utilisation, le fonctionnalités, la vitesse et un peu la sécurité (le jour où il y a des soucis).
Si Piwigo continue d'évoluer sur son architecture technique actuelle, c'est parce que 1) ça marche très bien 2) tout changer représente un travail titanesque, pour un gain utilisateur invisible. Oui je suis conscient de la problématique de dette technique mais je suis également conscient que le temps est limité et que la priorité pour Piwigo c'est l'utilisateur final.
Bon j'ai fini de défendre Piwigo :-) Je suis curieux de voir ce que le passage Symfony va donner, notamment en terme de perfs et si c'est gérable de conserver le système de plugins. Bon courage pour cette adaptation !
4 De Nicolas -
"Vieille application", c'est au sens historique même si je l'avoue cela a un sens péjoratif.
Après je partage ton avis sur le fait de moderniser le code : c'est plus un exercice de style qu'autre chose. Mais l'idée est de garder les fonctionnalités sans rien casser et en gardant les performances.