Discussion :

[resus]

Bonjour
Je ne sais pas si je suis au bon endroit mais ma demande pourrait intéresser l'auteur.

Je domine assez bien PHP et MySQL et quelques notions en javascript pour des adaptations.
Mais de plus en plus de membres utilisent leur smartphone pour uploader des photos sur mes sites.
Et quand la photo est mal orientée elle s'affiche aussi dans ce format sans parler des photos qui mettent un temps fou à se télécharger avec les smartphones récents.
Ma demande*:
Je voudrais un script Jquery*qui:
• 1-télécharge la photo*;
• 2-propose une rotation*;
• 3- rogne, agrandit ou diminue la photo*;
• 4-télécharge l’image sur le serveur vers une page PHP
• 5-vérifie l’image, l’enregistre sur le disque avec son adresse dans Mysql. (non obligatoire)

J’ai trouvé celui-ci*:
https://preview.codecanyon.net/item/...546.1577029592
Très abouti et élégant en payant 59$. J’étais prêt à l'acheter mais en ajoutant les taxes et les frais de conversion bancaires, j'arrivais à 100€.*J’ai abandonné cette idée en me disant que c’était le moment d’apprendre Jquery et d'adapter un script existant.

Alors j’ai trouvé:
https://gitlab.com/tanvirfatmonk/cropme/tree/master
https://www.jqueryscript.net/other/c...e-cropper.html

Ces 2 scripts effectuent les points 1, 2 et 3
Je butte depuis plusieurs jours sur le point 4. Les 2 scripts ci-dessus donnent une image en base64 qui se trouve côté client mais je la veux sur une page php du serveur pour lui faire subir le process 5
Merci de me signaler un script qui pourrait répondre à ma demande ou si quelqu'un veut s'investir dans un code qui correspondrait au process 4
D’avance merci
JJ
PS*: Entre temps j’ai essayé UploadAjaxABCI v7.5c qui est très complet et documenté avec de multiples exemples dont UploadAjaxABCI_Redimensions_Album.php qui m’a vivement interessé. Seulement je n’ai pas vu ou su voir une fonctionnalité rotate. Dommage*!

[Invité]

@ABCIWEB
Je ne sais pas si tu as vu, mais j'ai aussi mis à jour mes Fonctions de redimensionnement d'images

• dont : V. « Rotation » de l'image

[resus]

OK je vais regarder pour voir ce que je peux faire avec et l'intégrer dans une page
Merci

[ABCIWEB]

Bonjour
Je ne sais pas si je suis au bon endroit mais ma demande pourrait intéresser l'auteur.
...
Entre temps j’ai essayé UploadAjaxABCI v7.5c qui est très complet et documenté avec de multiples exemples dont UploadAjaxABCI_Redimensions_Album.php qui m’a vivement interessé. Seulement je n’ai pas vu ou su voir une fonctionnalité rotate. Dommage*!

Bonjour,

Ce sujet est plutôt destiné à annoncer les nouvelles versions. Je vais te répondre mais ne t'étonnes pas si ton message est déplacé vers le sujet que je donne en lien à la fin de ma réponse.

