J’essaye d’installer dokuwiki (version dokuwiki-2011-05-25a “Rincewind” stable ) sur ouvaton.
Mais je n’y arrive pas complètement. Ma page “start” ne se charge pas complètement. Le chargement s’arrête en plein milieu. ce qui fait que je n’ai pas accès à certains éléments, comme le bouton login, etc …
Pourtant, j’ai suivi les procédures:
téléchargement de l’archive sur mon PC local
décompression de l’archive sur mon PC local
transfert des fichiers de l’archive décompressée sur mon site ouvaton, via ftp
redéfinition des droits en 777, des dossiers conf, data et lib, de leurs fichiers et sous dossiers, avec FilleZilla
ouverture de la page install.php et remplissage de la page en respectant les règles de caractères autorisés
j’ai essayé les méthodes consistant à ajouter le bout de code concernant php5
La communauté de dokuwiki essaye de son côté de trouver le yap, mais nous nous demandons s’il ne faut pas que je fasse quelque chose de spécial sur ma plaque ouvaton.
Merci Greg pour tes indications. C’est très sympas à toi.
: oui. Dokuwiki dit: php 5.1 ou supérieur
: ce qui veut dire ? créer un fichier .htaccess à la racine de ma plaque, ou bien dans le répertoire créé pour le dokuwiki ? Avec comme code uniquement php5 dedans ou bien avec le code AddHandler application/x-suexec-php5 .php ? Et dois-je y mettre des choses spéciales pour la sécurité sachant qu’il existe déjà plusieurs .htaccess dans les répertoires dokuwiki.
: je suis sur node1-6.ouvaton.coop => est-ce nécessaire d’activier php5 ? il m’a semblé avoir lu que php5.3 était activé automatiquement sur node1-6.ouvaton.coop ?
: heuuuu … je n’ai jamais fait ça. Je ne sais pas faire. Il va falloir que je cherche comment on fait. Si tu as une piste …
Oui, et pas qu’une seule fois. Seulement, cela parle d’une version ancienne de dokuwiki. Il semble que depuis ce temps les choses aient changées.
Bon, on progresse. Je sens que nous sommes pas loin du dénouement …
Je n’ai pas encore trouvé comment “activer” les messages d’erreurs PHP.
Je vais essayé de demander de l’aide à Etienne Fort: peut-être pourra-t-il tester une installation de la version RinceWind et faire un échange d’expérience …
: ce qui veut dire ? créer un fichier .htaccess à la racine de ma plaque, ou bien dans le répertoire créé pour le dokuwiki ? Avec comme code uniquement php5 dedans ou bien avec le code AddHandler application/x-suexec-php5 .php ? Et dois-je y mettre des choses spéciales pour la sécurité sachant qu’il existe déjà plusieurs .htaccess dans les répertoires dokuwiki.[/quote]
Si tu sais que tu es en php5, tu n’as pas besoin de l’activer (c’est pour les sites qui sont encore sur le cluster).
[quote]
: heuuuu … je n’ai jamais fait ça. Je ne sais pas faire. Il va falloir que je cherche comment on fait. Si tu as une piste …[/quote]
J’avoue que je n’ai pas d’autre idée: ta page arrête effectivement de se charger au milieu, et si le code nous disait ce qui se passe à ce moment, ça nous aiderait peut-être un peu… Une fonction requise qui n’est pas activée? Un temps d’exécution trop long (mais là, il y aurait un message, et comme jusque là, la page se charge rapidement…)?
Résultat: Ma page “start” de mon dokuwiki ne se charge plus, et j’obtiens à la place le message suivant: The server encountered an internal error or misconfiguration and was unable to complete your request..
Comme j’ai trouvé ça bizarre, et que cela ne donnait semble-t-il pas d’erreurs php, mais une erreur serveur, j’ai supprimé le fichier .htaccess créé à l’occasion de cette “manip”. retour à la case départ …
Je continue à chercher et … à espérer.
nota: j’ai aussi trouvé et testé une autre façon de mettre en place le listage d’erreurs php (en anglais) ici, sans amélioration: cela bloque.
Il doit y avoir aussi un moyen d’afficher les erreurs avec du code php, mais il faut pour cela modifier une des pages (p.ex. index.php, ou une page incluse automatiquement, comme une page config.php). J’ai trouvé le code ci-dessous, mais pas testé.
J’ai pu tester ce code sur un fichier appelé index.php présent à la racine du dossier dokuwiki, après avoir créé un fichier error_log.txt, mais rien ne s’est passé. J’ai demandé à la communauté dokuwiki où je pourrais placer ce code.
Ok, Greg. Super ton idée !
La communauté dokuwiki, m’a aidé. Ce code peut s’insérer dans un fichier appelé doku.php
Grâce à ton idée, nous avons enfin le fin mot de l’histoire: le code m’a renvoyé le message d’erreur suivant:
PHP Notice: Undefined index: REMOTE_USER in /usr/...../dokuwiki/inc/template.php on line 342
PHP Fatal error: Cannot use string offset as an array in /usr/...../dokuwiki/inc/common.php on line 280
D’après la communauté dokuwiki qui m’a aidé, ce serait la procédure sécurité php des serveurs ouvaton, qui empêcherait dokuwiki d’écrire certains fichiers. L’explication technique serait ici sur la page php5 de ouvaton et concernerait safemode.
Ce code impliquerait que Dokuwiki ne peut pas donner $SERVER’REMOTE_USER’] au nom de l’utilisateur , car seules les variables d’environnement qui commencent avec PHP peuvent être changées ou données par PHP. (traduction de ce post sur le forum dokuwiki). J’avoue, que n’étant pas technique, je ne fais que retransmettre. Il se peut que je me trompe dans mon interprétation.
Bon, ben voilà. Maintenant, … pour arriver à solutionner ça …
Huummm … une idée sur la marche à suivre compte tenu de cette nouvelle donnée ?
Là, on progresse, effectivement. Et tu as touché mes limites de compétences
Le mieux serait que tu contactes les admins avec ce message. Soit ils savent ce qu’il faut faire, soit ils regardent avec l’infogérant. Tu peux aussi poster sur les news: il y a davantage de personnes qui les consultent.
Andi, le créateur de DOKUWIKI et d’autres pointures de la communauté DOKUWIKI, nous ont gentillement aidé à y voir plus clair.
Le résultat n’EST PAS BON DU TOUT POUR OUVATON !!!
Il s’avèrerait en effet, que : **dans phpinfo se trouve quelque chose de vraiment pas normal: une valeur auto_prepend_file avec /usr/local/www/session/weirdsession.inc.php **(les mots sessions et weirdsession étant à remplacer par leurs véritables valeurs, nous supposons), le tout étant inaccessible et donc impossible à comprendre. Il semblerait que cette façon de faire soit vraiment peu conforme et la question est:
mais pourquoi diable OUVATON a créer ce code php ? et pourquoi OUVATON n’a pas réagit tout de suite pour que DOKUWIKI puisse s’installer normalement en modifiant ce paramètre ? Avec en ligne de mire, une sorte de suspicion qui pointe le bout de son petit nez, et une envie de poser une recommandation plus vache encore, car peut-être non fondée: peut-on faire confiance en un “provider” qui s’amuse de la sorte ?
Bref, au vue de tout cela, nous sommes devant la nécessité d’espérer avoir une réponse de la part des techniciens en charge de la plateforme OUVATON, afin d’éclaircir cette pratique, et la réaligner avec la conformité, pour que des DOKUWIKI 2011 ou supérieurs, utilisant php 5.3 ou supérieur, sur des node1-6.ouvaton.coop , puissent enfin s’installer dignement.
De notre côté, tant que cela ne sera pas résolu dans la douceur, nous nous disons que DOKUWIKI ne peut pas “tourner” normalement sur OUVATON, ce qui peut poser des problèmes lors de mises à jour.
Si vous voulez nous aider à essayer de résoudre ça, ce serait impeccable. Ce serait vraiment étrange que OUVATON, c’est à dire “nous tous ensemble”, nous n’arrivions pas à solutionner ce truc , non ?
Les résultats des investigations m’intéressent beaucoup.
Pour ma part, je fais tourner la version angua sur ouvaton. Seule la page “Gestionnaire de médias” semble buggée avec une barre de défilement qui ne s’arrête pas lors de la suppression ou la restauration d’une ancienne version d’un fichier.
J’ai juste ajouté le fichier .htaccess avec la ligne “AddHandler application/x-suexec-php5 .php” à la racine du site.
Voici comment, Andi de Dokuwiki, a de son côté, résolu le problème:
1/ on créé un fichier intitulé:
.user.ini
2/ on y met ensuite uniquement la ligne suivante (il ne doit y avoir rien d’autre que cette ligne)
auto_prepend_file = off
3/ on place ensuite ce fichier à la racine du wiki (nous répètons, racine [a]du wiki[/a])
Eexemple dans: /html/wiki/dokuwiki/
De ton côté, Etienne, tu nous dis:
Tu le places à la racine du répertoire dans lequel est installé dowiki ? ou bien dans le répertoire racine /html du site web créé sur ta plaque ouvaton ?
Par ailleurs, ton site se trouve-t-il sur les serveurs node1-6 ?
Le .htaccess est à la racine de dokuwiki (qui se trouve être aussi le dossier html d’ouvaton).
Je ne sais pas si je suis sur le node 1.6
Sur gloux, il me propose la migration vers le 1.5 ou le 1.6, j’aurais donc tendance à penser que je ne suis pas encore sur le 1.6
Où puis je vérifier cette information ?
Maintenant dokuwiki fonctionne sans le .htaccess et… sans le .user.ini !
Mais la supression ou la restauration des fichiers dans le gestionnaire des média se solde toujours par la barre de défilement qui n’arrête pas de défiler (mais la suppression ou la restauration ont bien lieu). J’ai essayé avec le .user.ini mais ça ne change rien.
Je suis le seul à avoir ce bug dans le gestionnaire des médias ?
Alors ça ! Nous sommes jaloux là !
Pouvons-nous te demander quelques infos supplémentaires ?
S’agit-il d’une installation toute neuve et « vierge » d’une version 2012 de dokuwiki ?
Si oui, comment s’est effectuée l’installation: copie de fichiers, ou downloadhelper ?
L’installation s’est faire dans un sous-domaine ? dans un répertoire spécifique ?
As-tu un fichier conf.php à la racine de ton site ?
Nous essayons de comprendre ce qui pourrait diffèrerer …
C’est une mise à jour de la version stable précédente.
J’ai envoyé la version anteater par FTP avec filezilla. J’ai pas encore pris le temps de faire le ménage des fichiers inutiles de la version précédente. Suite à ça, j’ai fait la migration vers le node1.6.
Dokuwiki est directement dans le dossier html du nom de domaine. Pas de fichier conf.php à la racine du site.
Moi aussi je suis étonné que ça marche car il a toujours fallu bidouillé jusqu’ici. Par contre, je radote mais la page “gestionnaire des médias” est buggée (barre de défilement qui ne s’arrête pas pour la suppression ou la restauration de fichier).
J’ai demandé précision à Jérôme : le fichier weirdsession.php est nécessaire : c’est lui qui dit à PHP de stocker les variables de session dans MEMcache, ce qui économise des écritures disque.
Donc, par défaut, Ouvaton garde weirdsession.php.
Maintenant effectivement, si votre logiciel (DokuWiki ou un autre) est incompatible avec notre weirdsession.php et bien il vous faut passer par un .user.ini pour mettre un auto_prepend_file=off
