Pourquoi pas en effet. Cela dit, copier des choses dans l'admin à l'install d'un plugin, va falloir verrouiller ça proprement d'une part, et veiller aux éventuels problèmes de droits d'accès (admin vs plugin qui peut être déporté). pas sûr que ce soit si simple. Le 2 septembre 2015 13:37, Bruno <dsls(a)morefnu.org&gt; a écrit : > Hello, > > Pour faire suite aux problèmes de certains hébergeurs (ovh pour ne pas les > citer) pour délivrer des pages statiques, je me demande s'il ne serait pas > pertinent de permettre aux plugins de gérer des contenus statiques. > > Par exemple : chaque plugin propose un répertoire _static à sa racine, > lequel est recopié à l'installation dans un répertoire donné de l'admin > (par exemple admin/static/<nom plugin>). Et on rajouter des sections de > rafraîchissement/purge dans le plugin maintenance. > > Motivation : actuellement, pour des raisons de sécurité, pour accéder à du > contenu statique (images, css, js, ...), il faut passer par > admin/index.php?pf=plugin/fichier. > > Le problème de cela, que j'ai souvent rencontré, c'est que les css ou js > considèrent que l'url de base est admin/ et non plugins/plugin/. Du coup > les inclusions posent problème. > Par ailleurs, cela génère du temps de traitement php pour souvent pas grand > chose... > > Z'en dites ? Ca vaut le coup qu'on en discute dans un ticket (je me demande > s'il n'y en a pas déjà un e ce type) ? > > -- > Bruno > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 2 septembre 2015 14:17, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > Je comprends l'idée mais ça risque aussi de compliquer les choses pour > certains. Cela oblige à rendre la partie admin accessible en écriture; je > parle du répertoire admin. Jusqu'à présent ce n'était pas nécessaire. > Par exemple pour l'installation sur debian, cette partie là peut-être en > lecture seule. Du coup ce déplacement de fichiers statique ne serait pas > possible. > > Mais le besoin pour un répertoire de ce type existe. J'ai eu le même besoin > pour le plugin permettant d'installer des extensions pour ckeditor. Où > mettre les plugins qui doivent être accessibles depuis un lien http ? Ne > pourrait-on pas créer un nouveau répertoire pour tous ces besoins que l'on > appellerait assets (ou ce que vous voulez) et dans lequel on mettrait tout > ça. Ce répertoire serait purgeable et reconstruisible à partir du plugin > maintenance. > > Z'en dîtes? > L'avantage d'un sous répertoire de /admin, c'est qu'il est visible depuis l'administration. Par exemple chez moi, j'ai un domaine spécifique qui pointe vers /admin (en https), qui me permet d'administrer le blog, le /admin de mon blog n'étant pas visible. L'idéal serait de proposer un /admin/quelquechose, que l'on pourrait changer via un paramètre dans le config.php. Un peu à la manière du public_path/public_url des blogs. Juste pour qu'on soit bien d'accord : il doit s'agir d'un répertoire commun à tout le monde quel que soit le blog (rien à voir avec le public de chaque blog du coup). A noter, on peut même rendre cela transparent pour les anciens plugins : Une fois le nom trouvé, index?pf=*** regarde si le fichier est présent dans le contenu statique (auquel cas il renvoie juste un 302 vers ce fichier), sinon il recopie ledit fichier à son emplacement destination et renvoie le 302 -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 2 septembre 2015 17:05, Franck Paul <carnet.franck.paul(a)gmail.com <javascript:;>> a écrit : > Pourquoi ne pas utiliser un sous-répertoire de cache ? > > Ca m'embête un peu le répertoire cache, aujourd'hui on y stocke des fichiers php, qui n'ont pas vocation à être visibles par le reste ... J'savais bien que j'avais ouvert un ticket là-dessus ... il y a 7 ans :) http://dev.dotclear.org/2.0/ticket/236 -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org <javascript:;> - http://ml.dotclear.org/listinfo/dev