Malgré mes recherches dans les forums et la documentation, je n’ai pas trouvé de réponse à cela : est-il possible d’installer un thème acheté sur Dolistore en utilisant l’installateur comme pour les modules, c’est-à-dire en téléchargeant le ZIP du thème depuis l’interface d’administration de mon instance Dolibarr ?
J’ai examiné le code de cet installateur de modules (Dolibarr 18) et je n’ai pas trouvé que cela soit possible. J’ai également examiné le PHP qui charge la liste des « thèmes installés » (dans Configuration / Environnement) et il ne recherche pas au-delà du répertoire « /theme ».
Donc ma question est la suivante :
Suis-je dans l’erreur ? Peut-on vraiment installer un thème depuis l’ « installateur ZIP » de modules ?
Si ce n’est pas le cas, ne devrions-nous pas en créer un pour que les utilisateurs non-programmeurs (même pour soi-même) puissent plus facilement télécharger un thème et l’installer sur leurs instances Dolibarr ?
Note : Je me pose toutes ces questions parce qu’après 4 ans de vente de mes modules sur Dolistore (DarkTheme et SolarizedTheme), un client m’a posé cette question aujourd’hui, car il n’a pas pu installer mon thème via l’installateur de modules.
Pour ma part, je trouve qu’on devrait déjà commencer par séparer les fichiers de template des contrôleurs, et de placer tout ça dans les thèmes.
Cela donnerait plus de liberté aux développeurs de thèmes.
Il n’y a même pas besoin de moteur de template pour ça. C’est vieux comme le monde, facile à comprendre, et ça ne demande aucune mise à jour d’un quelconque moteur ensuite. Ceci est le meilleur exemple que j’ai trouvé:
Puis, d’adopter une bibliothèque commune (Bootstrap par exemple), préchargée dans Dolibarr, sur laquelle tous les développeurs pourraient s’appuyer pour développer leurs modules ou thèmes.
je suis d’accord avec toi sur le fait qu’il serait probablement plus judicieux de le rendre plus modulaire que sa configuration actuelle, mais dans la PRATIQUE, je pense que ce n’est ni RÉALISTE ni AVANTAGEUX de le faire avec Dolibarr.
Je suis moi-même développeur de mon propre CMS en PHP depuis le début et depuis 15 ans (!!!), et je t’assure que ce que tu proposes relève presque de la « mission impossible »… en pratique.
Dans le cas de Dolibarr, je pense que c’est encore plus impossible que pour un projet « personnel » comme le mien, pourquoi ? Parce que tu as un UNIVERS DE PLUGINS DE TIERS, qui serait EXTREMEMENT DIFFICILE à adapter à une nouvelle architecture logicielle. Je pourrais te parler ou te montrer quelques modules tiers que nous utilisons pour la facturation spécifique au Mexique, qui est un monde de listes, d’écrans, de formulaires, etc… qui rivalisent en COMPLEXITÉ et ÉTENDUE avec ceux de Dolibarr lui-même… et je te parle d’UN SEUL MODULE tiers. Alors, je n’imagine même pas comment ça serait de REÉCRIRE (avec succès) tout l’univers des modules tiers.
Ce que je te dis, nous en avons déjà discuté année après année sur les forums. Et ici, je soutiens l’opinion « officielle » de l’équipe Dolibarr la plus expérimentée qui défend une thèse comme celle que je viens de te présenter.
Et si tu me demandes une alternative : je te dirais que notre meilleure option est de tenter d’OPTIMISER ce qui existe. Il y a des études qui montrent que pour les « plateformes logicielles » (frameworks), il est beaucoup plus AVANTAGEUX « d’optimiser » que de « réécrire ».
Je comprends qu’il y a des gens (surtout des jeunes) qui se laissent éblouir chaque année par la nouvelle technologie à la mode et les nouvelles façons de faire les choses « différemment ». Mais généralement, le bénéfice du changement est minime, tandis que le coût et le risque du changement sont tout simplement énormes.
Je vote pour le laisser tel quel. Et en revenant à mon premier message dans cette discussion : une bonne optimisation serait de mettre un onglet d’installation de thèmes « en deux clics » .
Y’a rien, ou presque, à réécrire. Dans un premier temps, il s’agit juste de déplacer du code dans les thèmes, plutôt que de le laisser dans le contrôleur et de le formater différemment. Ça se fait progressivement
Il n’y a rien de nouveau, c’est du pure PHP, aucune bibliothèque tierce nécessaire.
Ensuite, intégrer une bibliothèque CSS à dolibarr, c’est justement pour que tout fonctionne sans conflit ensuite, que les modules s’adaptent aux thèmes, et éviter le genre de problème que vous semblez mentionner.
En tant que developpeur de module, Revoir le template de ses modules ne me semble pas insurmontable. C’est aux modules de s’adapter au CMS, pas l’inverse…
Cher Cedanc, ce que tu décris comme « presque rien à réécrire » représente une montagne d’heures de tests, après ces « réécritures »… et cela dans le cas où ce serait vraiment aussi « immédiat » que tu le proposes pour tous les modules.
Ce qui donne le plus de travail n’est pas « réécrire », mais laisser le résultat de la réécriture avec moins de défauts que le logiciel en avait déjà. De plus, je pense que je n’ai pas été suffisamment emphatique dans mon commentaire précédent : aussi simple que soit le déplacement à effectuer dans chaque « vue »… il y en a des dizaines dans chaque module… qui va payer ces heures de travail ? Est-ce vraiment rentable ?
D’après ce que je vois, cela ne vaut absolument pas la peine, et la situation actuelle MVC de Dolibarr et de ses modules s’est avérée « suffisamment acceptable ». Nous ne sommes pas dans une situation de NÉCESSITÉ ABSOLUE de refactoriser le code.
En ingénierie logicielle, il faut être sage pour trouver le juste équilibre entre effort et qualité. La qualité peut être infinie, mais le coût aussi. Personne ne conteste que le code actuel pourrait être amélioré. Tu me comprends ? C’est plus une question de COÛTS RÉELS.
Salutations ! Et bonne entrée dans l’année !
Sergi
Je comprends. Mais je vois surtout un problème d’attrait de développeurs. Je trouve dommage que la communauté attende de recevoir de l’argent pour moderniser le core.
Tant que dolibarr n’aura pas un V digne d’un MVC, ce sera difficile d’attirer des dev front-end. Il y aurait pourtant de belles choses à faire en pure PHP si la communauté se donnait la peine de faire évoluer leur outil de travail.
Pour en revenir à l’installation de thème. Je pense qu’il faudrait le même système d’installation que les modules mais dans la section affichage. Ce serait plus logique. Cependant, je n’ai pas étudié la façon dont sont conçus les thèmes actuellement. Donc, je ne sais pas si c’est faisable.
Actuellement, pour installer un module, il faut qu’il contienne un descripteur. Développement module - Dolibarr ERP CRM Wiki
Je ne sais pas s’il est possible de créer un module de thème dans l’état actuel de dolibarr. À creuser.
Installer un thème est la chose LA PLUS SIMPLE DU MONDE : il suffit de placer les fichiers du thème (principalement du CSS, bien que généré avec PHP pour pouvoir prendre en compte les variables de configuration de l’utilisateur comme la couleur ou la taille de la police) dans le répertoire « /htdocs/themes ».
Actuellement, la seule façon de réaliser cette opération est de se connecter au serveur par FTP, SSH ou via un explorateur de fichiers dans le navigateur… et il serait tellement facile et pratique qu’il y ait simplement un onglet du type « Installer un thème » où il suffirait d’indiquer le fichier ZIP du thème !!
J’aime ta suggestion : placer cet onglet d’installation du thème à côté de l’onglet d’administration où l’on choisit le thème pour l’instance ! Très bonne idée
D’ailleurs, en ce qui concerne la difficulté d’apporter ces changements dans l’architecture de Dolibarr pour la question du MVC (et d’autres « détails » en suspens), ce n’est pas une question « simplement » de « la communauté » (de manière abstraite) travaillant « gratuitement ».
Ce jugement de ta part est courant chez beaucoup de personnes « nouvellement arrivées » dans le monde de l’OPENSOURCE. La « communauté » que tu imagines n’est pas un ensemble de « personnes ayant beaucoup de temps libre à offrir pour rendre le monde meilleur ». Certains le sont, en particulier les plus jeunes. Cependant, la plupart d’entre nous sommes soit des personnes avec une famille qui doivent gagner un certain revenu chaque mois pour payer les factures, soit des entreprises PME de développement ou de conseil à des clients qui ont des EMPLOYÉS et qui doivent également payer des SALAIRES.
Ainsi, le modèle de développement de l’OPENSOURCE n’est pas quelque chose de « facile » et encore moins GRATUIT !! Peut-être que beaucoup de personnes qui téléchargent simplement le logiciel ou qui de temps en temps collaborent en aidant d’autres utilisateurs sur les forums, ou en apportant un « petit FIX » pour un bug sur Github, pensent cela. Mais le gros du travail (le noyau de Dolibarr et les modules tiers) est développé sur la base de NOMBREUSES HEURES DE TRAVAIL par des gens qui ont besoin d’argent en retour… non pas par « égoïsme »… simplement parce que c’est notre travail.
Cela signifie finalement que l’opensource est un modèle de « développement partagé par des gens ayant des intérêts similaires et qui vont tirer un bénéfice de son utilisation », mais aucun d’entre nous n’attend que les autres travaillent « gratuitement », haha.
Je sais que tu ne demandes pas cela. Mais je pense qu’il est nécessaire de souligner le fait que ce contexte de développement n’est pas « triste » comme tu l’as qualifié… au contraire : c’est une belle collaboration de type GAGNANT-GAGNANT !
.
