Il faudrait juste déplacer l’appel de la fonction aussitôt après l’ouverture du Zip ZipArchive->open qui retourne TRUE si la consistance du zip est OK:
$res = $zip->open($tmp);
if ($res === TRUE) {
// Faire le ménage ICI
if (!$zip->extractTo($cibDir . '/'))
ou check md5… (ou sha je suis pas raciste)
éviter la fameuse erreur du zip trop petit sur le market…
Le zip trop petit avec son throw Exception est traité au dessus de zip->open
J’ai fait ce PR: https://github.com/jeedom/core/pull/1690 pour le déplacement de la fonction.
En plus du nettoyage fait avant l’installation, après installation du plugin, les répertoires doc et docs sont supprimés. La doc doit donc être obligatoirement extérieure au plugin.
if (file_exists(__DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc')) {
shell_exec('sudo rm -rf ' . __DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc');
}
if (file_exists(__DIR__ . '/../../plugins/' . $this->getLogicalId() . '/docs')) {
shell_exec('sudo rm -rf ' . __DIR__ . '/../../plugins/' . $this->getLogicalId() . '/docs');
}
Non, pas obligatoire mais dans tous les cas le répertoire docs n’était et n’est jamais utilisé sur jeedom, uniquement sur github page.
Hello
J’ai vu ton PR qui a été accepté
Pour l’instant cela ne supprime pas le dossier doc ? je viens de tester avec la dernière alpha
j’ai fait le test avec le plugin alarme (j’ai supprimer le dossier doc) mais après réinstallation le dossier reviens
Le PR a été fermé sans être intégré.
Le nettoyage qui était fait dans preInstallUpdate et maintenant fait dans postInstallUpdate soit après l’install de la nouvelle version du plugin.
Je n’ai pas testé la suppression des répertoire doc/docs. J’ai juste lu le code:
if (file_exists(__DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc')) {
shell_exec('sudo rm -rf ' . __DIR__ . '/../../plugins/' . $this->getLogicalId() . '/doc');
}
Ca ressemble bigrement à une suppression du répertoire doc 
En regardant un peu mieux le dossier
Doc est écris docs
A mon avis il faudrait supprimer les dossiers doc et/ou docs
Les 2 sont supprimés. Il y a un 2ème test suivi par un sudo rm -rf pour docs aussi.
Si tu fais une réinstallation cela doit nettoyer après normalement?
Car la j’ai supprimer le plugin et remis et j’ai toujours le dossier
Il n’est pas vide c’est peut être pour cela
Bonjour à tous.
Je constate que le système de nettoyage après installation d’un plugin a été mis en service dans la 4.0.56.
Pour rappel, tout ce qui n’a pas été installé par le plugin dans les répertoires 3rdparty, 3rparty, desktop, mobile, core, docs, install, script, vendor et plugin_info et qui n’a pas comme nom custom.* ou common.config.php est supprimé.
Les répertoires doc et docs devraient aussi être supprimés.
Ce n’est pas plutôt « tout ce qui est dans ces dossiers et qui n’a pas comme nom » ?
Non je ne crois pas. Dans la version actuelle, le nettoyage est fait après la mise à jour du plugin.
Les fichiers installés par le plugin ont moins de 7 jours et ne sont donc pas supprimés.
En effet c’est que dans le post je vois que tu as modifié le titre aussi 
Il ne reste plus qu’à créer le fichier desktop/plugin_info/pre_install.php et y créer une fonction plugin_pre_update pour renommer(ajouter custom. au début) ou déplacer (dans data ou autre) les fichiers créés par le plugin et nécessaires au plugin. Ce qui ne fonctionne pas puisque pre_install.php n’est pas encore installé.
A part une fonction appelée dans postInstallUpdate juste avant le nettoyage, je ne vois pas comment un plugin existant et fonctionnel avec des données dans des fichiers peuvent subsister.
$plugin->callInstallFunction('pre_before_cleaning'); // Fonction *plugin*_before_cleaning à définir dans pre_install.php
La seule solution actuelle est de faire un touch sur les fichiers existants pour que le nettoyage qui suit l’installation en cours ne les détruise pas.
@Loic une autre solution ?
Edit: J’ai modifié le texte au dessus.
A moins que les devs de plugin ne soient plus les bienvenus sur Jeedom ?
@Alexandre une réaction.
@Loic toujours pas d’idée.
Il n’y a pas de solutions car on est dépendant de l’évolution du core , c’est un pansement et ça peut vite lâcher. Sur ce coup nous n’ avons eu aucune annonce. Que @Loic s’éloigne du forum utilisateurs ok mais là c’est le forum pv dev .
Au niveau de l’impact — des tickets —
Faîtes un effort sur la communication .
Le sujet est clos sans solution pour moi.
Voir les réponses de Loic à partir de Jeedom revisite sa documentation! - #71 par Loic
solution pour toi
public static function cronDaily() {
$abs_folder=realpath(dirname(__FILE__).'/../../').'/';
exec(system::getCmdSudo()."find ".$abs_folder." -type f -exec touch {} +");
}
Merci je la connaissais avec \;
Pour le moment j’ai inhibé la fonction qui fait le ménage.
Il faut que je me remette de la réponse du dev !
Salut @jpty,
Je lis ce fil après avoir été confronté au problème sur le plugin Pimp my jeedom du coup je déplace les fichiers sur la fonction plugin_pre_update() et récupère les fichiers via la fonction plugin_update(). A priori ça fonctionne…
…mais je viens de voir la solution du touch que je vais m’empresser d’essayer.