La librairie historique de SPIP PclZip possédait une option PCLZIP_OPT_REMOVE_ALL_PATH. Cela permettait de mettre tous les fichiers à la racine du zip, même s'ils étaient dans des dossiers différents.
Il n'y a plus cette possibilité avec la classe Archiviste (sauf erreur de ma part), et il faut passer par des copies préalables / liens en durs des fichiers.
La méthode emballer() possède bien une option racine mais cela concerne l'emplacement de départ des fichiers, pas l'emplacement d'arrivé.
La librairie historique de SPIP PclZip possédait une option `PCLZIP_OPT_REMOVE_ALL_PATH`. Cela permettait de mettre tous les fichiers à la racine du zip, même s'ils étaient dans des dossiers différents.
Il n'y a plus cette possibilité avec la classe Archiviste (sauf erreur de ma part), et il faut passer par des copies préalables / liens en durs des fichiers.
La méthode `emballer()` possède bien une option `racine` mais cela concerne l'emplacement de départ des fichiers, pas l'emplacement d'arrivé.
typiquement lorsque tu zip des documents issus de la mediathèque, tu n'a pas forcéement envie d'avoir cela par type (et à fortiori si par ailleurs tu utilise hash document).
typiquement lorsque tu zip des documents issus de la mediathèque, tu n'a pas forcéement envie d'avoir cela par type (et à fortiori si _par ailleurs_ tu utilise hash document).
Sinon, effectivement emballer() prend un tableau de chemins ['chemin/source.ext']
qu’il va recopier.
Peut être qu’il pourrait accepter un format ['chemin/source.ext' => 'chemin/dest.ext'] permettant de renommer ou mettre à plat les fichiers, par exemple avec ->emballer['chemin/source.ext' => 'source.ext'])
Ou qu’il y ait une autre fonction pour cela.
Tu peux mettre le lien vers le code actuel ?
Sinon, effectivement `emballer()` prend un tableau de chemins `['chemin/source.ext']`
qu’il va recopier.
Peut être qu’il pourrait accepter un format `['chemin/source.ext' => 'chemin/dest.ext']` permettant de renommer ou mettre à plat les fichiers, par exemple avec `->emballer['chemin/source.ext' => 'source.ext'])`
Ou qu’il y ait une autre fonction pour cela.
Ce que j'ai commis hier (puisque je devais adapter le plugin à la nouvelle librairie)
https://git.spip.net/spip-contrib-extensions/zippeur/commit/6d5d5b89092512281b8a608adbfaa365aa6b9236
ce qui correspond à https://git.spip.net/spip-contrib-extensions/zippeur/pulls/1/
Ce qu'on avait avant
https://git.spip.net/spip-contrib-extensions/zippeur/src/branch/master/zippeur_fonctions.php#L115-L134
et la doc https://contrib.spip.net/Zippeur
Et oui, ce serait pas mal d'avoir ca. Mais attention actuellement si j'en crois le PHpDoc la fonction accepte deja un tableau avec clés, donc risque de casse :(
Et oui, ce serait pas mal d'avoir ca. Mais attention actuellement si j'en crois le PHpDoc la fonction accepte deja un tableau avec clés, donc risque de casse :(
J'ai peut-être une piste. A priori, elle ne casserai pas la compatiblité ascendante. Il faut que je creuse ça, que je fasse des tests, mais ça pourrait marcher pour la version 2.2 (SPIP4.2) et la future 3.0 (SPIP5.0). Il faut aussi que ça fonctionne avec les Tar.
J'ai peut-être une piste. A priori, elle ne casserai pas la compatiblité ascendante. Il faut que je creuse ça, que je fasse des tests, mais ça pourrait marcher pour la version 2.2 (SPIP4.2) et la future 3.0 (SPIP5.0). Il faut aussi que ça fonctionne avec les Tar.
La librairie historique de SPIP PclZip possédait une option
PCLZIP_OPT_REMOVE_ALL_PATH
. Cela permettait de mettre tous les fichiers à la racine du zip, même s'ils étaient dans des dossiers différents.Il n'y a plus cette possibilité avec la classe Archiviste (sauf erreur de ma part), et il faut passer par des copies préalables / liens en durs des fichiers.
La méthode
emballer()
possède bien une optionracine
mais cela concerne l'emplacement de départ des fichiers, pas l'emplacement d'arrivé.Mais à quoi cela sert ?
Pourquoi réintroduire cela ?
typiquement lorsque tu zip des documents issus de la mediathèque, tu n'a pas forcéement envie d'avoir cela par type (et à fortiori si par ailleurs tu utilise hash document).
Tu veux dire que tu as un code perso qui fait cela ?
Ce n’est pas dans le plugin Médiathèque par défaut ?
Non c'est le plugin zippeur (qui existe depuis pf... longtemps).
Tu peux mettre le lien vers le code actuel ?
Sinon, effectivement
emballer()
prend un tableau de chemins['chemin/source.ext']
qu’il va recopier.
Peut être qu’il pourrait accepter un format
['chemin/source.ext' => 'chemin/dest.ext']
permettant de renommer ou mettre à plat les fichiers, par exemple avec->emballer['chemin/source.ext' => 'source.ext'])
Ou qu’il y ait une autre fonction pour cela.
Ce que j'ai commis hier (puisque je devais adapter le plugin à la nouvelle librairie)
6d5d5b8909
ce qui correspond à spip-contrib-extensions/zippeur#1/
Ce qu'on avait avant
https://git.spip.net/spip-contrib-extensions/zippeur/src/branch/master/zippeur_fonctions.php#L115-L134
et la doc https://contrib.spip.net/Zippeur
Et oui, ce serait pas mal d'avoir ca. Mais attention actuellement si j'en crois le PHpDoc la fonction accepte deja un tableau avec clés, donc risque de casse :(
Ah bah non je peux pas faire ce que je pensais, vu que emballer ne fonctionne qu'une fois.
J'ai peut-être une piste. A priori, elle ne casserai pas la compatiblité ascendante. Il faut que je creuse ça, que je fasse des tests, mais ça pourrait marcher pour la version 2.2 (SPIP4.2) et la future 3.0 (SPIP5.0). Il faut aussi que ça fonctionne avec les Tar.