Catégories
Drupal 8

Construire un Stream Wrapper spécifique

Pour gérer les fichiers, Drupal utilise des StreamWrapper.

Les plus connus sont public:// et private:// qui permettent de disposer d’un niveau d’abstraction pour la définition des chemins locaux des fichiers publics (habituellement dans sites/default/files) et des fichiers privés à l’extérieur du DocRoot.

Des modules contribués viennent compléter la collection pour accéder à des chemins standards de Drupal :

  • System Stream wrapper fournit module://, theme://, profile:// et library://
  • Remote Stream Wrapper se concentre sur http://, https:// et feed:// même si je n’ai pas encore bien compris l’usage exact à en faire, faute de documentation et d’interfaces claires… et semble casser FlySystem (ci-dessous)
  • Alternative Stream Wrappers fournit un File Streamer poru disposer d’un dossier temporaire alternatif : par exemple, à plus haute performance que le premier, pour des usages très ciblés
  • FlySystem est une approche beaucoup plus générique, à regarder de prêt

Code de départ

Le code de Alternative Stream Wrapper est relativement simple et peut servir de base à une implémentation spécifique d’un Stream Wrapper.

Jouer avec FlySystem

Il est possible de définir différents types de Stream Wrappers avec FlySystem :

  • Local
  • FTP
  • SFTP
  • Générer un fichier Zip
  • Se brancher sur divers services

La problématique à l’origine du projet est : comment s’appuyer sur des outils Cloud dont les règles peuvent arbitrairement changer du jour au lendemain tout en restant en capacité de déplacer rapidement les fichiers dans une solution de repli si nécessaire. Tout un programme 🙂

Dans Drupal, cela signifie que l’on peut segmenter les fichiers téléversés en fonction de leur nature et de leurs usages par destination.

Imaginons un workflow un peu sophistiquer :

  • je gère mes contenus sur Drupal parce que les interfaces éditoriales sont très souples
  • je génère un rendu Markdown destiné à être consommé dans un FileCMS (PicoCMS, Gatsby, etc.)
  • au moment de la mise à jour : un fichier est généré et stocké vers… un StreamWrapper

En d’autres termes : en phase de développement, dans le public:// avec un intégration par simple lien symbolique sur le serveur local.

Et dès que tout est OK, il suffit de :

  • modifier le nom du StreamWrapper cible, et
  • … c’est tout !

Dès qu’un nouveau contenu est publié ou mis à jour, la prise en compte est aussi rapide que lors d’un dépôt de fichier manuel – mais un peu plus rapide à livrer.

Facile à industrialiser pour construire une ferme de sites avec espace éditorial centralisé :

  • déployer un nouveau FileCMS
  • définir un nouveau StreamWrapper pour pointer vers le nouveau projet
  • attacher le contenu à ce projet au travers d’un profil utilisateur ou d’un terme de taxonomie – ou un terme de taxonomie au sein d’un profil utilisateur… 😉

On notera avec intérêt que l’on n’a pas forcément besoin d’utiliser une connexion SFTP via FlySystem : un StreamWrapper local sur un dossier distant monté est peut-être plus performant.

Push CDN

Il est aussi facile d’utiliser FlySystem pour pousser des contenus vers un serveur distant, puis paramétrer le module CDN pour faire en sorte que les fichiers soient dynamiquement servis avec la bonne URL.

Pratique pour paralléliser les requêtes. Bon pour le SEO.