Community « Le forum « Soupçons de bogues «
Retour migration vers 7.6beta
Avec un bon problème...
Il y a quelques temps, j'ai installé la 7.6alpha. Après révision de mes css, template et skin perso, et avant de terminer tout cela, j'ai voulu faire une mise à jour vers la 7.6beta.
Conditions :
La mise à jour s'est bien déroulée jusqu'à l'appel de la mise à jour des tables. Là, blocage complet avec un drôle de message d'erreur :
"Drôle", parce qu'il n'y a pas de répertoire home4 nulle part ni sur le serveur en dessous de www, ni dans les fichiers de configuration. Incidemment, tous les liens du panneau de contrôle relatifs à la gestion du serveur contiennent ce chemin erroné, et rien ne fonctionne. La navigation est rendue possible après renommage du switch.on, mais impossible d'enregistrer quoi que ce soit, et toujours bien sûr aucun accès aux fonctions de gestion.
Gnapz a débloqué la situation après quelques recherches (merci Gnapz) de la manière suivante (je cite) :
Donc depuis le site fonctionne, il reste quand même des appels contenant ce drôle de chemin (et notamment à propos de l'url-rewriting) mais là, faut que je fasse quelques tests, d'autant plus qu'il semble y avoir une procédure spécifique - au moins chez nuxit - pour la mise en place du rewriting. J'en dirais plus dès que ça aura pris un peu mieux forme dans ma tête - et dans mes tests - à ce propos.
Voilou
Conditions :
- hébergeur : nuxit sur serveur mutualisé
- répertoire d'installation : www/yacs/ avec non gestion de l'index de la racine (y'a le site de prod à la racine)
- pointage par sous-domaine : //test.gresivaudan.org
- archive récupéré sous windows (oui, je m'en sers encore)
- décompression en local, transfert des fichiers par ftp dans le dossier scripts/staging, et mise à jour à partir de ce dossier.
Info pour Gnapz : filezilla est paramétré pour une reconnaissance automatique ascii/binaire, je n'ai rien touché à cela.
Info pour Bernard : la mise à jour incrémentale n'a jamais fonctionné chez nuxit, par contre la mise à jour à partir de l'archive dans inbox/yacs marche avec les tgz. Marche aussi à partir du dossier staging.
La mise à jour s'est bien déroulée jusqu'à l'appel de la mise à jour des tables. Là, blocage complet avec un drôle de message d'erreur :
Not Found. The requested URL /home4/test.gresivaudan.org/control/setup.php was not found on this server."Drôle", parce qu'il n'y a pas de répertoire home4 nulle part ni sur le serveur en dessous de www, ni dans les fichiers de configuration. Incidemment, tous les liens du panneau de contrôle relatifs à la gestion du serveur contiennent ce chemin erroné, et rien ne fonctionne. La navigation est rendue possible après renommage du switch.on, mais impossible d'enregistrer quoi que ce soit, et toujours bien sûr aucun accès aux fonctions de gestion.
Gnapz a débloqué la situation après quelques recherches (merci Gnapz) de la manière suivante (je cite) :
" C'était uniquement au niveau du shared/global.php. Bernard a changé l'utilisation de "self_script" en utilisant une autre variable serveur. Hors si chez moi ça marche, ce n'est pas le cas chez Nuxit.
Je t'ai donc remis le traitement de "self_script" comme dans la version précédente que tu avais et tout roule. "
Donc depuis le site fonctionne, il reste quand même des appels contenant ce drôle de chemin (et notamment à propos de l'url-rewriting) mais là, faut que je fasse quelques tests, d'autant plus qu'il semble y avoir une procédure spécifique - au moins chez nuxit - pour la mise en place du rewriting. J'en dirais plus dès que ça aura pris un peu mieux forme dans ma tête - et dans mes tests - à ce propos.
Voilou
Problem has been recorded
| GnapZ from Caribbean 2970 posts |
Bernard: J'ajouterai que, dans le cas des sous-domaines, il y a un point très important auquel les souscripteur d'hébergement n'ont pas forcément accès: Le mode de traitement des sous-domaines par Apache. "Test.gresivaudan.org" est directement concerné par ce problème. Je n'avais jamais accès sur tous mes sites en mode 2 de yacs (url-rewriting .../articles/view.php/123) à cause de ce fait. Du coup, le mode 3 (url-rewriting .../article/3.html) ne marche encore moins. Tout ceci est dû à la méthode de redirection de l'hébergeur:
Hors, la plupart du temps, les hébergements mutualisés offrent des "Plans" limités en bombre de domaines et sans Catch All, chaque sous-domaine est considéré comme un domaine indépendant. J'ai opté pour la désactivation et tout fonctionne à merveille (les 3 url-rewriting de Yacs). Dans le cas spécifique de "test.gresivaudan.org", je considère le Catch All actif et dans ce cas, il y a un mauvais retour (ou utilisation de variable server) dans la création de $context['self_script'] qui prends en compte $context['url_to_root'].$_SERVER['REQUEST_URI'] . Hors $_SERVER['REQUEST_URI'] de Nuxit retourne la valeur "Home4..." citée dans le post d'Agnès. Hébergeur ou mauvaise variable ? ... ouf, un gros grain de sel ! |
Bernard from nearby-an-airport Associate, 6995 posts |
Normalement, REQUEST_URI désigne une partie de la requête reçue par le serveur. Donc le home4 qui apparait est de trop, et je pense que nuxwin aurait des choses à faire de son côté... Ceci étant, la diversité des comportements sur les variables soi-disant standards est absolument hallucinante. C'est à se demander comment on va s'en sortir... GnapZ, quelques suggestions qui marchent chez toi comme chez nuxwin ? Je pourrais alors les tester chez ovh pour finaliser la 7.6, avec URL rewriting, même avec les sous-domaines... |
| GnapZ from Caribbean 2970 posts |
Bernard : En comparant les test.php sur 3 hébergeurs (ici, test_grési et YacsInfo, soit OVH, Nuxit et TextDrive) on peut reconnaître 1 + 2 variables utilisables en dehors de REQUEST_URI: $_SERVER['REDIRECT_URI'] OU $_SERVER['REDIRECT_URL'] qui contiennent bien '/(yacs)/control/test.php' mais il faut tester la présence de l'une OU l'autre car on a ...URL chez OVH et TextDrive mais ...URI chez Nuxit. Ou mieux, chez les 3 on a une belle $_SERVER['PHP_SELF']='/(yacs)/control/test.php' identique chez le 3 ! Impossible de tester Free (Erreur 500 permanente, je n'ai plus d'accès). |
| Bernard from nearby-an-airport Associate, 6995 posts |
J'ai donc, au vu de ces difficultés, créé un sous-domaine de yetanother..., avec quelques modifs de code, notamment dans shared/global.php, pour faire rentrer tout ceci dans YACS 7.6...test.yetanothercommunitysystem.com est hébergé sur OVH, avec ré-utilisation de la base des utilisateurs de yetanother... Les associés d'ici sont les associés de là-bas, etc... Normalement, les modifs effectuées devraient s'appliquer aussi à d'autres hébergeurs, et j'aimerais avoir confirmation pour nuxwin... Aucune nouvelle du côté de Free ? |
Simplify3 48 posts |
FIX in 7.6 for pretty url (option 2 view.php/37/news style... Mine were broken after upgrading to 7.6 - and after weeks of optimizing my site for Google and Yahoo (and getting more successful by the day) - the idea of losing that work completely sent me into a fit. But I figured out what works for me. [php 4.4.0 is on my server] BERNARD - MAKE THIS FIX (if it's universal): In shared/global.php Instead of using: $_SERVER['PATH_INFO'] use $HTTP_SERVER_VARS('ORIG_PATH_INFO'] This is the result: // analyze script args (e.g. 'articles/view.php/123/3', where '123' is the article id, and '3' is the page number) if(isset($HTTP_SERVER_VARS['ORIG_PATH_INFO']) && strlen($HTTP_SERVER_VARS['ORIG_PATH_INFO'])) { // split all args, if any, and decode each of them $context['arguments'] = array(); $arguments = explode('/', substr($HTTP_SERVER_VARS['ORIG_PATH_INFO'], 1)); if(is_array($arguments)) { foreach($arguments as $argument) $context['arguments'][] = rawurldecode($argument); } } I don't know if it matters, but here's my .htaccess: [it might have made a difference!] # This file adds nice features to YACS # # Uncomment directives below depending of your needs. # Do this one block at a time. # Then load the main index page of your YACS server. # If you experiment a 500 Internal Server Error then # go back to the commented version. # # More support at http://www.yetanothercommunitysystem.com/ # # ask Apache to redirect to pretty error pages # #ErrorDocument 401 /yacs/error.php?error=401 #ErrorDocument 403 /yacs/error.php?error=403 #ErrorDocument 404 /yacs/error.php?error=404 # disable directory browsing below this directory # #Options -Indexes # set the default handler to index.php # DirectoryIndex index.php # translate authentication data if PHP runs as CGI -- see agents/feed.php # # # RewriteEngine on # RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L] # #download palm files # AddType application/octet-stream .prc .pdb RewriteBase / SetEnv TZ US/Eastern AddDefaultCharset US-ASCII ForceType application/x-httpd-php I could optimize it, but since it works now - I'm not changing a THING! I'm using PHP 4.4.0 Solution hint finally found (after hours of searching) AT: http://www.dew-code.com/modules/newbb/viewtopic.php?topic_id=683&forum=8 Ken http://free.naplesplus.us/ |
Edit
Delete