Tu n'as pas vu l'option de rotation parce qu'elle est intégrée automatiquement au script javascript en se basant sur les informations EXIF. Côté Php dans le script serveur, la correction automatique se fait avec la ligne CorrectionExifJpg::filePath($fichier_complet); (toujours en se basant sur les informations EXIF) qui est déjà intégrée dans le script de création d'album photo dont tu parles (et dans d'autres exemples également).

Ce module devrait donc répondre à l'ensemble de tes besoins. As-tu essayé ?

Après oui, cela peut-être une bonne idée de faire une option manuelle pour la rotation, j'y penserai mais normalement cela se fait automatiquement pour toutes les photos de type jpg et jpeg, directement issues d'un APN ou d'un smartphone, en fonction des informations EXIF du fichier image. Mes tests ont été concluants mais je n'ai évidemment pas pu tester tous les cas de figure. Fais-moi savoir si tu as un exemple d'image pour laquelle cela ne fonctionne pas, ou si tu as une autre question, en postant un message dans ce sujet.

[ABCIWEB]

@ABCIWEB
Je ne sais pas si tu as vu, mais j'ai aussi mis à jour mes Fonctions de redimensionnement d'images

• dont : V. « Rotation » de l'image

Merci pour l'info

[ABCIWEB]

Bonjour,

Petite correction à faire dans la fonction php de renommage des fichiers.

Par défaut, en cas de doublon sur le serveur, cette fonction ajoute un suffixe unique au nom du fichier, ou en option, incrémente le fichier avec un suffixe numérique. A la fin de l'opération, une revérification de l'existence du fichier est faite par sécurité, au cas ou deux fichiers de même nom seraient téléchargés simultanément, et si besoin la fonction est rappelée.

Mais la fonction rappelée ne correspond pas au nom de la fonction appelante, c'est une erreur de transposition venant d'une fonction que j'avais créée bien avant ce module d'upload. Ce bug a toujours existé toutes versions confondues, il n'a jamais été signalé car il est extrêmement rare puisqu'il faudrait que deux utilisateurs téléchargent un fichier de même nom exactement au même instant.

Cette fonction se nomme renameIdenticName dans les versions 7.0, ou RenameIdenticName à partir de la version V4.0, et RenommeDoublon dans les versions précédentes, et elle se trouve dans le dossier "Php_Upload".
Depuis la version 7.5 elle est dans le fichier Php_Upload/Classes/UploadABCITraitServices.php, dans les versions précédentes elle est dans le fichier Php_Upload/Classes/UploadABCIServices.php, et directement dans le fichier UploadAjaxABCIServeur.php pour les versions inférieures à 6.0.

Donc chercher l'expression Rename_fich (c'était le nom de ma fonction initiale) à l'intérieur de la fonction et remplacez-là par le nom de votre fonction en respectant la casse (majuscules/minuscules). Les paramètres qui sont au nombre de 4 ou 5 suivant les versions, doivent rester identiques.
Pour les versions >= 7.0 par exemple, la ligne :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

return Rename_fich($adresse_fichier, $incr, $unix, ++$stop, true);

deviendra donc :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

return renameIdenticName($adresse_fichier, $incr, $unix, ++$stop, true);

Notez que même si vous utilisez cette fonction vous n'êtes pas obligé de faire cette correction. D'une part parce que la probabilité que ce bug apparaisse est très faible, et d'autre part, dans cette éventualité, php renverra une erreur (appel de fonction inexistante) et le visiteur sera averti que son fichier n'a pas été téléchargé, mais le fichier n'écrasera pas un fichier existant. Il n'y a donc pas de dysfonctionnement dans la protection des fichiers déjà existants sur le serveur, mais potentiellement (avec beaucoup d'utilisateurs et d'upload simultanés) un retour d'erreur inattendu mais rarissime pour le visiteur.

Ce sera corrigé dans la prochaine version.

[Never_54800]

Bonsoir tt le monde.

Tout d'abord un super grand merci ABCIWEB pour le script, il fait tt ce qu'il faut, comme il faut.

