simple, ok mais fo connaître...
l'idée d'un formulaire dans l'espace privé pour passer le site spip hors ligne et
afficher le message de son choix n'est pas à rejetter sous prétexte d'un
remplacement de fichier sour le ftp...
MO
---- Message original ----
@ root@japanim.net <root@japanim.net> :
simple, ok mais fo connaître...
Il suffit de mettre une page dans la FAQ :^)
www.uzine.net/spip_contrib/ecrire/
l'idée d'un formulaire dans l'espace privé pour passer le site spip hors
ligne et afficher le message de son choix n'est pas à rejetter sous
prétexte d'un remplacement de fichier sour le ftp...
On peut transformer SPIP en machin-qui-fait-tellement-tout-que-
l'utilisateur-ne-sait-plus-rien-faire-tout-seul, mais c'est pas vraiment le
but...
-- Fil
Salut,
> l'idée d'un formulaire dans l'espace privé pour passer le site spip hors
> ligne et afficher le message de son choix n'est pas à rejetter sous
> prétexte d'un remplacement de fichier sour le ftp...
On peut transformer SPIP en machin-qui-fait-tellement-tout-que-
l'utilisateur-ne-sait-plus-rien-faire-tout-seul, mais c'est pas vraiment le
but...
Justement, je croyais que c'était le but: sinon on peut aussi lui demander
d'apprendre php et mysql auquel cas personne n'a même plus à développer
spip, chacun fait ses scripts dans son coin.
Après tout, un bouton qui fait ce que tu dis (mv inc-public.php3
inc-public.php3.bak; cp site-indisponible.php3 inc-public.php3) et le
contraire sur un autre clic, c'est simple et ca fait gagner du temps à des
gens qui sont avant tout interessés par le résultat publié et non par les
technique de copies de fichiers unix.
Et je pense que ça, c'est aussi le role de spip.
Bon, faut pas non plus faire une usine à gaz ingérable en ajoutant des
collifichets dans tous les coins, mais ceci me parait etre une requete
suffisement simple pour ne pas obscurcir le code et suffisement utile pour
mériter attention, même si triviale à réaliser pour "quelcun qui sait".
Mais c'est aussi trivial de vider une base SQL (si on sait) ou d'effacer
les fichiers du caches par FTP (si on sait).
Bref, faut le mettre où dans l'interface ce bouton ?
Yannick
J'ajouterais que l'on a pas toujours accès à un FTP
pour faire la manip.
Admettons que l'accès à la base soit impossible. Je
préfère personnellement mettre le site sur une page de
maintenance que d'avoir des pbs d'affichages.
Ceci peut arriver à n'importe quel moment, y compris
lorsqu'on n'a pas accès à un FTP alors que l'on a
accès au WEB. Un bouton du même type que vider le
cache (que l'on pourrait également faire par FTP si je
ne m'abuse) serait idéal.
A+,
Manu
--- Yannick Patois <patois@calvix.org> a écrit :
J'ajouterais que l'on a pas toujours accès à un FTP
pour faire la manip.
De toutes façons il y aurait une authentification ftp obligatoire, alors...
Admettons que l'accès à la base soit impossible. Je
préfère personnellement mettre le site sur une page de
maintenance que d'avoir des pbs d'affichages.
A ce propos, la version CVS prévoit d'afficher une erreur standard
en cas d'absence de MySQL et si la page n'est pas dans le cache.
-- Fil
+1
yannick a formalisé ce que j'allais dire 
cordialement,
Matthieu ONFRAY
webmaster de Japanim.net
Toute l'actualité de la japanimation
www.japanim.net
donc le moteur de recherche affichera ce message , non ?
cordialement,
Matthieu ONFRAY
webmaster de Japanim.net
Toute l'actualité de la japanimation
www.japanim.net
De toutes façons il y aurait une authentification
ftp obligatoire, alors...
Question de néophite sur SPIP : pourquoi faire une
authentification FTP ? Dans tous les cas où une action
génère une modification du site et pour s'assurer que
la personne qui pratique l'opération a bien le droit
de le faire ?
C'est pas un peu lourd et bloquant dans le cas que
j'ai indiqué précédemment ?
--- Fil <fil@rezo.net> a écrit : >
Hello,
Pour poursuivree sur l'idée de "rideau", deux suggestions pour compléter
:
- Pouvoir fermer uniquement une ou plusieurs rubriques (tout aussi utile
me semble-t-il, ça permet de travailler sur les squelettes d'une
rubrique sans devoir fermer tout le site);
- Faire en sorte que cette fermeture du site ou des rubriques ne soit
pas active pour les utilisateurs disposant du cookie administrateur (ce
qui permet de voir ce que l'on fait);
On peut transformer SPIP en machin-qui-fait-tellement-tout-que-
l'utilisateur-ne-sait-plus-rien-faire-tout-seul, mais c'est
pas vraiment le but...
Là, ça devient un peu plus complexe (il faut du code) et se justifie
sans doute dans le développement de SPIP.
François
> De toutes façons il y aurait une authentification ftp obligatoire,
> alors...Question de néophite sur SPIP : pourquoi faire une authentification FTP ?
Dans tous les cas où une action génère une modification du site et pour
s'assurer que la personne qui pratique l'opération a bien le droit de le
faire ?
Exactement. Les actions qui ont des conséquences lourdes (mise à jour,
sauvegarde, etc) sont protégées par l'accès ftp.
Autre point : si la connexion MySQL est tombée, tu n'as pas accès à l'espace
privé de toutes façons.... donc : la mise en place via un bouton d'un écran
spécial, c'est un concept absurde.
-- Fil
Pour ça, il vaut beaucoup mieux avoir une version "de développement"
de son site, en local sur un PC par exemple, et livrer les modifs "en
bloc" une fois que c'est au point.
À+, Pif.
j'ai fais un include d'un menu déroulant qui s'affiche avec le bouton
recalculer dans le site
ce menu déroulant ecrit dans un fichier txt 0,1,2,3 etc...
mon fichier rubrique.php recupere la valeur du fichier txt et me permet
d'appeler rubrique0.html, rubrique1.html etc... rubrique0.html me sert
justement à mettre une page en construction. les autres a switcher mes
maquettes.
voila si ca peut servir
Florent
"ONFRAY Matthieu" <silicium@japanim.net> a écrit dans le message de news:
002401c33b07$924410d0$1000a8c0@maori...
+1
yannick a formalisé ce que j'allais direcordialement,
Matthieu ONFRAY
webmaster de Japanim.net
Toute l'actualité de la japanimation
www.japanim.net
From: "Yannick Patois" <patois@calvix.org>
To: "Fil" <fil@rezo.net>
Cc: <spip-dev@rezo.net>
Sent: Wednesday, June 25, 2003 11:18 AM
Subject: Re: [spip-dev] Page de maintenance> Salut,
>
> > > l'idée d'un formulaire dans l'espace privé pour passer le site spip
hors
> > > ligne et afficher le message de son choix n'est pas à rejetter sous
> > > prétexte d'un remplacement de fichier sour le ftp...
> > On peut transformer SPIP en machin-qui-fait-tellement-tout-que-
> > l'utilisateur-ne-sait-plus-rien-faire-tout-seul, mais c'est pas
vraiment
le
> > but...
>
> Justement, je croyais que c'était le but: sinon on peut aussi lui
demander
> d'apprendre php et mysql auquel cas personne n'a même plus à développer
> spip, chacun fait ses scripts dans son coin.
>
> Après tout, un bouton qui fait ce que tu dis (mv inc-public.php3
> inc-public.php3.bak; cp site-indisponible.php3 inc-public.php3) et le
> contraire sur un autre clic, c'est simple et ca fait gagner du temps à
des
> gens qui sont avant tout interessés par le résultat publié et non par
les
> technique de copies de fichiers unix.
>
> Et je pense que ça, c'est aussi le role de spip.
>
> Bon, faut pas non plus faire une usine à gaz ingérable en ajoutant des
> collifichets dans tous les coins, mais ceci me parait etre une requete
> suffisement simple pour ne pas obscurcir le code et suffisement utile
pour
Autre point : si la connexion MySQL est tombée, tu
n'as pas accès à l'espace
privé de toutes façons.... donc : la mise en place
via un bouton d'un écran
spécial, c'est un concept absurde.
Le concept n'est pas absurde mais il n'est pas
réalisable, on va dire que c'est plus diplomatique ...
Fil pas diplomatique ? on va pas en faire un monde 
À+, Pif.
Pour ça, il vaut beaucoup mieux avoir une version "de
développement" de son site, en local sur un PC par exemple,
et livrer les modifs "en bloc" une fois que c'est au point.
C'est effectivement plus efficace mais plus contraignant (ne serait-ce
que pour installer spip en local). Je ne suis pas sûrt que des modifs
sur les squelettes directement en ligne soient a priori une si mauvaise
manière de faire.
Cela dit, ça ne change rien à l'intérêt d'une fermeture possible du site
par rubrique (pour les autres raisons évoquées : justification
éditoriale, légale,...).
François
Encore moins une uzine (à gaz).
Cela dit, ça ne change rien à l'intérêt d'une fermeture possible du site
par rubrique (pour les autres raisons évoquées : justification
éditoriale, légale,...).
Ca tombe bien, il y a les squelettes de rubrique pour faire ça ; puis :
"vider le cache".
-- Fil
> Pour ça, il vaut beaucoup mieux avoir une version "de
> développement" de son site, en local sur un PC par exemple,
> et livrer les modifs "en bloc" une fois que c'est au point.C'est effectivement plus efficace mais plus contraignant (ne serait-ce
que pour installer spip en local).
Heu .. à priori, c'est pareil que sur un serveur. Suffit d'installer
apache+php+mysql (ou un truc tout fait à la easyPhp) et hop.
Je ne suis pas sûrt que des modifs
sur les squelettes directement en ligne soient a priori une si mauvaise
manière de faire.
C'est qu'une question de point de vue.
La moindre manip de travers risquant de mettre ton site par terre, si
c'est "la page perso de monsieur leneuf", c'est p'tet pas vital, mais si
c'est un site super connu, ça l'fait moyen.
De même, si c'est ton site, c'est tes oignons, mais si t'es prestataire,
ça risque de pas plaire à ton client
À+, Pif.
euh!!! je dis peut etre une grosse betise, mais le systeme des dossiers
squelettes, en permettant de basculer rapidement entre 2 configs n'est-il
pas une solution possible pour traiter ce cas, en faisant : 1 dossier
squellete _prod et 1 ou plusieurs dossier(s) squelettes_test
@+
Nicolas R
Antoine a écrit :
Le concept n'est pas absurde mais il n'est pas
réalisable, on va dire que c'est plus diplomatique ...Fil pas diplomatique ? on va pas en faire un monde
Encore moins une uzine (à gaz).
pfff 
... ces gosses