Pourquoi ne pas utiliser un sous-répertoire de cache ?
Le 2 septembre 2015 14:31, Bruno <dsls(a)morefnu.org> a écrit :
Le 2 septembre 2015 14:17, Nicolas <nikrou77(a)gmail.com> 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