Affichage page configuration modules TRES lente (>40s)

Re

Oui ou dans la page existante des modules une case à cocher pas cochée par défaut, qu’on coche unqiuement quand on veut checker les versions.
Vraiment pas compliqué à coder ça, si j’ai 30min pour faire un PR …

j’ai 40 modules à modifier si cela te chante… pas juste un PR…

Bah sauf si dans /admin/modules, on modifie les appels getVersion
if ($casecoche) {
$version = $objMod->getVersion(xx);
} else {
$version = $objMod->version;
}
Un peu sauvage certes, mais efficace à priori

yaka lol
on se demande bien pourquoi on a mis en place une fonction getVersion…

le code en question sur mes modules :

// skip check version of our modules
if ($action == 'patasMonkeySkipCheckVersion') {
dolibarr_set_const($db, "PATASMONKEY_SKIP_CHECKVERSION", GETPOST('value'), 'chaine', 0, '', $conf->entity);
}
$patasMonkeySkipCheckVersion=!empty($conf->global->PATASMONKEY_SKIP_CHECKVERSION);
print '<table class="noborder" width="100%">'."\n";
print '<tr class="liste_titre">';
print '<td width="20%">'.$langs->trans("PatasMonkeySkipCheckVersion").'</td>';
print '<td>'.$langs->trans("InfoPatasMonkeySkipCheckVersion").'</td>';
print '<td width=100px align=left>';
if ( $patasMonkeySkipCheckVersion == 1) {
print '<a href="'.$_SERVER["PHP_SELF"].'?action=patasMonkeySkipCheckVersion&token='.newToken().'&value=0">';
print img_picto($langs->trans("Enabled"), 'switch_on').'</a>';
} else {
print '<a href="'.$_SERVER["PHP_SELF"].'?action=patasMonkeySkipCheckVersion&token='.newToken().'&value=1">';
print img_picto($langs->trans("Disabled"), 'switch_off').'</a>';
}
print '</td></tr>';
print "</table>";

De toutes façons, cela ne résoud pas le ralentissement pour d’autres modules manifestement, donc pas de solution même sauvage
Là je teste sur un hébergement mutualisé type OVH et c’est très pénible (et ça ne vient pas des modules Patas puisque j’ai mis la cste PATASMONKEY_SKIP_CHECKVERSION =1)

Hello all,
c’est un peu dans ce sens que j’avais proposé ça il y a quelques temps : CAP-REL / dolibarr / moduleVersion · GitLab qui me semblerait être une bonne piste …

Mais la meilleure solution serait que dolibarr fasse une seule requête sur dolistore pour récupérer tout simplement une liste de tous les modules dispo avec leur numéro de version

soit sous la forme d’un bon vieux « format à la CSV »

module:1.0.1
toto:1.0.54
tata:15.0.25

soit du json ou du yml peu importe mais ça serait un service rendu par le dolistore que ça me semblerait assez normal …

… et actuellement le changelog des modules créer avec le générateur de module natif sont au format md… bon courage pour le parser et l’analyser…

Pour ma part je suis partie sur du xml dans mes modules, mais le format n’est vraiment pas une contrainte, mais je ne sais pas ou il serait bon de conserver les changelog des modules, et le dolistore n’est vraiment pas à mon sens une solution pérenne car cela oblige de diffuser sur cette plateforme tout les modules si on veux suivre les versions (sans parler que l’on risque d’avoir un jolie DDOS si tous le monde se crée des outils de scrapping sur ce dernier)

Une remarque cependant, chaque module doit avoir un numéro de version unique, à préciser dans le fichier mod…class.php , cela pourrait servir de clé d’accès au changelog conserver quelque part

je peux proposer mon bout de code de gestion du changelog en xml si jamais, ce n’est pas la panacée mais je doute que l’on puisse pour le moment trouver mieux…

Sauf erreur de ma part, la page dolibarr qui liste les modules n’a besoin que de savoir quelle est la dernière version disponible pour l’afficher à l’administrateur non ?

Le changelog n’est pas nécessaire à cette étape il me semble … donc pourquoi alourdir la charge utile ?

Au niveau du dolistore ça serait à mon avis TRES facile d’avoir un fichier d’index qui liste les modules + version vu que l’information est dans la BDD de dolistore et de mettre ce fichier accessible sur une url directe.

N’ayant pas connaissance de tous les id de tous les modules je me suis limité à ma liste de mes modules sur le code proposé sur le dépôt git pointé dans mon message précédent.

