Voici les informations sur mon nouveau plugin :
Bonjour,
Vous êtes au courant que l’éducation nationale a poursuivi le dernier développeur de ce plugin ?
Bonjour,
As-tu vérifié ce problème avec les éditeurs ?
Oui, j’ai regardé ce point mais je vois aussi beaucoup de plugin maintenus autour de pronote.
De plus, il publie toutes les infos concernant l’API.
Donc je pense que depuis leur politique a du changer.
J’ai lu qu’il fallait annoncer le ports pour son plugin.
Je choisi pour le moment le port 55369 cela arbitraire et l’usager pourra le changer.
Est ce le bon endroit pour le signifier ?
Je pense pas que ça serve ici, perso pour tous mes plugins j’utilise un port aléatoire choisi et testé au lancement du démon:
public static function getFreePort() {
$freePortFound = false;
while (!$freePortFound) {
$port = mt_rand(1024, 65535);
exec('sudo fuser '.$port.'/tcp',$out,$return);
if ($return==1) {
$freePortFound = true;
}
}
config::save('socketport',$port,'unifi');
return $port;
}
Salut @nebz,
C’est bien comme méthode, mais n’est ce pas un peu dangereux ?
En effet, si ton démon est le dernier à démarrer tout va bien, mais si c’est le premier qui démarre, les ports ne sont pas encore utilisés et il y a un risque qu’il tombe sur un port qui va être réclamé par un autre plugin qui démarre juste après non?
Bonne journée,
TiTidom.
si tout le monde fait comme ça il y aura pas de problème 
et sinon la chance qu’il y ait un conflit est extrèmement faible.
en choisissant son port, j’ai déjà eu des problèmes avec d’autres plugins, tant que le core gère pas ça, je vois pas d’autres moyen de le faire proprement
j’ai vu des commits dans le core alpha dans ce sens, donc la question sera bientot réglée je pense (en 4.5 probablement)
Je rajouterais que pour un démon auquel l’utilisateur doit accéder via une interface (type zigbee2mqtt ou tgw ou autre), ça a du sens de choisir un port et de le garder. par contre pour un port « technique » dont l’utilisateur n’en a cure, il vaut mieux qu’il soit aléatoire
Re,
Alors pour préciser, je la trouve très bien ta méthode, mais comme tu le précises, il faudrait que tout le monde fasse pareil y compris les plugins officiels.
Ou bien réserver une plage pour les plugins officiels, et une autre plage pour les plugins tiers, et dans cette plage de plugins tiers utiliser ta méthode (avec peut être une possibilité de débrayer cet automatisme s’il y a un soucis par exemple, genre une option type case à cocher dans chaque plugin qui dirait : « c’est en automatique, mais au cas où possibilité de le débrayer »)
On est tout à fait d’accord, pour moi il devrait y avoir dans le core une fonction genre ‹ getDaemonPort › d’attribution du port du démon avec une table (ou autre) qui référence ceux utilisés.
Une autre solution serait par exemple, d’attribuer une plage (de 50 ports par exemple) à chaque dev qui en fait la demande (donc qui a besoin d’un démon), et qu’il y ait un post dans la zone dev du Community qui référence cela, cela pourrait être une solution à court terme assez simple à mettre en place (comme on le fait par ailleurs par exemple pour référencer les plugins qui fonctionnent dans telle ou telle version de Debian)
Bref, il y a pleins de solutions, mais j’ai toujours trouvé dommage qu’il n’y ait pas un référencement, quel qu’il soit, c’est vrai que lorsqu’on arrive en tant que dev et qu’on se dit « ah mince, quel port je vais utiliser 
» on est bien perdu au départ 
Au plaisir,
TiTidom.
Mais comme je disais c’est prévu déjà dans la core pour la prochaine version
OK voila un bonne nouvelle, e reste donc sur un port fixe arbitraire et paramétrable.
On verra après la mise à jours.
J’en profite, pour enfoncer une porte, la documentation pour le développement de plugin est à mettre à jour.
Tu as raison @Mips, le fait de découvrir me rend le pieux placer pour pointer du doigt les erreurs, et de proposer un update de cette documentation.
J’ai devant moi quelques jours pour mener à bien le projet de plugin en sujet.
Mais je vais prendre ce point en taches de fond.
Dans mon plugin, je cherche à créer un bouton de ce type :
<‹ a class=« btn btn-sm btn-success » data-action=« test »> {{Valider}}</a ›>
J’aimerais qu’il exécute la fonction PHP publique UpdateInfoPronote(« Test »)
Je me doute que cela est possible, mais il me manque un petit quelque chose sur lequel je ne met pas le doigt.
Salut,
En règle générale on bind un event js sur le click.
Ce js va faire un call ajax vers ton plugin qui pourra appeler une fonction de ta class eqLogic et renvoyer une réponse
Je ne me rappelle pas si le plugin template contient un exemple type mais plusieurs plugin officiel gratuit oui