Stockage cloud (Google Drive, OneDrive, Dropbox)

Extension payante. Les pièces jointes explicitement autorisées sont recopiées dans un dossier de votre Google Drive, OneDrive ou Dropbox, après la soumission.

Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Copier les pièces jointes vers un espace de stockage ».

Copier un fichier chez un tiers n’est pas envoyer une valeur

Tout le module tient dans cette différence.

Un champ texte part vers un CRM parce qu’un administrateur a relié ce CRM. Une pièce d’identité part vers un espace de stockage parce que quelqu’un a coché ce champ-là, nommément.

D’où une liste blanche vide par défaut, et vide veut dire « rien ». C’est l’inverse du déclencheur Zapier, où une liste vide laisse tout sortir. Un module qui copierait tout par défaut déposerait, le jour où un formulaire gagne un champ fichier, des documents que personne n’a décidé d’envoyer.

Le chemin vient de la base, donc il n’est pas digne de confiance

La valeur d’un champ fichier est un document JSON stocké en base, qui contient un chemin. Une importation de formulaire, une restauration partielle, une injection : il suffirait d’un chemin forgé pour que ce module lise wp-config.php et le dépose sur le Drive de quelqu’un.

Chaque chemin est donc confronté au dossier de téléversement du plugin avant toute lecture, par le contrôle qui garde déjà la purge — il résout le chemin réel, liens symboliques et .. compris. Deux contrôles différents pour la même question auraient fini par diverger, et c’est celui qu’on aurait oublié qui lisait des fichiers.

Trois fournisseurs, et ce qui les distingue vraiment

La taille. Aligner les trois sur la plus basse aurait interdit chez Dropbox des fichiers qu’il accepte sans difficulté ; prendre la plus haute aurait produit des refus incompréhensibles chez Microsoft. Chaque fournisseur annonce sa borne, et l’écran la montre. Un fichier au-dessus est refusé sans être tenté : l’envoyer pour se le voir refuser coûterait le temps et la bande passante du serveur pour un échec certain.

Les dossiers. Google désigne un dossier par identifiant et ne crée rien : le module cherche puis crée chaque niveau. Les deux autres créent l’arborescence à partir du chemin.

Le lien. Google et Microsoft rendent une adresse qui ouvre le fichier dans leur interface, pour qui y a déjà accès. Dropbox n’en rend pas sans créer un partage — une adresse qui ouvre le fichier à qui la connaît. Le plan l’exclut, et pour une bonne raison : une pièce justificative déposée par un visiteur deviendrait un document public dès qu’une adresse fuite. L’écran montre donc le chemin.

Aucun partage n’est jamais créé, chez aucun des trois.

Les portées sont minimales, et cela se voit

Google : drive.file. Elle ne donne accès qu’aux fichiers que cette application a créés — le module ne peut ni lire, ni modifier, ni supprimer quoi que ce soit d’autre dans le Drive du client, y compris s’il était détourné. drive tout court aurait donné un accès complet à l’espace, pour y déposer des fichiers.

Conséquence à connaître : le dossier racine doit être créé par le module, et non choisi parmi les dossiers existants, qui lui sont invisibles.

Microsoft : Files.ReadWrite, sur le OneDrive de la personne qui autorise — et non Files.ReadWrite.All, qui porte sur tous les fichiers auxquels elle a accès, espaces partagés de l’organisation compris. offline_access n’est pas un confort : sans elle, aucun jeton de rafraîchissement n’est délivré.

Le dossier se construit, et aucune valeur n’en décide la structure

Un gabarit — {form}/{year}/{entry} — range à mesure. Mille soumissions dans un même dossier donnent mille fichiers qu’aucune interface ne sait parcourir.

Chaque valeur est assainie avant d’entrer dans le gabarit. Sans cela, un titre de formulaire contenant Un/Deux/Trois créerait trois niveaux de dossier : la structure serait décidée par le titre, et non par le gabarit qui existe pour cela. Et un titre contenant .. ferait sortir du dossier racine — chez Dropbox et OneDrive, où le chemin fait foi, « sortir » peut mener n’importe où dans l’espace du client.

La profondeur est bornée à six niveaux : un gabarit à trente niveaux ferait parcourir trente dossiers à Google, deux requêtes chacun.

Le nom du fichier vient du navigateur de la personne qui a téléversé. Il perd son chemin, ses caractères de contrôle, et sa longueur excédentaire — en gardant son extension, parce qu’un fichier déposé sans extension ne s’ouvre pas d’un double-clic.

Un fichier, une copie

UNIQUE (soumission, champ) : une pièce ne part qu’une fois. Une seconde copie coûterait du stockage au client et laisserait deux fichiers dont personne ne sait lequel fait foi.

Le champ entre dans la clé parce qu’une soumission porte légitimement plusieurs pièces — une carte d’identité et un justificatif de domicile — copiées séparément : l’une peut échouer et l’autre non.

La prise de ligne décide qui copie quand deux tâches se croisent, ce qui arrive dès qu’un dépôt dépasse l’intervalle de reprise — et un dépôt de plusieurs mégaoctets le dépasse facilement.

« Ignoré » et « échoué » ne disent pas la même chose

Ignoré : rien n’a été tenté et rien ne le sera — fichier absent, taille au-dessus de la borne du fournisseur, chemin refusé, champ non coché. Il y a un réglage à corriger, ou rien à faire.

Échoué : le fournisseur a refusé ou n’a pas répondu. Les refus définitifs — 403 pour un droit retiré ou un quota épuisé, 404 pour un dossier disparu — ne sont pas rejoués : chaque reprise consomme le quota d’API du client pour obtenir le même refus. Les 429 et 5xx le sont, à 1, 5 puis 30 minutes. Un 401 donne droit à un renouvellement immédiat, puis à un second dépôt.

La suppression distante ne commande jamais la purge locale

Elle est facultative et par défaut éteinte : effacer une soumission ici n’a pas à effacer le document là-bas, que le client peut avoir classé, annoté, versé à un dossier.

Quand elle est demandée, les identifiants distants sont lus avant l’effacement — après, il ne reste rien à viser — puis la suppression est programmée. Son échec laisse un fichier de trop chez le client ; la retenir aurait laissé la donnée ici, ce qui est pire.

Elle est idempotente : un fichier déjà absent est une réussite, pas une erreur. Sans cela, une seconde purge échouerait à jamais sur ce que la première a bien effacé.

Recopier à la main peut créer un second fichier

Le détail de la soumission porte un bouton par pièce. Les trois fournisseurs renomment plutôt qu’ils n’écrasent, et c’est voulu : un dépôt qui écrase remplacerait un document que quelqu’un a peut-être annoté. L’écran le dit plutôt que de le laisser découvrir.

Les contrôles ne sont pas contournés : la ligne repasse par la vérification du chemin, la taille et la liste blanche.

Ce que le journal ne contient pas

Ni le chemin local, ni le contenu : le second est le fichier lui-même, et le consigner ferait du journal une seconde copie qui s’en irait dans les sauvegardes et les exports.

Schéma

slf_cloud_copies : une ligne par soumission et par champ fichier, avec le fournisseur, l’identifiant distant, le chemin déposé, le lien le cas échéant, l’état et le motif du dernier problème.

Les connexions vivent dans une option, une entrée par fournisseur, jetons chiffrés avec une clé propre à chacun.

Ce que la V1 ne fait pas

Pas de dossier public, pas de partage automatique, pas de synchronisation bidirectionnelle, pas de transformation de fichier, et pas d’envoi par session reprise — c’est ce qui borne la taille, et c’est le premier chantier si des fichiers plus gros doivent passer.