Ajout d'un répertoire Depot pour la plateforme

[bruno]

Actuellement, si un plugin veut gérer des données partagées, il n'a que le $core->blog->settings pour le faire. Cela peut s'avérer assez limitant si on veut avoir des données plus volumineuses (images, fichiers à part, ...)

Plusieurs contournements sont aujourd'hui possibles, mais ont chacun leurs inconvénients :

• Utiliser le /public pour stocker ses données : reste spécifique à chaque blog (donc nécessité de dupliquer les informations pour chaque nouveau blog)
• Utiliser /plugins/leplugin : le répertoire est écrasé à chaque installation d'une nouvelle version du plugin
• Utiliser /themes/themecourant : problème similaire à /public : nécessité de dupliquer les informations pour tous les thèmes.

Il serait intéressant de ressusciter le dossier /share présent sur dc1, avec éventuellement l'urlhandler qui va bien avec...

[Moe]

Ça pourrait servir à quel fichier par exemple ?

[Moe]

J'ai trouvé une application possible du répertoire share (c'est pour un plugin) : j'aimerais utiliser les icônes des médias (celles affichées dans le gestionnaire de médias) sur le blog hors celles-ci sont placées dans le répertoire admin qui peut être protégé par .htaccess chez quelques-uns. Un répertoire share permettrait d'avoir accès à ces icônes sur toutes les installations, sur le blog et dans l'administration.

Une autre solution pour mon problème serait de copier ces icônes dans les répertoire public mais ça me semble un peu moche. :)

[olivier]

Le répertoire cache me semble un bon candidat à ce genre de chose.

[Moe]

Replying to Moe: J'ai utilisé un mécanisme semblable à celui de Weather pour servir les images avec une URL spéciale.

[xave]

Un répertoire de dépot commun à la plateforme pourrait avoir certains usages. Réflexion à avoir.

