Fonction du core qui fait le ménage dans les plugins: preInstallUpdate / postInstallUpdate

Salon des Développeurs
1

Bonjour @Loic

  • Serait-il possible d’ajouter une exception supplémentaire dans les fichiers à nettoyer ?
! -iname "*_user.html"

Dans les plugins heliotrope et vigilancemeteo de @lunarok, il est possible de créer des templates utilisateur dérivées de la template fournie par le plugin. Ceci pour que les modifications faites soient conservées lors de la maj du plugin. Sinon il faudra renommer les template_user.html en custom.template.html dans les plugins.

  • Les plugins qui ont utilisés le plugin_template comme base ont un répertoire 3rparty qu’il faudrait aussi nettoyer en plus du 3rdparty

  • J’aurais préféré comme @nebz que le find soit fait avec -atime +30 plutot que -mtime +7 cela afin de réduire la perte potentielle de fichiers rarement utilisés.

Qu’en pensez-vous ?

2 « J'aime »
2

çà ressemble plus a une faute de frappe :thinking:

3

C’est dans le plugin template: https://github.com/jeedom/plugin-template
J’ai 4 rep 3rparty dans mes plugins.

4

Ah oui en effet … Ben ce serait à corriger à mon avis. Par convention c’est third party, donc 3rd party

5

En même temps que le répertoire docs du même plugin avec ses 40 fonts Roboto ?

6

Elles ne sont pas appelé par le Template ?

Il faudrait aussi migrer jquery en 3.5.1

7

En fait c’est pas 40, c’est 2 x 20. Je n’ai pas vérifié si elles étaient appelées dans la doc.
De + les Roboto sont aussi dans le core.

8

Pourquoi avoir aussi un dossier font et fonts

a priori c’est le dossier fonts avec s qui sert

Il faudrait récupérer le dossier de l’ancienne documentation qui est juste

1 « J'aime »
9

Le mieux est de sortir la doc des plugins.

10

Le dossier html/plugin_backup ne serait pas a supprimer aussi dans le core

je confirme que certain plugin ont utilisé le dossier 3rdparty et d’autres 3rparty

les fichiers avec l’extension *.md ne serait pas a supprimer aussi ?

11

@Loic a ajouté le nettoyage de 3rparty
je suppose que les réponses aux 2 autres propositions sont non et non :thinking:

12

Salut,
J’ai manqué le post p-e mais y a-t-il une explication de ce qu’un plugin doit faire (ou ne pas faire) pour éviter d’avoir des fichiers supprimés?
Y a-t-il une explication de ce nouveau mécanisme? est-il bien uniquement en 4.1 pour le moment? (pas eu le temps de vérifier le code)

13

Il a supprimé tout le dossier docs du plugin-template aussi…
enfin tous les assets; ce qui ne va pas aider les nouveaux dev à faire leur doc

2 « J'aime »
14

Oui, ce n’est qu’en 4.1
Pour la doc du plugin, c’est ici : https://doc.jeedom.com/fr_FR/dev/documentation_plugin

15

Oui mais cela renvoi vers le dossier docs du plugin template qui n existe plus

Dans cette partie, il faudrait remplacer

Note

A noter qu’une fois votre fichier info.json renseigné et pousser en version stable le site de documentation Jeedom (https://doc.jeedom.com) ajoutera automatiquement votre plugin.

par

Note

A noter qu’une fois votre fichier info.json renseigné et pousser en version stable le site de documentation Jeedom (https://doc.jeedom.com) ajoutera automatiquement votre plugin si la case
Autoriser un lien vers la documentation du plugin sur le site de doc jeedom est cochée dans le market et autorisé le compte github zoic21 à votre dépot.

il serait bien que l’on puisse accéder a ce réglage depuis le json

16

Bonjour
Ce nettoyage sera fait lors d’une mise à jour du plugin seulement ?
Il serait bien d’avoir justement des informations sur les dossiers concernés et quel nommage de fichiers permet d’échapper à la règle.

17

Tout est dans le code:

$cibDir = __DIR__ . '/../../plugins/' . $this->getLogicalId();
log::add('update', 'alert',  __('Supression des fichiers inutiles...', __FILE__));
foreach (array('3rdparty','3rparty','desktop','mobile','core','docs','install','script','vendor') as $folder) {
	if(!file_exists($cibDir. '/'.$folder)){
		continue;
	}
	shell_exec('find '.$cibDir. '/'.$folder.'/* -mtime +7 -type f ! -iname "custom.*" ! -iname "common.config.php" -delete 2>/dev/null');
}

Pour résumer, au début de la maj du plugin dans le répertoire du plugin, tous les fichiers des répertoires 3rdparty, 3rparty, desktop, mobile, core, docs, install, script, vendor qui n’ont pas été modifiés depuis plus de 7 jours sont supprimés sauf si leur nom est custom.* ou common.config.php
Edit: le répertoire plugin_info est aussi nettoyé.

Le répertoire data ( voir modif du plugin script avec le déplacement de core/ressources dans data ) n’est pas touché.

La suppression par la date de modif (-mtime) est très destructrice. Quand un fichier est au point, il n’est plus modifié.
C’est pourquoi il a été demandé de le faire plutôt par la date d’accès ( -atime)

C’est vraiment dommage que @Loic ne réponde plus !

18

Comme tout autre répertoire qu’un plugin créerait (et gérerait) lui même après l’install donc si j’ai bien lu; on est d’accord la-dessus?

J’avais la même réaction mais en fait en gros ici sont visés tous les répertoires en principe livrés avec un plugin et donc tous les fichiers d’un plugin seront recopiés depuis l’archive lors de l’update donc c’est bon non?
De nouveau, un plugin créant un fichier dans un de ces dossiers « officiels » après installation serait impacté mais si on créé les fichiers ailleurs c’est ok.

19

Par contre, si on prend la logique de nettoyage des fichiers, je ne comprend pas pourquoi les répertoires plugin_info et resources ne sont pas dans la liste? :thinking:

20

Oui

Pour le reste, je pense que l’on peut trouver des contre exemples avec des plugins qui lors d’une réinstallation serait nettoyés. Mais peut-être qu’une reinstall n’est pas une maj.