Documentation 3DIS Multifiles

Architecture, intégration et maintenance — 3DIS Multifiles

Référence : plugin 1.0.1, application Windows 1.0.0 inchangée · documentation actualisée le 30 septembre 2026. Cette partie complète le guide d’utilisation. Les exemples doivent être adaptés puis testés sur un formulaire ou contenu de recette. Ils ne modifient pas automatiquement votre site.

Composants et cycle d’un document

Dans src/, Plugin raccorde CF7, REST et les courriels ; Store gère sessions, quotas, index et états ; Crypto chiffre et déchiffre les flux ; KeyVault conserve les clés ; TemporaryFiles protège les fichiers temporaires. Admin fournit les réglages et le gestionnaire ; StorageLocation et Diagnostics contrôlent les chemins. DesktopAccess authentifie l’application et DesktopApi fournit sa lecture distante. Licensing raccorde le SDK.

Le cycle est receiving → ready → sending → retained. Un retrait produit removed. Un dépôt prêt n’est pas encore une soumission ; la sélection finale est vérifiée et engagée avant l’envoi CF7. Un échec du courriel principal permet le retour à l’état prêt. CF7 ne répercute pas nécessairement un échec de Mail (2) dans le statut principal : la conservation ne prouve pas la réception de chaque courriel.

Deux champs dans un formulaire

Chaque champ possède un nom distinct et ses propres limites. L’exemple suivant prévoit une zone obligatoire et un complément facultatif. Les tailles sont en octets. Configurez les destinataires dans CF7 et choisissez le mode de chaque message dans l’onglet Multifiles.

<label>Votre e-mail
    [email* votre-email]
</label>

<label>Documents
    [threedis_multifiles* documents maxfiles:5 minfiles:1 maxbytes:10485760 totalbytes:26214400 filetypes:pdf|jpg|jpeg|png]
</label>

<label>Complément facultatif
    [threedis_multifiles complement maxfiles:2 maxbytes:5242880 totalbytes:10485760 filetypes:pdf|txt]
</label>

[submit "Envoyer"]

Pour la copie client, le destinataire Mail (2) est [votre-email] dans cet exemple ; le nom peut être différent. Les balises [documents] et [complement] s’utilisent dans le corps du courriel. N’y placez pas le chemin physique du coffre ou des fichiers chiffrés.

Index, chemins et concurrence

L’index JSON versionné décrit sessions, fichiers, contexte, états et échéances. index.lock protège ses opérations ; l’écriture utilise un temporaire puis un renommage. Le chemin d’un document suit site-ID/formulaire-ID/AAAA-MM/titre-normalise-pageID/champ/UUID.mfenc. Le nom original reste une métadonnée ; le chemin n’est pas renommé lorsque le titre de page change.

Cette architecture impose des plafonds : index de 16 Mio, 10 000 enregistrements de fichiers et 5 000 sessions. Elle n’est pas une certification de stockage distribué sur NFS ni de charge massive. Une sauvegarde doit capturer ensemble index et fichiers : suspendez les dépôts pendant la copie ou utilisez un snapshot cohérent.

Chiffrement et sauvegarde restaurable

Les contenus utilisent Sodium secretstream XChaCha20-Poly1305, avec un en-tête 3DISMF01, l’identifiant de clé, des blocs authentifiés et une terminaison vérifiée. Les noms et métadonnées de l’index ne sont pas chiffrés par ce format. Le serveur détient les clés pour les restitutions : ce n’est pas un chiffrement de bout en bout.

1. Relevez le chemin effectif du stockage et celui du coffre, y compris les constantes qui peuvent remplacer les réglages.
2. Sauvegardez l’index et les fichiers chiffrés de façon cohérente, puis le coffre correspondant dans un emplacement séparé et protégé.
3. Conservez la phrase de protection séparément de la sauvegarde du coffre. Ne publiez jamais le coffre dans la médiathèque.
4. Testez la récupération sur une copie, avec l’application, dans un dossier de restitution vide. Ouvrez le fichier obtenu et comparez-le à un original de test.
5. Après restauration serveur, relancez le diagnostic d’accès HTTP et vérifiez les permissions et les alias éventuels de l’hébergement.

Sans les clés correspondantes, l’application ne peut pas reconstituer les documents. Ne restaurez pas un index ancien sur les nouveaux dépôts sans rapprochement. Les copies exportées ou reçues par e-mail restent sous la responsabilité de leur détenteur.

Routes et droits

Les dépôts utilisent POST /wp-json/3dis-multifiles/v1/session, /upload, /cancel et /status. Le contexte signé identifie le site, formulaire, occurrence et champ ; le secret de session autorise les opérations. Origine et en-tête spécifique sont vérifiés. Ne reproduisez pas ces appels en supprimant ces protections.

L’application utilise les routes GET /wp-json/3dis-multifiles-desktop/v1/status, /files et /files/{id}/download. Elle exige HTTPS, l’accès personnel activé, le mot de passe Multifiles, les capacités manage_options et manage_3dis_multifiles, ainsi qu’une autorisation de licence. Dix échecs d’authentification déclenchent une limitation temporaire. L’API est en lecture seule et ne transmet pas le coffre.

L’archive de l’application peut contenir l’adresse du site ; elle ne crée pas les routes, qui sont enregistrées par le plugin. Un proxy qui retire l’en-tête d’authentification peut empêcher la connexion. Les réponses authentifiées et les téléchargements ne doivent pas être mis en cache publiquement.

Hooks et intégrations

wpcf7_posted_data remplace les valeurs publiques par des références durables 3dis-mf:UUID. Les claims techniques restent distincts. Les validations des balises, wpcf7_before_send_mail, wpcf7_mail_components, wp_mail et wpcf7_submit assurent sélection, pièces jointes et état final. Le hook 3dis_multistep_validate_step raccorde les dépôts à la validation intermédiaire.

Le filtre threedis_multifiles_minimum_files($minimum, $tag, $form) permet une règle conditionnelle du nombre minimal. Limitez votre callback au formulaire et champ voulus, renvoyez un entier cohérent avec les limites, et utilisez des données vérifiées côté serveur. Masquer une zone par CSS ne la rend pas facultative. CFDB peut conserver la référence, pas un lien public automatique ; l’incorporation dans Send PDF n’est pas fournie par ce contrat.

Exploitation, mise à jour et retour arrière

La tâche threedis_multifiles_cleanup et le complément opportuniste à la fermeture d’une requête PHP effectuent le nettoyage. Sans visite ni planification externe, la purge physique peut être retardée ; le contrôle d’expiration refuse néanmoins la lecture. Contrôlez la date du dernier nettoyage, les quotas et le diagnostic. Une ligne d’historique retirée n’implique pas que le fichier soit encore téléchargeable.

Avant mise à jour, sauvegardez base, index, stockage et coffre. Contrôlez ensuite deux zones et deux occurrences, le refus des types interdits, le retrait, les modes de courriel, l’application et une récupération locale. En retour arrière, vérifiez la compatibilité du format d’index et du coffre avant de remettre un ancien code. La désactivation ne doit pas servir à purger les fichiers : utilisez les actions explicites de gestion. La recette datée ci-dessous distingue les vérifications effectivement réalisées des contrôles à reproduire lors de vos propres mises à jour.

Retrouver les autres documentations 3DIS · Assistance technique