Meme l’espace de stockage faut eviter aussi, je suis bien conscient que ya des soucis sur la v4 et que c’est pas facile pour vous l’équipe Jeedom est dessus et derriere vous pour aider un maximum (la preuve je bosse autant que d’habitude alors que je suis en vacance…) mais faut virer ce plugin.
Ya pas de souci. Je termine l’adaptation à la v4 des 2 derniers widgets qui restent et je supprime le plugin.
Mais je n’avais 1500 cmd avec des widgets perso comme @Nemeraud.
Ce n’est pas qu’une requête SQL, il faut aussi comparer avec la liste des fichiers présents dans data/customTemplates.
Ça donne un script que je n’ai pas.
Ça existait dans le plugin widget en v3. Dans la liste des widgets sur la gauche, il y avait pour chaque widget son nombre d’utilisation.
je suis désolé mais j’ai pas la même vision
suite à la migration, par défaut les commandes pointent vers le PLUGIN WIDGET et s’affichent correctement en effet mais l’info dans le template n’est pas bon, il affiche donc DEFAUT quand on veut voir l’affection du widget à la commande
+> cela se corrige dans la base SQL en modifiant « custom » par « widget »
mais dans ce cas, on pointe vers le PLUGIN WIDGET ce que l’on ne veut pas
Il faudrait donc, modifier dans la base le « custom » en « customtemp »
ca fonctionne pour l’affichage du widget mais là aussi l’affectation dans l’affichage de la commande n’est pas correcte, indique « DEFAUT », car tous les widgets qui ont été copiés dans la nouvelle arbo DATA ne sont pas connus par jeedom et même en faisant NOUVEAU dans la partie CORE, et en mettant le même nom qui est affichié dans le nom long, exemple « cmd.info.numeric.progressBar.html », je nomme mon nouveau widget « progressBar », le nouveau widget, d’apparait pas dans la partie CUSTOM si on veut l’affecter à une commande, alors que si je fais NOUVEAU que je mets un nouveau nom « progressBarNew » et que je colle le code, là ca fonctionne mais ca oblige a refaire de nouveau widget, il y a donc bien un soucis dans cette partie là
Il faut supprimer les anciens fichiers du plugin widget s’ils portent le même nom. Sinon le nouveau n’apparait pas pour affectation.
Je viens de pousser une correction pour les prochains qui vont faire le passage ou effectivement je mettais custom:: au lieu de customtemp::
1 « J'aime »
tu veux que je restaure et que je test ?
ok merci
donc il suffit de supprimer le plugin widget, en ayant fait le changement dans le base, tout va rester comme avant
A vérifier si la suppression du plugin widget résout tout après modif de custom:: en customtemp:: dans la bdd.
Vous avez écrit au dessus:
ca fonctionne pour l’affichage du widget mais là aussi l’affectation dans l’affichage de la commande n’est pas correcte, indique « DEFAUT »
defaut ca apparait si il trouve pas le widget dans la liste et en custom::XXX il le trouvera jamais alors que en customtemp::XXX il devrait
oui ca semble bon, j’ai des widgets du CODE qui sont apparu après avoir fait une suppression dans le plugin widget
Il vous restera à traiter les chemins en absolu dans les fichiers pour par exemple les images.
Exemple dans le widget qu’il me reste à traiter:
var imgPath = 'plugins/widget/core/template/dashboard/cmd.info.numeric.Signal_IMG/';
1 « J'aime »
je viens de passer toute la base en « customtemp », ceux qui étaient en « widget »
j’ai supprimé le plugin WIDGET
j’ai renommé à la volé (357 lignes modifiées)
plugins/widget/core/template => data/customTemplates
et tout semble OK
quelques correction à faire, de mémoire la gestion de l’affichage du NAME qui change
<span class="cmdName" style="font-weight: bold;font-size : 12px; #hideCmdName#">#name_display#</span>
devient
<div class="title #hide_name#">
<div class="cmdName">#name_display#</div>
</div>
d’ailleurs ca m’arrange pas trop, on peut pas faire uniquement ?
<div class="cmdName #hide_name#">#name_display#</div>
il y a un moyen pour relancer la cache des images, j’ai du vider le cache du navigateur et les images ne s’affichent que si je resauvegarde la commande
un petit moteur de recherche est prévu dans la partie CODE ? stp @Loic 
c’est vrais que c’était pratique d’avoir le nombre de commande affilié au widget, Excel devrait faire le nécessaire
Non la partie code n’evoluera pas désolé on encourage pas du tout son utilisation car lors de changement comme la en v4 c’est la misere pour nous et nous a fait perdre au bas mot plusieurs milliers d’heure.
Ça reste quand même un widget v3 ( ou moins) avec plein de déf de style alors qu’en v4 il y a des class CSS. Ca va donner par exemple des textes de hauteur diff entre vos widgets et les widgets core.
Class de nom différent:
Ex: widget v3 en v4 
Quand je modifie, j’essaie de repartir d’un widget core v4 et faire l’adaptation
oui, c’est aussi ce que je pense faire
tout ce que je peux passer en CORE, en TEMPLATE et en WIDGET CODE Adapté
mais sans stress, car pour le moment, tout s’affiche plus ou moins correctement
merci à tous
c’est quoi cette erreur sur la page CODE ?
200 : SyntaxError: Unexpected end of JSON input
il n’y a pas de moyen pour forcer le « name » ou « display_name » dans un template ?
Ben si tu mets #name# dans option ou name je sais plus et la valeur que tu veux