Pourquoi ne pas utiliser un sous-répertoire de cache ? Le 2 septembre 2015 14:31, Bruno <[email protected]> a écrit :
> Le 2 septembre 2015 14:17, Nicolas <[email protected]> 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 - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
