Author: fil@rezo.net
Date: 2007-09-16 23:19:12 +0200 (dim, 16 sep 2007)
New Revision: 10315
Log:
le bon calcul pour la globale $profondeur_url (qui pour l'instant ne sert qu'a url_de_base()
Modified:
spip/ecrire/inc/utils.php
spip/ecrire/inc_version.php
Le 16 sept. 07 à 23:19, fil@rezo.net a écrit :
Author: fil@rezo.net
Date: 2007-09-16 23:19:12 +0200 (dim, 16 sep 2007)
New Revision: 10315Log:
le bon calcul pour la globale $profondeur_url (qui pour l'instant ne sert qu'a url_de_base()Modified:
spip/ecrire/inc/utils.php
spip/ecrire/inc_version.php
Je ne comprends pas ce chgt, qui met par terre mon installation mutualisé sans que j'arrive à redresse la situation:
- si je ne touche pas à $profondeur_url, les squelettes appelés de l'espace privé (jquery en premier lieu) sont référencés avec une mauvaise url (il y a ecrire/ dedans)
- si j'affecte $profondeur_url, ceux-ci marche, mais quand j'ai besoin de repasser par la page de login, celle-ci ne renvoie pas sur spip.php/action=cookie mais sur spip.phpspip.php/action=cookie.
Quelle était l'intention ?
Committo,Ergo:Sum
> le bon calcul pour la globale $profondeur_url (qui pour l'instant
> ne sert qu'a url_de_base()
>
> Modified:
> spip/ecrire/inc/utils.php
> spip/ecrire/inc_version.php
>
> Details: http://trac.rezo.net/trac/spip/changeset/10315Je ne comprends pas ce chgt, qui met par terre mon installation
mutualisé sans que j'arrive à redresse la situation:
réparé en 10324
Quelle était l'intention ?
Pour gérer des urls arborescentes, on a besoin de savoir à tout
instant à quelle profondeur on se situe par rapport à la racine, de
façon à pouvoir remonter de n crans pour aller chercher spip.php, IMG
etc. C'est cette globale qui sait où on en est (sauf quand elle a
abusé de la vodka)
-- Fil
Le 18 sept. 07 à 12:26, Fil a écrit :
cette globale qui sait où on en est (sauf quand elle a
abusé de la vodka)
maintenant çà doit être au whisky car ça ne s'arrange pas.
Committo,Ergo:Sum
maintenant çà doit être au whisky car ça ne s'arrange pas.
hips!
Chez moi ça marche, en tous cas ; cette globale n'est utilisée qu'à
trois endroits (urls/propres et inc/utils, dans l'initialisation et
dans url_de_base()) ; il faut que tu regardes en détail ce qui se
passe ; est-ce que les variables suivantes sont bien définies et
cohérentes ?
$_SERVER['REQUEST_URI']
$GLOBALS['meta']['adresse_site']
-- Fil
Le 18 sept. 07 à 12:46, Fil a écrit :
maintenant çà doit être au whisky car ça ne s'arrange pas.
hips!
Chez moi ça marche, en tous cas ; cette globale n'est utilisée qu'à
trois endroits (urls/propres et inc/utils, dans l'initialisation et
dans url_de_base()) ; il faut que tu regardes en détail ce qui se
passe ; est-ce que les variables suivantes sont bien définies et
cohérentes ?
$_SERVER['REQUEST_URI']
$GLOBALS['meta']['adresse_site']
Hmmm. Ca marche en effet en MySQL, et ça marche en PG si $GLOBALS['meta']['adresse_site'] n'est pas rempli. Mais si je la remplis, c'est là que l'intall PG part à l'ouest. Ce comportement est peut-etre vieux, car je n'ai rempli que face au problème rencontré aujourd'hui. La suite plus tard.
Committo,Ergo:Sum
le bon calcul pour la globale $profondeur_url (qui pour l'instant
ne sert qu'a url_de_base()Quelle était l'intention ?
Pour gérer des urls arborescentes, on a besoin de savoir à tout
instant à quelle profondeur on se situe par rapport à la racine, de
façon à pouvoir remonter de n crans pour aller chercher spip.php, IMG
etc. C'est cette globale qui sait où on en est (sauf quand elle a
abusé de la vodka)
Pour mes URL arborescentes -- oui, je sais, je dois écrire un article à ce sujet -- je n'ai pas besoin de connaître le niveau d'arborescence, parce que j'utilise de toute façon des URL absolues partout. Cela pose potentiellement problème quand je passe les données d'un site vers un autre (prod vers dev par exemple), mais je me contente de vider les url_propre et ça remarch (pas testé avec les récents changement en SVN).
Le gain est par contre intéressant, je n'ai plus à me préoccuper de l'emplacement relatif.
Quel est l'intérêt de s'embêter avec des URL relatives (à part la migration de contenus) ?
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Pour mes URL arborescentes -- oui, je sais, je dois écrire un article
à ce sujet -- je n'ai pas besoin de connaître le niveau
d'arborescence, parce que j'utilise de toute façon des URL absolues
partout.
Le problème c'est les liens vers les documents, pas tellement les
liens vers les autres articles ; surtout avec reduire_image, qui
travaille sur l'url de l'image alors qu'elle devrait traiter le chemin
local (http).
-- Fil
Pour mes URL arborescentes -- oui, je sais, je dois écrire un article
à ce sujet -- je n'ai pas besoin de connaître le niveau
d'arborescence, parce que j'utilise de toute façon des URL absolues
partout.Le problème c'est les liens vers les documents, pas tellement les
liens vers les autres articles ; surtout avec reduire_image, qui
travaille sur l'url de l'image alors qu'elle devrait traiter le chemin
local (http).
Pour les liens vers les documents, j'utilise ça :
function generer_url_document($id_document) {
if ($id_document > 0) {
$query = "SELECT fichier FROM spip_documents WHERE id_document = $id_document";
$result = spip_query($query);
if ($row = spip_fetch_array($result)) {
$url = lire_meta('adresse_site').'/'.get_spip_doc($row['fichier']);
}
}
return $url;
}
Qu'entends-tu par « chemin local (http) » ? L'URL relative sans le domaine ?
N'est-ce pas justement ce que get_spip_doc() renvoie ?
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Le 18 sept. 07 à 13:07, Committo,Ergo:sum a écrit :
Le 18 sept. 07 à 12:46, Fil a écrit :
maintenant çà doit être au whisky car ça ne s'arrange pas.
hips!
Chez moi ça marche, en tous cas ; cette globale n'est utilisée qu'à
trois endroits (urls/propres et inc/utils, dans l'initialisation et
dans url_de_base()) ; il faut que tu regardes en détail ce qui se
passe ; est-ce que les variables suivantes sont bien définies et
cohérentes ?
$_SERVER['REQUEST_URI']
$GLOBALS['meta']['adresse_site']Hmmm. Ca marche en effet en MySQL, et ça marche en PG si $GLOBALS['meta']['adresse_site'] n'est pas rempli. Mais si je la remplis, c'est là que l'intall PG part à l'ouest.
Ce n'est pas lié à PG: lorsque j'installe un site en mutualisé, la première connexion juste après le message "SPIP est désormais installé...." m'envoie sur la page d'accueil avec une profondeur de trop pour jquery.js (je vois ecrire/ dans l'attribut de la balise Link). Si je raffraichis la page, tout rendre dans l'ordre.
Committo,Ergo:Sum
Ce n'est pas lié à PG: lorsque j'installe un site en mutualisé, la
première connexion juste après le message "SPIP est désormais
installé...." m'envoie sur la page d'accueil avec une profondeur de
trop pour jquery.js (je vois ecrire/ dans l'attribut de la balise
Link). Si je raffraichis la page, tout rendre dans l'ordre.
On aurait donc un problème avec la global[adresse_site] définie mais
pas correcte ?
J'ai remarqué un truc peut-être similaire avec le charset, qui parfois
semble ne pas être connu (le nom du site s'affiche, dans l'espace
privé, sous sa forme "À@"). Comme si on n'avait pas réussi à lire
correctement spip_meta.
-- Fil
Le 19 sept. 07 à 14:54, Fil a écrit :
Ce n'est pas lié à PG: lorsque j'installe un site en mutualisé, la
première connexion juste après le message "SPIP est désormais
installé...." m'envoie sur la page d'accueil avec une profondeur de
trop pour jquery.js (je vois ecrire/ dans l'attribut de la balise
Link). Si je raffraichis la page, tout rendre dans l'ordre.On aurait donc un problème avec la global[adresse_site] définie mais
pas correcte ?J'ai remarqué un truc peut-être similaire avec le charset, qui parfois
semble ne pas être connu (le nom du site s'affiche, dans l'espace
privé, sous sa forme "À@"). Comme si on n'avait pas réussi à lire
correctement spip_meta.
Trouvé le perturbateur: c'est le "static $url" dans url_de_base().
Si on enlève cette déclaration, ça décoince.
Il y a sans doute moins bourrin, mais faudrait comprendre où cette fonction est appelée trop tot.
Committo,Ergo:Sum
Le 19 sept. 07 à 15:26, Committo,Ergo:sum a écrit :
Il y a sans doute moins bourrin, mais faudrait comprendre où cette fonction est appelée trop tot.
... dans verifier_visiteur.
10339 devrait rouler sans pb maintenant.
Committo,Ergo:Sum