Re: SPIP 4 et la compat des plugins
tcharlss <[email protected]> Fri, 7 May 2021 18:41:10 +0200
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0247238596==
Content-Type: multipart/alternative;
boundary="------------D508F654A917686A2F1F7CFB"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------D508F654A917686A2F1F7CFB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Le 07/05/2021 à 18:24, Eric Lupinacci a écrit :
>
> Oui mais là je ne suis pas trop d'accord.
> C'est comme si on disait que prefixe_options pourrait être utilisé
> autrement.
> A partir du moment où pour l'instant il est toujours possible de
> donner un nom quelconque et que le paquet possède toujours l'attribut
> je pense que ce sera aux plugins de s'adapter si contact_logo ou autre
> ont été utilisés hors logo.
>
> On pourra faire ça tranquillement.
> Et ensuite l'attribut logo pourra disparaître.
>
> ++
> Eric
Les fichiers php et les images ça n'est pas les mêmes contraintes : les
plugins ou les gens sont libres de ranger et nommer les images destinées
au site public comme bon leur semble, il n'y a rien d'imposé.
Moi le doute de conflit c'est plutôt par rapport à ça : quelqu'un qui
aurait placé toutes ses images en vrac à la racine dans son dossier
squelettes. Et quand bien même c'est pas super, il/elle aurait bien le
droit.
C'est dans ce sens que ça serait plutôt à nous d'anticiper pour pas
collusionner.
--------------D508F654A917686A2F1F7CFB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 07/05/2021 à 18:24, Eric Lupinacci a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAM6W4bZKRgnstkqW0vFohNd=r_W_3tMEG0YrXHm1n+R804fcOw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote"><br>
<div>Oui mais là je ne suis pas trop d'accord.</div>
<div>C'est comme si on disait que prefixe_options pourrait
être utilisé autrement.</div>
<div>A partir du moment où pour l'instant il est toujours
possible de donner un nom quelconque et que le paquet
possède toujours l'attribut je pense que ce sera aux plugins
de s'adapter si contact_logo ou autre ont été utilisés hors
logo.</div>
<div><br>
</div>
<div>On pourra faire ça tranquillement.</div>
<div>Et ensuite l'attribut logo pourra disparaître.</div>
<div><br>
</div>
<div>++</div>
<div>Eric</div>
</div>
</div>
</blockquote>
<p>Les fichiers php et les images ça n'est pas les mêmes contraintes
: les plugins ou les gens sont libres de ranger et nommer les
images destinées au site public comme bon leur semble, il n'y a
rien d'imposé.<br>
Moi le doute de conflit c'est plutôt par rapport à ça : quelqu'un
qui aurait placé toutes ses images en vrac à la racine dans son
dossier squelettes. Et quand bien même c'est pas super, il/elle
aurait bien le droit.<br>
C'est dans ce sens que ça serait plutôt à nous d'anticiper pour
pas collusionner.<br>
</p>
</body>
</html>
--------------D508F654A917686A2F1F7CFB--
--===============0247238596==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline