Coucou,
j'ai repris le script qui génère les archives.
* halte à la confusion :
il n'y a plus de génération automatique dans /DISTRIB/ : il faut mettre la
distribution stable dans /devel/, avec son numéro de version, attendre
que le tar.gz et le .zip soient générés, puis copier ceux-ci dans /DISTRIB/
en deux exemplaires : sous leur propre nom et sous le nom générique
par exemple actuellement c'est 0.99c.tar.gz et spip.tar.gz
* amélioration de l'archivage :
le répertoire de base est intégré dans le tar.gz et dans le .zip : du coup
le truc se décompresse dans un répertoire comportant son numéro de version.
Ainsi, si l'on va chercher /DISTRIB/spip.zip, il se décompresse en 0.99c/
* L'arborescence est simplifiée en conséquence :
DISTRIB/
0.99c.tar.gz
0.99c.zip
spip.tar.gz
spip.zip
devel/
0.99c/
0.99c.tar.gz
0.99c.zip
1.0alpha3/
1.0alpha3.tar.gz
etc...
et il faut aller dans devel/version/ pour consulter les sources
C'est mieux ??
-- Fil
Hello,
J'ai fait quelques tests sur altern (pas de preg_replace),
et effectivement le propre() bouffe un max de temps machine.
(plusieurs secondes sur de gros articles...)
Notamment :
- le traitement des liens en deux temps était affreusement
onéreux (2 secondes sur un article prenant 8 secondes à
s'afficher) : je l'ai donc bazardé, les liens sont remplacés
en une seule fois (plus de <LIENbidule>).
- la version du remplacement des liens utilisant le strpos à
3 positions n'était en fait pas plus rapide que l'autre, je
l'ai donc virée (code plus lisible).
- s'il n'y a pas preg_replace, j'essaie d'utiliser str_replace.
- j'ai concaténé certaines expressions régulières en une seule.
- dans l'espace public, les champs courts (titre, soustitre,
surtitre, nom, nom_site) ne seront traités qu'avec typo() et
non plus propre() : a priori, on met pas de gras ni de liens
dans un titre ni dans un nom d'auteur...
Voici le inc_texte.php3, si vous voulez modifier des trucs....
a+
inc_texte.php3 (11.3 KB)
- le traitement des liens en deux temps était affreusement
onéreux (2 secondes sur un article prenant 8 secondes à
s'afficher) : je l'ai donc bazardé, les liens sont remplacés
en une seule fois (plus de <LIENbidule>).
L'intérêt du <LIEN...>, c'était d'exclure les liens hypertexte du traitement typographique (notamment les deux points et les points d'interrogation). J'ai pas testé cette nouvelle version, mais j'ai l'impression qu'une URL du genre:
http://www.bidule.com:8080/essai.php3?sid=249
ne passerait plus. Non? (Qu'est-ce que ça donnerait si on conservait l'idée du traitement en deux temps, mais sans <LIEN...>, mais plutôt avec <SOURCE...>? Auquel cas le deuxième traitement serait effectué dans la boucle <SOURCE>, dont on ne peut pas se passer...)
Au fait, tu n'as pas ajouté le traitement des liens simplifiés [article->129] (du genre #URL_ARTICLE), il me semble? Sachant que les "inc-urls" ne se trouvent pas dans /ecrire, est-ce qu'il n'y a pas une difficulté, là? (au passage, pour ces liens simplifiés, j'en voyais 3:
[article->129] (le plus simple)
[article->art129] (même chose que le précédent, mais plus "cohérent" dans le cas de l'utilisation dans le même texte de raccourcis de type "rubriques")
[rubrique->rub34] (pour les rubriques).
Ce sont ces liens simplifiés qui justifient la présence de ces gros pavés "ARTICLE NUMERO XXX" dans /ecrire.
Salut Arno,
ne passerait plus. Non? (Qu'est-ce que ça donnerait si on conservait
l'idée du traitement en deux temps, mais sans <LIEN...>, mais plutôt
avec <SOURCE...>? Auquel cas le deuxième traitement serait effectué
dans la boucle <SOURCE>, dont on ne peut pas se passer...)
Oui, mais j'ai trouvé beaucoup plus simple (et plus rapide) :
appeler la fonction typo() à l'intérieur de la boucle qui analyse
les liens, sur les textes qui se trouvent entre les liens, mais
pas sur les urls de liens.
Au fait, tu n'as pas ajouté le traitement des liens simplifiés
[article->129] (du genre #URL_ARTICLE), il me semble? Sachant que les
"inc-urls" ne se trouvent pas dans /ecrire, est-ce qu'il n'y a pas
une difficulté, là?
Ah oui, je n'avais pas pensé à ce problème.... zut....
Sinon, problème récurrent depuis le début: chez moi, l'affichage des
espaces créées par un blanc et par un retour chariot ne sont pas du
tout identique.
??? Sous netscape, je vois une différence entre les insécables
et les normaux (en mode justifié, les insécables ne sont pas étirés
ce qui peut donner des trucs assez laids...). Mais entre "\n" et " ",
c'est particulièrement bizarre non ?
J'ai pas vérifié, mais logiquement même problème avec
des lignes blanches à la fin d'un texte (qui dans un cas se termine
par un <P> parasite).
Non, le trim() dans propre() est là pour ça (début et fin du texte).
Un sous-titre (par exemple) laissé parfaitement vide n'est
certainement pas traité de la même façon qu'un sous-titre contenant
un espace blanc. (Et donc, pas traité pareil en tant que pseudo-tag
conditionnel.)
Oui, c'est réglé en ajoutant un trim() dans la liste des prétraitements
des champs qui utilisent typo().
a+
J'ai essayé multimania. La commande include() ne fonctionne même pas 
Poubelle.....
Arno* :
> Sinon, problème récurrent depuis le début: chez moi, l'affichage des
> espaces créées par un blanc et par un retour chariot ne sont pas du tout
> identiques.
Même chose sous Internet Explorer 5 Macintosh : faites un essai avec un
fichier html tout bête (et une fenêtre étroite) : <P align=justify>blah blah
blah.. les espaces sont élastiques alors que les sauts de lignes font des
espaces non élastiques. Drôle de bug. En tout état de cause ce n'est pas lié
à spip...
-- Fil
@ Arno* (arno@scarabee.com) :
Autre petit problème chiant: un texte qui commence par des lignes
blanches commence par un <P> (cas notamment lorsque le rédacteur a
sauté quelques lignes avant de commencer son texte), alors que le
même texte commençant bien au début du "formulaire" ne commencerait
pas par ce <P>. J'ai pas vérifié, mais logiquement même problème avec
des lignes blanches à la fin d'un texte (qui dans un cas se termine
par un <P> parasite).
Dans le même ordre d'idées, il y a une différence de comportement entre le
texte justifié et le texte non justifié. Je m'explique :
(#TEXTE) -> "ligne 1 <P> ligne 2"
(#TEXTE|justifier) -> "<p align=justify> ligne 1 <p align=justify> ligne 2"
le filtre |justifier ajoute donc un <p ...> au début
... ce qui peut causer un défaut si l'on désire par exemple ajouter une
image dans ce premier paragraphe : le <p align> venant après l'image, ça
ajoute du blanc.
Si l'on change la
function justifier($letexte) {
$letexte = eregi_replace("<P>","\n<P align='justify'>",$letexte);
return "<P align='justify'>".$letexte;
}
en
function justifier($letexte) {
return eregi_replace("<P>","\n<P align='justify'>",$letexte);
}
, on résoud, mais il faudrait penser à modifier les squelettes : le code
(#TEXTE|justifier) ne contrôlerait pas le premier paragraphe, à remplacer
donc par <P ALIGN=JUSTIFY>(#TEXTE|justifier)
C'est pas très compliqué, et ça permettrait plus de finesse sur les
maquettes.
-- Fil
@ Fil (fil@rezo.net) :
le filtre |justifier ajoute donc un <p ...> au début
ça pose d'autant plus de problèmes que, du coup, on ne peut pas faire de
conditionnel sur un champ justifié : [<HR>(#NOTES|justifier)] affichera une
ligne <HR> qu'il y ait des notes ou pas.
Donc il faut supprimer le premier <p align=justify> de la fonction
justifier.
Hello,
Suite aux différentes améliorations des derniers jours,
j'ai fait une alpha4 :
- il y a donc toutes les modifs qui ont été faites sur
propre() et typo() afin d'essayer d'accélérer les calculs.
- j'ai ajouté les liens internes. Pour l'article 123,
c'est [lien->123] ou [lien->art123] ou [lien->article123].
De même pour les rubriques c'est "rub" ou "rubrique", et
pour les brèves "breve" ou "brève". On peut mettre des
espaces aussi ([lien-> article 456 ]). Le inc-urls.php3
customisable reste à la racine, mais il y a une version
figée pour l'espace privé qui appelle spip_redirect.php3
(en fait la généralisation de ce qui était déjà utilisé
pour les liens "voir en ligne").
- modifs sur la sauvegarde et restauration de bases :
on peut désormais restaurer directement des sauvegardes
compressées (dump.xml.gz), et surtout le format est
maintenant parfaitement compatible XML (de cette manière
les dumps peuvent être visionnés avec un afficheur XML
comme Internet Explorer, ou pourquoi pas exploités pour
les importer sous d'autres outils...). Ce qui fait que,
attention, les dumps réalisés précédemment ne sont plus
compatibles avec cette nouvelle version !
a+
Salut,
Deux propositions pour faciliter la procédure
d'install :
- (idée de Fil) mettre tous les squelettes et les
.php3 associés dans un sous-répertoire exemples/,
et rappeler au webmestre de les recopier à la racine
lors de la première installation. Ainsi, pas de
dilemne concernant les fichiers à remplacer lors
de la mise à jour d'une nouvelle version : les
fichiers personnels sont à la racine, et les exemples
par défaut sont rangés à part.
- pouvoir réinstaller sans supprimer le inc_connect.php3
ni le .htaccess. Ainsi, lors d'une mise à jour, on
n'aurait pas à retaper les identifiants mysql. Il
suffirait d'ajouter un bouton dédié dans la partie
maintenance, avec une sécurité.
Des avis ?
-----Message d'origine-----
de Antoine Pitrou
- pouvoir réinstaller sans supprimer le inc_connect.php3
ni le .htaccess. Ainsi, lors d'une mise à jour, on
n'aurait pas à retaper les identifiants mysql. Il
suffirait d'ajouter un bouton dédié dans la partie
maintenance, avec une sécurité.
Des avis ?
rw: cela va règler pas mal de pb (je touche du bois) signalés sur les
.htaccess et inc_connect -
Salut,
Deux propositions pour faciliter la procédure
d'install :
- (idée de Fil) mettre tous les squelettes et les
.php3 associés dans un sous-répertoire exemples/,
et rappeler au webmestre de les recopier à la racine
lors de la première installation. Ainsi, pas de
dilemne concernant les fichiers à remplacer lors
de la mise à jour d'une nouvelle version : les
fichiers personnels sont à la racine, et les exemples
par défaut sont rangés à part.
Bof bof bof...
- Manoeuvre supplémentaire, donc complication inutile.
- Un répertoire "exemples", ça signifie à terme _plusieurs_ squelettes d'exemples. Or, ça, faut pas le mettre dans la release de SPIP lui-même, sauf à alourdir énormément le fichier de release. Les squelettes d'exemples, ce sera sur uZine, bien présentés avec des copies graphiques... Là, dans un dossier livré d'office, on obtiendrait un résultat pas du tout aussi concluant.
- pouvoir réinstaller sans supprimer le inc_connect.php3
ni le .htaccess. Ainsi, lors d'une mise à jour, on
n'aurait pas à retaper les identifiants mysql. Il
suffirait d'ajouter un bouton dédié dans la partie
maintenance, avec une sécurité.
Pourquoi pas? Mais comme la "protection" consistera à coup sûr en la création d'un dossier via FTP, ça ne sera pas du tout plus simple qu'actuellement.
De fait, la connaissance des codes d'accès mysql, c'est une forme de protection tout à fait équivalente à la vérification d'un accès par FTP, non?
Amicalement,
ARNO*
ARNO* wrote:
>- (idée de Fil) mettre tous les squelettes et les
>.php3 associés dans un sous-répertoire exemples/,
>et rappeler au webmestre de les recopier à la racine
>lors de la première installation. Ainsi, pas de
>dilemne concernant les fichiers à remplacer lors
>de la mise à jour d'une nouvelle version : les
>fichiers personnels sont à la racine, et les exemples
>par défaut sont rangés à part.
Bof bof bof...
- Manoeuvre supplémentaire, donc complication inutile.
Ah non, au contraire : tu recopies une fois les fichiers,
puis à chaque réinstall tu es tranquille (plus besoin de
sélectionner exactement les fichiers que tu n'as pas
modifiés, etc.).
- Un répertoire "exemples", ça signifie à terme _plusieurs_
squelettes d'exemples. Or, ça, faut pas le mettre dans la release de
SPIP lui-même, sauf à alourdir énormément le fichier de release.
?? SPIP est déjà fourni avec des squelettes d'exemple. Et je
ne vois pas pourquoi on serait obligé de les livrer tous.
Pourquoi pas? Mais comme la "protection" consistera à coup sûr en la
création d'un dossier via FTP, ça ne sera pas du tout plus simple
qu'actuellement.
Oui, chuis bête, il y a plus simple : séparer la procédure
d'upgrade de la procédure d'install.
a+