Si on cherche à optimiser le dolistore pourrait faire un fichier d’index à partir de sa bdd, stocker ce fichier sous la forme d’un fichier plat dans son arborescence publique et c’est tout. C’est ce que fait le code que j’ai proposé … avec un rafraîchissement automatique du cache.

De là à imaginer un DDOS je ne vois pas du tout la différence avec un DDOS sur https://dolistore.com/ tout court …

Sur la page des modules, les changelog sont affichés dans le mini popup quand on clique sur le petit icône (i) ou (?) en haut à droite des modules complémentaires.

Oui mais ça ne télécharge le fichier que lorsqu’on clique sur l’onglet « ChangeLog » non ? /admin/modulehelp.php?id=xxxx&mode=changelog

Tiens je vais aller lire le code de cette partie de dolibarr moi :slight_smile:

Bon courage pour t’y retrouver dans le code.

Depuis que j’ai commencé à me plonger dans le code, je suis horrifié toutes les 10 lignes et j’envoie pour l’instant des micro-patchs. Étant habitué du code propre avec Django, je reviens 20 ans en arrière avec Dolibarr.

Je trouve aussi des aberrations logiques dans certains modules complémentaires.

Arf, vu que mes 1eres contribs remontent à y a ~20 ans je ne suis pas trop perdu :smiley: mon bagage est plus structuré par Laravel depuis des années mais pour en revenir à dolibarr c’est ce qui fait son charme.

J’ai regardé LARAVEL, c’est un bordel aussi. J’ai piraté en moins de 45 minutes une appli LARAVEL. Le dev peut rapidement provoquer des failles de sécurité (comme dans tout ce qui est PHP de toute façon). Aucune gestion réelle des migrations des bases de données, il faut tout lui dire. Sur Django, il se démerde à migrer les bases et à contrôler les données, le code est propre, et seulement dans 1% des cas, il faut l’aider un peu.

L.O.L. … pfffffff allez on respire un coup et ensuite on essaye d’expliquer ou bien c’est même pas la peine ? dans le développement l’outil n’a jamais fait la qualité du produit.

Il y aura toujours des bouses quel que soit le langage et inversement. Il y aura toujours des cas particuliers et svp ne faites pas de généralités, ça n’apporte rien… et ça ne grandi personne.

Quel que soit le framework ou la pile applicative il y aura toujours des failles de sécu et ce qui est important c’est de voir une communauté soudée pour les corriger rapidement et proprement.

Je suis très détendu hein.

Le langage lui-même, ne fait rien. Le framework utilisé peut avoir un impact pour forcer la qualité du code.

Si on prend en exemple EspoCRM (en php), le code source est propre de chez propre. L’appli est en grande partie en javascript.

Je fouille régulièrement le code source.

J’ai corrigé un micro-micro problème dans la glibc il y a quelques années, un bit mémoire consommé inutilement pour rien pendant une fraction de seconde.

J’ai corrigé un petit bug dans WP-Rocket (code en PHP très propre).

Donc oui, ça dépend des dev mais un framework bien conçu aide les devs à ne pas faire n’importe quoi et à rendre le code lisible ensuite et ne pas être obligé d’avoir un écran 1000 pouces pour réussir à tout comprendre.

Ce que je constate pour l’instant est que le niveau de développement de Dolibarr et des extensions est très moyen, dû à un historique, qu’il est difficile à faire évoluer sans risquer de le rendre non fonctionnel. :slight_smile:

pour connaitre, synfony (dont laravel emploie du code), donner des cours sur Django et coder sur dolibarr depuis plus de 10 ans, je dirais que ce n’est pas forcément le sujet de cette file (lenteur de la page de configuration).
mais je confirme que cette page, meme si elle apporte une fonctionnalité importante est codée avec des gants de boxe, rien que le fait qu’elle se rafraichisse à chaque activation de module, sa vue kaban et l’absence d’accordion pour réduire les groupes de modules …
avec la page des dictionnaires et la gestion des menus, elles sont la trinité des saletés que se traine dolibarr

Je ne suis pas certain que 1000 pouces ça soit suffisant pour afficher les fichiers de plus de 13000 lignes qu’on trouve dans le code de Dolibarr :crazy_face:

Bonjour :slightly_smiling_face:
@defrance et si vous hébergiez vos changelog sur un cdn gratuit?

quel en serai l’intérêt (à part gérer encore un truc à la con)?
mes changelogs sont sur mon serveur de démonstration chez ovh.

2 « J'aime »