Pour la personalisation, je cherche encore certaines choses, logique. (Style passer le chemin d'upload depuis la page d'appel sans devoir la redéfinir ailleurs, ce qui permet de personaliser, mais j'y arriverai )

Je coince sur un détail tt bête, j'ai honte. J'ai regardé partout, fait des ^c ^v et tout et tout, rien n'y fait.

Pour faire simple (en explication), ce que je voudrais est de pouvoir faire comme un form classique avec "action='...php'

Je suppose que c'est avec

'Up.config.func_FormEnd'

, mais ... suis trop nul, j'y arrive pas.

[Never_54800]

Pour le submit, c'est résolu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
up.config.func_FormEnd = function()
{ form_base_controle.submit();
};

Aussi simple que l'oeuf de Colomb

Par contre, le nom de ma variable est vide

?fichier=&UpAbci_fragmentSize=104......

[ABCIWEB]

Bonsoir tt le monde.

Tout d'abord un super grand merci ABCIWEB pour le script, il fait tt ce qu'il faut, comme il faut.

Pour la personalisation, je cherche encore certaines choses, logique. (Style passer le chemin d'upload depuis la page d'appel sans devoir la redéfinir ailleurs, ce qui permet de personaliser, mais j'y arriverai )

Je coince sur un détail tt bête, j'ai honte. J'ai regardé partout, fait des ^c ^v et tout et tout, rien n'y fait.

Pour faire simple (en explication), ce que je voudrais est de pouvoir faire comme un form classique avec "action='...php'

Je suppose que c'est avec

'Up.config.func_FormEnd'

, mais ... suis trop nul, j'y arrive pas.

Tu n'y arrives pas sans doute parce que tu cherches midi à 14H. La méthode config.func_FormEnd permet d'avoir la main sur le formulaire à la fin du traitement du formulaire, c'est à dire après le traitement php. Si tu veux passer un chemin d'upload pour qu'il soit pris en compte par php, cette méthode ne t'es d'aucune utilité. Ajoute simplement un input dans ton formulaire qui contiendra ce chemin et que php pourra récupérer. C'est donc plutôt ce chapitre du mode d'emploi qu'il te faut consulter. En complément et en plus complet, il y a aussi le fichier "UploadAjaxABCI_Champs_Sup_Notation.php" qui montre plus de possibilités concernant le passage de variables inclues dans le formulaire vers php.

A noter que si tu passes un dossier d'upload depuis une variable dans le formulaire, c'est un risque majeur de piratage puisqu'un pirate pourra modifier ce dossier. A réception de cette variable, il te faudra donc contrôler en php qu'il fait partie des dossiers autorisés. Par exemple si tu inclus dans ton formulaire html un input nommé "dossier", et que tu autorises les téléchargements vers "dossier1", "dossier2" et "dossier3", il te faudra faire dans ton code php :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
$dossier = isset($_POST['dossier ']) ? $_POST['dossier '] : null; 
$erreur_dossier = in_array($dossier, ['dossier1/','dossier2/','dossier3/']));// retourne true si vrai, false si faux.
$up = new UploadAjaxABCIServeur($dossier);
// Si le dossier n'est pas inclus dans les dossiers autorisés
if (!$erreur_dossier)
{
// On sort du sript php en envoyant un message d'erreur
$up->exitStatusErreur('Dossier : '.$dossier.' non valide');
}
//...

C'est une façon de faire. Tu n'es pas obligé de renseigner la variable $dossier dans l'initialisation de la classe UploadAjaxABCIServeur, puisque tu peux aussi définir le chemin d'upload dans la fonction Transfert() mais je pense que c'est le plus simple dans ton cas de figure. Si besoin, le fichier 'Php_Upload/UploadAjaxABCI_Upload.php' (entre autre) donne des exemples de définition du chemin d'upload depuis la fonction Transfert().

Notes au passage que la variable "$dossier" passée éventuellement en paramètre à la classe UploadAjaxABCIServeur($dossier) et qui sert de dossier par défaut si aucun argument n'est passé dans la fonction Tranfert(), doit comporter un slash final, ex:'dossier1/'. Donc dans ton html tu devrais avoir un input sous la forme <input type="hidden" name="dossier" value="dossier1/">.

Si tu as d'autres questions, précises ce que tu veux faire exactement (et non pas des principes), sinon il me sera difficile de te répondre. Aussi, laisses un petit mot si ton problème est résolu, cela aidera les autres qui se poseraient la même question.

[Never_54800]

J'avoue que j'ai été un peu trop vague dans mon texte.

En ce qui concerne le dossier d'upload, personnalisé ne veux pas dire ouvert à tout vent. Ton script tournera a 3 endroits chez moi
- envois (gros) fichier pour traitement sql (mise a jour bdd)
- envois fichiers (uniquement pdf) pour partage entre utilisateurs / affiliés
- envois pdf par affilié

Donc je personnalise le chemin en fonction de, mais pas par formulaire, juste par page d'appel / utilisateur (+ arboressence, les fichiers ont renomés en ce qui concerne les pdf).
Je teste dans la journée et poste le résultat.

Pour le sumit, automatique à la sélection du formulaire, j'ai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
up.config.func_FormEnd = function()
{ 
 
form_base_controle.submit();
 
};
up.config.func_FileSelectAll = function(event,tableau){
	file_form.submit();
}

et ca tourne nickel

Me reste juste le nom du fichier uploadé qui ne revient pas dans $_POST

Array ( [hideFileID] => [UpAbci_fragmentSize] => 1048576 [UpAbci_uniqidForm] => ba48e438ab9dae1a033825a48c622fb90df8d5b1f8fc221c7363ee301d6b4ad3 [post] => [hideFileID] => [UpAbci_fragmentSize] => 1048576 [UpAbci_uniqidForm] => ba48e438ab9dae1a033825a48c622fb90df8d5b1f8fc221c7363ee301d6b4ad3 [logop] => 35 [logsub] => 44 [logutil] => 1 )

[Never_54800]

J'avance

Dans la page d'appel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<input type="hidden" name="UpAbci_uniqidpath" value=1>

(1 pour faire simple, ca sera mieux en prod :p

Dans le traitement ajax

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$UpAbci_uniqidpath = isset($_POST['UpAbci_uniqidpath']) ? $_POST['UpAbci_uniqidpath'] : null;
if ($UpAbci_uniqidpath==1) {
  $ext_ok = ['.txt','.mdb'];
  $dossier_destination = '../../doc/bdd/';
}

Et hop, d'une pierre 2 coups . Le chemin et l'extension

Plus que le nom du fichier qui revient pas apres le form_base_controle.submit();

[ABCIWEB]

Salut,

La soumission automatique du formulaire est montrée dans l'exemple n°4 du fichier d'exemple "UploadAjaxABCI.php".

Effectivement j'utilise la fonction config.func_FileSelectAll, mais pas la fonction "config.func_FormEnd" puisque comme déjà dit plus haut, celle-ci est déclenchée à la fin du traitement du formulaire, c'est à dire après le retour ajax et donc après le traitement php. Le fichier d'exemple "UploadAjaxABCI_Custom.php" donne un exemple d'utilisation de la fonction "config.func_FormEnd".

[Never_54800]

Après le traitement php de la page 'ajax' (plus simple de l'appeler comme ca pour s'y retrouver.), oui, tout à fait.

Ceci dit, j'ai du traitement a faire dans la page d'appel, comme un bete <form> quoi

Et apres le submit, je n'arrive pas a récup la valeur du <input type="file"

Je récupère tous les champs du formulaire, mais pas celui la.

Merci de ton aide

Le form d'appel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<form id="form_base_controle" action="<?php echo $modname; ?>" method="POST">
      <input type="file" name="hideFileID" accept="<?=$accept?>" data-max-size="<?=$max_size?>">
     <input type="hidden" name="UpAbci_fragmentSize" value="<?=$UpAbci_fragmentSize?>">
     <input type="hidden" name="UpAbci_uniqidForm" value="<?=$UpAbci_uniqidForm?>">    
	 <input type="hidden" name="UpAbci_uniqidpath" value=1>

Edit :

J'ajoute dans mon form

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<input type="hidden" name="ccfile">

et dans le submit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

form_base_controle.ccfile.value=form_base_controle.hideFileID.value;

et la, miracle, je recupère ma variable

[ABCIWEB]

Pourquoi ne pas faire ce traitement complémentaire dans le fichier php d'upload. Et en quoi consiste ce traitement?
Encore une fois si tu ne me dit pas exactement ce que tu veux faire, je ne pourrai pas t'aider..

[Never_54800]

- envois (gros) fichier pour traitement sql (mise a jour bdd)

ce que je voudrais est de pouvoir faire comme un form classique avec "action='...php'

J'en avais déjà fait mention

Je DOIS faire le traitement en page d'appel, et pas en ajax, car en plusieurs étape

Mais bon, ma soluce fonctionne, un super grand merci pour ton script et ton aide

[ABCIWEB]

J'en avais déjà fait mention

Je DOIS faire le traitement en page d'appel, et pas en ajax, car en plusieurs étape

Mais bon, ma soluce fonctionne, un super grand merci pour ton script et ton aide

En fait je te demandais quelles sont ces différentes étapes car il y a fort à parier que ce serait réalisable dans le script d'upload, et en même temps plus sécurisé.

Si j'ai bien compris ta façon de faire, tu reprends le nom du fichier original transmis par l'utilisateur pour le passer en bdd. Mais la plupart de mes scripts php utilisent la fonction getCleanFileName ou encore la fonction renameIdenticName qui vont renommer le fichier en cas de besoin, la première pour rendre le fichier accessible via une URL et la seconde pour le renommer si un fichier de même nom existe déjà sur le serveur, si bien que le nom du fichier enregistré sur le serveur ne sera pas nécessairement identique à celui transmis par l'utilisateur. C'est pour cette raison qu'il est plus simple de mettre à jour sa bdd depuis le script php d'upload.

De même si l'utilisateur stoppe le téléchargement d'un fichier en cours d'upolad il ne sera pas enregistré sur le serveur mais avec ta méthode il risque d'être enregistré dans la bdd. Et de même s'il y a une panne internet lors du retour de la requête ajax le fichier sera enregistré sur ton serveur mais pas dans ta bdd, alors que si tu faisais cet enregistrement dans le script php tu serais à l'abri de ce genre de panne puisque le serveur continuera son travail indépendamment de l'état du réseau.

Après il est aussi possible de transmettre dans le paramètre mixte_serveur de la fonction config.func_FormEnd le nom final des fichiers (même s'ils ont été renommés), et de savoir s'ils ont été ou non entièrement téléchargés en scrutant la propriété result du paramètre tableau de cette même fonction. Dans ce cas tu seras au moins certain d'enregistrer les bons noms de fichiers dans ta bdd, tout en étant certain qu'ils ont été entèrement téléchargés, mais cela ne te protèges pas d'une panne internet lors du retour ajax comme je le disais à fin de mon paragraphe précédent.

Pour dire qu'il y a plusieurs façons de faire mais que dans tous les cas, le plus sécurisé est de mettre à jour sa bdd dans le script d'upload pour garantir l'intégrité des données.

[Never_54800]

Il faut d'abord se dire qu'on est dans du back-office, que donc l'accès est limité.
Pour ce qui est de la synchro sql, l'accès est limité uniquement aux utilisateurs ayant un niveau suffisamment élevé dans les droits d'accès. En gros... 3 personnes dont moi.

Dans cette config, pas besoin de renommer le fichier.

Mon traitement se fait APRES l'upload (d'où le fait que je cherchais l'équivalent d'un form classique avec gestion des gros fichiers). Donc pas grave si on interrompt le process

Je ne peux pas traiter dans l'upload car, comme les données sont externes, je considère qu'elles ne sont pas fiables, et donc avant insert / update eventuel, le fichier est analysé, le compte rendu affiché. Si tout est correct, le gestionnaire peut poursuivre la synchro. Mon script supporte la panne Internet sans soucis. On parle de +/- 20K enregistrements, (cette table là faut +/- 16Mo)

Idem sur 2 tables (la seconde fait 350Mo là on ne fait que des insert après vérif).

Comme il s'agit d'une synchro mensuelle, pas grave non plus si on écrase l'ancien fichier.

Pour ce qui est de l'envois de doc par l'utilisateur, ils sont une grosse 100aine, il ne s'agit que de pdf, dont le nom réel ne sera pas celui renseigné,ce qui eviter les doublons. Il suffit de combiner num d'utilisateur et timestamp (ou daye("YmdHis") , c'est suffisant)

Pour ce qui est de l'affilié, il ne s'agit que de la digitalisation d'un process, il ne pourront envoyer qu'un seul doc par... an. Verrouillé en pdf, fichier renommé (identifiant_annee);

En résumé, je dois avoir le comportement d'un form classique. Je l'ai deja avec un script en flash, mais à remplacer :p. L'environnement est sécurisé dans son ensemble (accès a RIEN sans identifiants, pas meme une seule page, juste la 403 )
Voili voilà

Bonne journée

[ABCIWEB]

Ok, je tenais simplement à souligner l'avantage de mettre à jour la bdd juste après l'upload des fichiers car sur le principe on risque moins d'interruption dans le processus global quand l'un et l'autre se suivent immédiatement.
Mais il existe des variantes tout aussi sécurisées pour préserver l'intégrité des données en bdd, par exemple ne pas utiliser la fonction Tansfert() et donc laisser le fichier dans le dossier temporaire (en prenant soin d'utiliser la méthode "saveAll()" pour que tous les fichiers soient enregistrés dans le dossier temporaire, y compris les plus petits) et récupérer son adresse, ce qui permet de ne le déplacer vers son emplacement définitif que plus tard à point nommé dans le script.

Bref c'est pour cela que je demande le plus de précisions possibles sur le processus d'upload, d'une part pour éviter de répondre à côté mais aussi parce qu'il existe de nombreuses options qui permettent d'optimiser le script pour répondre à des situations très différentes.

Mais bon, je vois maintenant que tu as fais le tour de la question, c'est l'essentiel. Bonne fin de journée

[Marywilliams]

Merci

[ABCIWEB]

Upload Ajax-Php, version 7.6
Disponible ici


Classes Php

A/ Modifications

1/ Modifications des paramètres d'initialisation de la classe UploadAjaxABCIServeur
- Suppression du paramètre de configuration "$verif_filesize_sup2Go".
Une nouvelle fonction interne à la classe permet de vérifier l'intégrité des fichiers quelque soit leur taille et la version de php.

- Suppression des paramètres de configuration "$cookie_heures" et "$cookie_path"
Ces paramètres ont été remplacés par le paramètre $cookie_options qui requière un tableau identique au tableau d'options de la fonction native "setcookie" de php, excepté pour la première option "expires" remplacée par l'option "duration" qui indique la durée de validité du cookie exprimée en secondes, et non pas sa date d'expiration. Cela permet de configurer toutes les options, y compris l'option "samesite" pour compatibilité avec les futures exigences de sécurité des navigateurs. Tous les index du tableau d'option doivent être renseignés.


2/ Modification du trait ParamsDefautServeur
Pour se conformer aux modifications mentionnées ci-dessus.

3/ Modification de la classe NettoyageTemp
Pour se conformer à la modification du paramétrage du cookie mentionnée ci-dessus.

4/ Modification de la classe Messages
Fusion des messages d'erreur ayant les index 'UpAbServerNomInvalide' et 'UpAbServerTailleInvalide' qui ont été remplacés par l'index 'UpAbServerErreurForm' => "Erreur dans la vérification de l'intégrité du formulaire d'upload". Notez que cet index ne sert qu'en cas d'erreur dans la construction du formulaire, donc uniquement en phase de test (ou tentative de piratage en production), sa personnalisation/traduction est donc inutile.


B/ Corrections

1/ Optimisation du message d'erreur en cas de sauvegarde non valide suite à une reprise d'upload
Depuis la version 7.5, qui par défaut contrôle le type MIME des fichiers, le message renvoyé pour cette erreur était: "type de fichier non valide". Il a été remplacé par "Reprise d'upload impossible. La sauvegarde n'est pas valide. Recharger votre fichier.". Notez que c'est une correction marginale dans le sens où ce message avait peu de chance d'être renvoyé car il est rare qu'un utilisateur stoppe la soumission de son fichier en cours d'upload dans l'intention de la reprendre par la suite, et d'autre part, ces sauvegardes suite à l'arrêt volontaire ou à une panne internet sont très majoritairement valides (à plus de 90% en moyenne). Une note à ce sujet a été ajoutée dans le mode d'emploi, rubrique "Mise en production, notes".

2/ Correction de la fonction renameIdenticName évoquée ici.


C/ Ajout de fonctionnalité

Une fonction setCookie a été ajoutée dans le trait UploadABCITraitServices qui permet de configurer toutes les options, y compris l'option "samesite" quelque soit la version de php. Attention ! le tableau d'options est cette fois-ci rigoureusement identique à la fonction native de php, contrairement au tableau d'options renseigné dans l'initialisation de la classe UploadAjaxABCIServeur et dans lequel le paramètre "expires" est remplacé par le paramètre "duration". Toutes les options du tableau doivent être renseignées.


Classe Javascript

A/ Modifications

1/ Comportement par défaut de la correction de l'orientation des images de prévisualisation
Lorsque l'affichage des vignettes de prévisualisation des photos était activé, la classe UploadAjaxABCI corrigeait automatiquement l'orientation des images en fonction de ses informations EXIF. Ce n'est plus nécessaire puisque les dernières versions des navigateurs font maintenant cette correction, et une double correction provoquait une mauvaise orientation. Ce problème était principalement observable avec des photos provenant d'anciens APN, car les nouveaux envoient maintenant la plupart du temps des images correctement orientées sans utilisation des informations EXIF.

Pour pouvoir revenir à l'ancien comportement, une option config.ExifOrientationCorrection configurée par défaut sur false, a été intégrée dans la classe d'upload javascript. Cela permettrait de faire un test sur la version du navigateur (pour les pays en retard technologique par exemple) afin de configurer cette option suivant le navigateur utilisé.

Notez que cela n'a qu'une incidence sur la présentation des vignettes, et non pas sur le résultat final de l'upload puisque le code serveur possède son propre mécanisme de correction d'orientation avec la classe CorrectionExifJpg qu'il convient d'utiliser pour compatibilité avec un maximum d'APN, notamment en cas de traitements d'images (optimisation pour le web, redimensionnement, recadrage) effectués dans certains exemples du module d'upload.

2/ Fonction docCookies
Cette fonction utilisée en interne, mais disponible pour une utilisation externe, supporte maintenant la configuration de l'option "samesite".

3/ Modification du paramètre de configuration config.cookiePath
Ce paramètre conserve la compatibilité avec les anciennes versions puisqu'il est toujours possible d'indiquer le path en fournissant une chaine de caractère. Mais il accepte maintenant alternativement un tableau pour paramétrer l'option "domain". Noter que la configuration du path et du domaine doit être identique à la configuration du cookie envoyé par Php. Si vous modifiez la configuration par défaut du cookie, il faut le faire en même temps pour les classes javascript et php. Les autres options (secure, httponly et samesite) ne sont pas nécessaires côté javascript car le script ne fait que lire le cookie, et le supprime parfois (rarement).


Compatibilité

Si vous avez utilisé les exemples fournis dans le dossier en téléchargement, vous pouvez mettre le code à jour sans modification depuis la version 7.0.

Vérifiez votre script d'upload côté serveur si vous avez configuré l'initialisation de la classe avec plus de deux paramètres en ligne, ou si vous avez utilisé la configuration avec un tableau en renseignant les index "cookie_heures", "cookie_path" ou "verif_filesize_sup2Go" (dans ce cas cela ne provoquera pas de bug mais ces paramètres seront ignorés). Consultez la fonction getParamUploadAjaxABCIServeur du trait ParamsDefautServeur pour prendre exemple et rectifier la configuration de ces options. Adaptez également les autres valeurs indiquées dans ce trait si vous les aviez modifiées.

Si vous avez personnalisé la traduction des messages contenus dans la classe messages en utilisant par exemple la méthode surchargeMessages, faites attention aux index 'UpAbServerNomInvalide' et 'UpAbServerTailleInvalide' qui n'existent plus.

La classe javascript peut être mise à jour indépendamment et sans contrainte depuis la version 7.0.

En résumer, la plupart du temps vous pourrez faire une mise à jour transparente. En cas de personnalisation des scripts, faire attention à l'initialisation de la classe d'upload dans votre script Php, et mettre éventuellement à jour le fichier ParamsDefautServeur.php. Et si vous avez utilisé la méthode surchargeMessages, vérifiez votre code de construction du tableau des messages puisque deux index ont été supprimés (mais c'est peu probable qu'ils ait été utilisés puisqu'il était indiqué dans la classe "Messages" que leur personnalisation/traduction était superflue).


Mise à jour du mode d'emploi
Effectuée.


Voilà