Bonjour,
On est d’accord qu’avec la modification, nos boutons que nous avions inséré ne fonctionne plus ?
Oui les boutons mis en place sur la page des équipements du plugin avant que ce soit géré par le core ne fonctionnent plus car la fonction est passée de core/js/plugin.template.js à desktop/js/plugin.js.
La PR plus haut faisait que c etait deja géré par le core.
Je reste sur l idee que ca reste interessant de laisser la possibilité aux dev qui le souhaitent (et qui l ont deja implémenté !) d avoir un bouton sur la page des equipements.
Un des gros problèmes du gros bouton sur la page des équipements est relatif aux marques blanches qui ne doivent faire aucune référence à Jeedom dans certains cas… Non ce n’était pas géré par le core mais par les plugins étant donné que c’était dans plugin.template.js.
Bonjour,
Je reste sur la même idée que @tomitomas, ca rend le bouton plus accessible sur la page des équipements. l’avoir sur la page de config est un plus pour les dev qui implanterai pas celui-ci.
2 « J'aime »
Donc on va finir par reposer les questions initiales… qu est ce qui empeche a chaque developpeur d implementer lui meme la fonction js qui va bien et donc qui de toute facon ne repondra pas a ta problematique …!?
Et rien ne vous empeche de masquer le bouton via css dans les cas qui vous « ennuient » puisqu il doit etre identifié par data-action="createCommunityPost" pour fonctionner. Donc facilement identifiable via css
Franchement je pige pas quel est le problème, il suffit d’ajouter le bouton de config du plugin sur la page des équipements et c’est accessible en 2 clics.
Pis si on part dans cette idée on ajoute aussi un bouton pour accéder au support alors ? A mon sens ce n’est pas une fonctionnalité primordiale je suis loin d’être convaincu de l’intérêt d’avoir un gros bouton sur la page des équipements juste pour ouvrir un sujet sur le forum.
Je ne comprends pas non plus quel est ton probleme pour avoir un bouton sur la page des equipements 
Quand j ai fait ma proposition en juillet dernier, ca avait l air d interesser un certain nombre et ne pas poser de probleme (la PR a ete accepté!) a ce moment la.
Qu est ce qui a changé en 7 mois pour que ca devienne genant …?
La comm sur le fait que Jeedom soit plus ouvert et « collaboratif » …?
Visiblement plusieurs autres personnes ne sont pas de ton avis, et sont convaincus du contraire aussi.
Apres tout pourquoi ne pas simplement laisser le choix au developpeur…!?
→ là aussi je ne comprends pas ce qui gene
Ma proposition initiale etait justement que tout soit intégré au core pour eviter que chaque developpeur fasse sa tambouille de son côté et que ca fasse des trucs differents a droite a gauche, ainsi que ca soit plus facilement gérable …
(Et cote support vous avez, j en suis sur, deja tout un tas d infos sur l installation sur laquelle l utilisateur demande une action. Contrairement au community où nous n avons aucune info…)
Bref … je ne vais pas lancer un debat de persévérant…
Il n’y a pas de problème vu que ça a été intégré au core directement pour tous les plugins sans avoir besoin de les modifier ! D’autre part j’explique bien qu’il existe un souci potentiel pour les marques blanches avec la présence de ce bouton sur la page des équipements.
La fonctionnalité est là sans être invasive, n’alourdit pas inutilement le code et la présentation de desktop/php/ID_PLUGIN.php. La page de configuration du plugin ne charge pas plugin.template.js, on ne va quand même pas dupliquer la fonction juste pour quelques plugins qui voudraient ajouter ce bouton alors qu’il y a un lien direct dans la conf du plugin, si ?
Qui peut etre géré via css non !?
Avec tes yeux a toi
Visiblement d autres ne sont pas de cet avis, encore une fois.
Non c est ce que je dis : laissons chaque developpeur dupliquer ce qu il faut dans son propre plugin.
C est quand meme + pratique et intelligent 
Tu te rends bien compte que l’équipe ne va pas s’amuser à mettre en place des rustines en CSS alors que tout est déjà prévu :
Et oui, si des devs veulent s’amuser à dupliquer une fonctionnalité déjà présente dans le core c’est leur choix, en tout cas le core le permet nativement tout en restant dans la philosophie Jeedom.
A moitié hors sujet: y a moyen en php de savoir qu’on est sur un jeedom vanilla ou marque blanche?
Et du coup des recos qu’on pourrait ajouter dans la doc dev pour ce point? Ou le « demo mode » qu’on voit dans certains tests? Je dois dire que j’ai jamais regardé ces points
Pour les marques blanches c’est config::byKey('mbState') à 1.
Vanilla, tu parles bien pur js avec jquery désactivé ? Si oui c’est config::byKey('core::jqueryless') à 1.
Pas vraiment de recommandation car c’est le core qui se doit de gérer ces points à condition que le plugin template ne vienne pas empiéter dessus vu que les plugins se basent dessus.
Le mode démo c’était quand y’avait des Jeedom de démo accessible en ligne, je ne sais pas si c’est toujours d’actualité.
Non pour moi vanilla c’est version « original » / « pure » autrement dit pas la marque blanche mais la version « jeedom »
Et effectivement même principe pour le js mais je parlais bien de jeedom ici.
Donc ici c’est uniquement la config mbState à prendre en compte (perso ca fait des années que je met un lien vers les sujets community dans la page équipements et dans la doc)
D’où ma question s’il y a des recos à suivre ou du moins conseillées
<Retiré>
Perso je ne suis pas satisfait du mode de fonctionnement du bouton du core, j’ai donc recodé le mien pour une future version : add jMQTTCommunityPost · BadWolf42/jMQTT@422ab32 · GitHub
Resultat :
En plein dans le mille, j’explique que pour les marques blanches ce bouton qui renvoi sur le forum est une vraie plaie pour l’équipe et bim !
Sinon, il existe déjà une fonction à intégrer à la classe de ton plugin pour ajouter des infos.
Hello Salvialf,
Alors non, tu annonces que c’est pas bien, mais tu n’expliques pas en quoi, ni ce que sont les OEM.
Les « marques blanches » utilisent les plugins tiers ?
A date, mes plugins ont été conçus pour Jeedom, pas sur d’autres systèmes.
Toute la documentation, les captures, les infos font référence explicitement à Jeedom.
Sinon, pour descendre d’un cran, il est question d’une « future version », même pas encore une beta.
Rien n’est encore acté, avec les bonnes explications, rien n’est définitif.
Bad
Ca rejoint un peu mon edit qui est peut-être passé inaperçu
On savait déjà plus ou moins qu’il y avait des marques blanches (suffit de voir la version « freebox » qui est une marque blanche light) mais je n’ai jamais vu de recommandations ou conseils pour les devs tiers.
Rien que pour les docs c’est un soucis non? Les plugins officiels aussi redirigent vers la doc jeedom.
Il y a un soucis sur le plugin-freebox_os si je te comprends bjr @Mips
Je suis prêt à corriger mais je ne vois qui est faux
Non les boutons de redirection sont dans une condition :
if (jeedom.theme.mbState == 0)