(je pense par exemple aux backup de l'autoupdate)

[Tomtom33]

see #1031

[kozlika]

L'idée était bonne, je trouverais ça dommage qu'elle tombe aux oubliettes. Je rouvre à la discussion (il me semble qu'il avait été question d'un rép var/ dans un autre ticket ?

[JcDenis]

Je vote pour le renommage du répertoire cache (ou sa duplication pour rester compatible) et si des plugins en on besoin, ils n'ont cas faire leurs propre urlhandlers.

[xave]

Si les fichiers doivent être présents de manière publique, le répertoire public/ est leur place légitime. Si c'est pour de la cuisine interne, un sous répertoire de cache/ voire un sous répertoire de ce var/ dont on parle depuis longtemps ma paraissent mieux convenir. Créer un deuxième répertoire public, quel que soit sont nom, me paraît peu optimisé.

[saymonz]

Une idée plus ou moins en relation avec celle-ci serait d'avoir un dossier (disons, plugins-datas) dans le dossier public de chaque blog qui ne serait par défaut pas affiché par le gestionnaire de médias (avec une option pour le rendre visible, éventuellement, pour les bidouilleurs). Chaque plugin ayant à stocker du contenu public y rangerait ses fichiers dans un sous-répertoire à son nom. Il faudrait, j'imagine, l'exclure du fonctionnement régulier du gestionnaire de médias (si je pense notamment à des images générées par un thème configurable, on n'a ni besoin qu'elles soient indexées, ni besoin de miniatures).

La logique derrière cette idée est que, selon moi du moins, un utilisateur ne devrait jamais être "perturbé" en trouvant dans son gestionnaire de médias du contenu qu'il n'y a pas mit lui-même (et encore moins du contenu plus ou moins obscur pour l'utilisateur lambda).

[franck]

Ah oui, un répertoire var (ou assimilé) pour les plugins, faut mettre ça sur l'établi.

[JcDenis]

A part renommer le répertoire "cache" en "var" et la constante "DC_TPL_CACHE" en "DC_VAR" il y a quoi à faire la dessus ? Il y a besoin de fonctions de gestion ? Ou de je ne sais quoi ?

Je ne connais pas l'historique DC1 donc je cherche des infos pour avancer ça...

[franck]

Renommer DC_TPL_CACHE n'est pas une bonne idée, on risque de casser quelques plugins.

Donc je verrais plutôt un DC_VAR pointant sur un /var (indépendant de /cache qui continuera à vivre sa vie et qu'on peut vider intégralement sans se poser de question).

Ensuite est-ce qu'il faut structurer le contenu ? Genre un sous-dossier par plugin, un par thème, un pour le noyau, … ? C'est à discuter.

[bruno]

Il y a bien 2 besoins plus ou moins distincts :

• La nécessité de lire/générer des fichiers internes à un plugin/thème
• La nécessité d'"exposer" des fichiers publiquement, dans le contexte d'un plugin

Pour le premier cas, on peut prendre l'approche unix : on ne s'éparpille pas dans le code, et on fait un /var similaire à /public, protégé par un .htaccess. Ensuite, dans ce /var: /var/cache pour les données cachées (contenant cbtpl, admtpl, ...) /blog/<idbublog> s'il faut stocker des infos spécifiques à un blog /plugin/<idduplugin> s'il faut stocker des infos spécifiques à un plugin, indépendamment du blog.

Pour le second cas, il aurait été plus propre de faire pointer le gestionnaire de medias vers /public/media, on aurait eu un répertoire public non dédié au gestionnaire de médias.

[franck]

On est d'accord et il n'est question, pour l'instant, que de gérer un /var privé et non exposé (quitte à fournir un URL handler pour fournir l'accès à certains fichiers stockés ici).

Par contre l'idée de mettre le répertoire /cache à l'intérieur me paraît bizarre (au delà de vouloir conserver une similitude avec unix/linux).

[franck]

Je pars sur l'idée suivante :

Dossier /var (avec un .htaccess qui va bien), avec dedans les dossiers suivants :

/var/system/ → data pour la plateforme /var/system/<blog_id>/ → data spécifique à un blog /var/plugin/<plugin_id>/ → data spécifique à un plugin qui fera ce qu'il voudra dans son répertoire

et éventuellement :

/var/theme/<theme_id>/ → data spécifique à un thème qui fera ce qu'il voudra dans son répertoire

Les répertoires DC_VAR_SYS = /var/system/, DC_VAR_PLUGIN = /var/plugin/ et DC_VAR_THEME = /var/theme seront créés d'emblée

L'idée est de stocker la-dedans ce qui doit être conservé de manière permanente. Le dossier /cache n'ayant pas cette vocation.

Un avis là-dessus ?

[franck]

Ou alors un simple /var avec un URL handler …?df=… et on voit comment ça fonctionne par la suite…

[franck <carnet.franck.paul@…>]

(In [cf9f7abdac2e]) Add /var directory, closes #236 (until further needs)

[franck <carnet.franck.paul@…>]

(In [d9fb614c4a97]) Create .htaccess file in /var directory if needed during upgrade, addresses #236

[Gvx]

Ne faudrait-il pas prévoir les fonctions d'aide suivantes

• getVF dans dcPage et ajouter dans /admin/prepend.php

  $core->adminurl->registercopy('load.plugin.varfile','admin.home',array('vf' => 'dummy.css'));
  

• getVF dans class.dc.blog.php

[franck]

Replying to Gvx:

Ne faudrait-il pas prévoir les fonctions d'aide suivantes

• getVF dans dcPage et ajouter dans /admin/prepend.php

  $core->adminurl->registercopy('load.plugin.varfile','admin.home',array('vf' => 'dummy.css'));
  

• getVF dans class.dc.blog.php

Tout à fait :-)

[franck <carnet.franck.paul@…>]

(In [d7ae7e24da60]) some stuff missing, thanks Gvx for suggestion, addresses #236