Cette page contient quelques remarques suite à mon installation d'almawiki
Tout d'abord félicitations, c'est un outil formidable, qui m'a séduit car il est simple et sophistiqué à la fois.
Je me suis d'abord interessé à la technique du tout un site dans un seul fichier html, comme WikiOnAStick ou Tiddlywiki, mais c'est du mono utilisateur, et à la fin le fichier html devient trop gros. Après je me suis tourné vers des wikis "light", sans base de données : Wikikubbe est un tout petit soft qui fait beaucoup, mais un peu plus rustique que votre projet.
jpduboust chez gmail point com
...
...
alain marty (09/09/2006 - 07h40)
Il fallait y penser, et c'était si simple :)), merci beaucoup.
Concernant le safe_mode, il est bien à ON sur free et il est à OFF sur mon installation Apache sur Mac. Sur free le safe_mode_exec_dir est à "no value" et à "/usr/local/php/bin" sur le Mac, ce qui explique (peut-être) le fait que je sois toujours obligé de retoucher les autorisations d'un nouveau répertoire almawiki en local afin de l'ouvrir en écriture ainsi que ses enfants.
La suggestion que vous faites sera certainement la solution au problème rencontré. Je me souviens que c'est le système que j'utilisais dans les tout premiers sytèmes d'exploitation que j'ai connus, sans concept de répertoires, tous les fichiers à plat. Internet c'est aussi un retou aux sources, aux bons petits fichiers en texte brut et aux astuces de nommage.
A part ça, vous dormez de temps en temps ?
jipi (09/09/2006)
Raccourcis wiki
"Notre équipe d'ingénieurs hautement spécialisés travaille nuit et jour à la recherche de la solution de ce problème d'affichage,..."
J'ai décroché mon titre d'Ingénieur Hautement Spécialisé DPLG monsieur le professeur ?
jipi (09/09/2006)
Pour la gestion de l'historique, j'ai testé la modif du script, mais cela ne change rien. J'ai un compte sur free et j'ai testé almawiki, cela fonctionne bien. Et free fonctionne avec le safe_mode à on. Sur des forums j'ai trouvé que la fonction mkdir en safe_mode on sur des hébergeurs comme sivit, nfrance (c'est le mien), ... ne devait pas être utilisée en php car on ne peut jamais copier de fichier dans le répertoire généré même en faisant un chmod dans le php. Pour contourner, il y a des usines à gaz qui en php, font une connexion ftp avec le compte en dur dans le script, pour faire le mkdir sous ftp et donc avec des droits différents qu'en php direct où se sont les droits du compte du serveur apache qui sont actifs.
Une suggestion, si plus d'utilisateurs rencontraient le pb, un dossier history qui contient toutes les pages d'historique dont le nom complet serait nom_de_la_page+date_heure.bak.
alain marty (09/09/2006 - 00h17)
Non aucun mécanisme de gestion de lock n'est prévu pour l'instant, c'est le dernier qui enregistre qui gagne et je ne vois pas encore de solution simple. On peut quand même retrouver sa version dans la liste des sauvegardes, en clair on ne perd pas son travail, c'est au moins ça de gagné :)
Concernant le problème de création du dossier backup et du fichier historique, je ne comprends pas parce que je ne peux pas reproduire le processus ni en local (sur Mac/Apache ou sur Windows/EasyPHP) ni sur le serveur de free. Je vous propose de télécharger par FTP un dossier almawiki sur free ... et de tester le fonctionement (le dossier n'est pas en lieu sûr et il vaudra mieux le détruire après le test). Chez quel fournisseur êtes-vous ?
Dans rowiki (qui m'a servi de base) l'historique d'une page était mémorisé dans un seul fichier par ajouts des versions successives des pages ; le problème était que ce fichier pouvait grossir démesurément, j'en ai vu jusqu'à 1 à 2 Mo pour une page ne dépassant pas quelques ko. La solution de l'historique sous la nouvelle forme me paraît être la seule viable et c'est dommage que ça ne fonctionne pas chez vous :(
j'ai relevé une erreur dans le fichier lib.php : dans la fonction write(), vers la ligne 227, le test :
if (! $dir = @opendir($complete_dir_s))
mkdir($complete_dir_s);
qui teste l'existence du répertoire en tentant de l'ouvrir ... et qui ne le ferme pas s'il existe, doit à mon avis être remplacé par :
if (! is_dir($complete_dir_s))
mkdir($complete_dir_s);
qui se contente de tester l'existence du répertoire. Il se peut que ça génère une erreur bloquant le fonctionnement. Je ne l'ai pas encore corrigé dans la version en ligne d'almawiki et dans l'archive v.20060901. Demain je le fais :)
jipi (08/09/2006)
J'ai remis l'introduction qui a dû disparaitre car nous devions éditer la page au même moment. Cela entraine une question : il n'y a pas de mécanisme de gestion de lock ou d'accès concurrents ?
Pour la gestion de l'historique la seule solution qui fonctionne, c'est créer le répertoire par ftp sur le serveur avant d'ajouter une page. Donc pas envisageable. J'ai enlevé le test d'erreur sur la création des fichiers historiques. C'est dommage car c'est justement la fonction qui m'a permis de restaurer l'intro. Et j'utilise almawiki en local sur mon pc, pour des tests c'est plus facile, mais pas une fin en soi.
jipi (07/09/2006)
Je rencontre un problème lors de la création d'une nouvelle page. Cela intervient à la mise en place de l'historique associé. Le répertoire est bien créé, mais il y a une erreur lors de la création du fichier .bak . J'ai effectué des recherches et trouvé une explication (qui solutionne aussi d'autres pb rencontrés sur des scripts d'autoinstallation en php). Sur les serveurs où le safe mode est activé, sous php on peut créer un répertoire, mais il n'est utilisable par personne, même si on fait un chmod 777. En conclusion il n'est pas possible dans du php de créer des répertoires sur des serveurs ou le safe mode est activé, ce qui est fréquent chez les hébergeurs internet.
La fonction index des pages (qui existe sur votre site perso) a disparue au profit de recherche ? Pourrait-il y avoir le pendant, autoriser une recherche "vide" qui donnerait la liste de toutes les pages du wiki.
Pourquoi y a t-il dans la plupart des répertoires un fichier index.html, c'est juste un piège pour éviter les connexions directes à cette endroit ?
alain marty (07/09/2006)
concernant les problèmes d'écriture : je ne connais que free comme hébergeur, dont le serveur n'accepte aucune modification des autorisations (genre chmod 777), les répertoires sont automatiquement réglés en "drwx------" et les fichiers en "-rw-r--r--" ; en local (Apache sur MacOSX) je déclare tous les répertoires et fichiers ouverts en lecture et écriture pour tous. Je ne sais pas vous répondre pour l'instant, vous êtes le premier à poser ce problème. A suivre ...
concernant la fonction index : je suis toujours à la recherche de fonctions utiles et je tatonne ; la fonction index liste effectivement toutes les pages du wiki, ça peut être un problème dans sa version brute s'il y a trop de pages. Dans mon site j'utilise ce fichier lib.php. Téléchargez-le et dites moi si ça répond à votre question. Vous pourrez voir que dans la variante microwiki je ne garde que cette fonction "index" avec l'indispensable "editer...".
concernant les fichiers index.html : c'est effectivement un piège qui bloque l'affichage du contenu du répertoire ; il y a d'autres méthodes (fichiers .htacces) mais pourquoi pas celle-là ?
...
Merci pour votre intérêt :), ... et au fait votre installation fonctionne-t-elle maintenant ? avez-vous trouvé une solution ?
page modifiée le 09/09/06 08:08 | date : 7/04/25 09:03 | IP : 3.140.185.223 | cpu : 2 ms | moteur : almawiki v.20070218