almawiki :: forum

forum

Cette page reste ouverte à l'édition quel que soit l'état verrouillé ou non du wiki. Mieux que le Bac à Sable (sandbox) qui devient rapidement un vrai bazar, elle peut servir de lieu d'échange d'idées. Ci-dessous une simulation pour tester une sorte de mini-forum élémentaire sans prétention, la présentation des fils de discussion. Notez que tout message peut être modifié, ajusté, supprimé sans problème, l'objectif étant que l'ensemble de la discussion atteigne un état stable qui pourra être éventuellement déplacé, archivé. On n'échange pas des idées pour échanger des idées, passer le temps, pour faire de bons mots (quoique ...), mais pour construire un sujet structuré susceptible d'apporter une information.
Par exemple une discussion sur l'Europe peut commencer comme un plat de nouilles indescriptible opposant les tenants du oui à ceux du non et se terminer par un texte construit collectivement structuré en trois parties : 1) principes, 2) objectifs, 3) modalités, quelque chose dans ce genre qui puisse devenir un outil de réflexion et de proposition.

Attention : au départ ce forum est une simulation ! A part AM, Jojo, Antoine, Lili et les autres sont de pures inventions :). Mais si vous voulez participer, vous êtes les bienvenus ! Par exemple, Emmanuel et Erick sont bien réels :).

Et n'oubliez pas qu'il vous est possible de créer une nouvelle page si vous avez beaucoup à dire, et pourquoi pas votre propre wiki.

alain (11/06/2007, 18h06)

Le site est verrouillé définitivement. Ca se passe maintenant sur epsilonwiki.
A bientôt !

alain (08/05/2007, 09h20)

Après almawiki il y a eu microwiki, puis alphawiki et maintenant epsilonwiki, toujours recommencés à partir de zéro (ou presque) puisque l'objectif est le zen du wiki : recherche dun graphisme minimaliste, administration la plus discrète possible, syntaxe HTML universelle, installation évidente. Epsilonwiki propose une nouvelle syntaxe HTML simplifiée qui semble réellement facile à mettre en oeuvre, à défaut d'un éditeur WYSIWYG toujours à venir. Rendez-vous sur ce dernier wiki si ça vous tente ...

alain (06/01/2007, 17h10)

Une mise à jour est disponible (v.20070102) assurant une meilleure sécurité au fonctionnement de ce wiki, la mise à jour concerne le dossier meca qu'il suffit de remplacer.

alain (29/11/2006, 12h15

Vous en avez assez d'écrire du HTML ? Vous rêvez de Wysiwyg ?
Observez cette image :

,
installez Xinha dans FireFox et appréciez !
Fonctionne sur tous les wikis sans aucune modification :), pas mal non ?

alain marty le 18/11/2006, 6h40

Faille de sécurité : la dernière version v.20061118, corrige une faille de sécurité ; ce serait bien de mettre à jour votre wiki en chargeant la dernière archive : admin

alain marty le 31/10/2006, 12h

Bravo !
A propos, le site portail de microwiki, base du modèle que tu utilises, c'est microwiki et non almawiki ; microwiki a également un forum.

Yohann FLORENTIN (31/10/2006, 11h42)

Ca y é le problèm é résolu... Wiki Yohann

Yohann FLORENTIN (31/10/2006, 9h42)

Bonjour. J'ai ouvert un nouveau compte sur free. J'ai chargé mon wiki sur celui-ci et j'ai un problème...Comment je fais pour le résoudre ? Tu pourras le regarder ici... Wiki Yohann

Eric(29/10/2006)

Bonjour Alain. A toute fin utile, voici un lien qui pointe vers une archive zip contenant un thème de ma composition
pour almawiki. Ce thème est basé sur le thème Basic. Tu pourras le récupérer ici... Thème Mer

alain marty le 10/10/2006, 14h

J'avoue ne pas bien comprendre la question, et je reste dans l'attente de la réponse à la question que vous avez posées à jean-emile.com, dont je ne situe pas très bien le contenu des services, non plus. A suivre...

vickie (08/10/2006, 15h 50)

Bonjour,

J'ai posé la question sur Jean-Emile.com sur ce post : Pb d'installation de Microwiki et je suis pour l'instant en attente d'une réponse.

En attendant, je voudrais soumettre ici la réflexion suivante. Un des (nombreux) avantages que je trouve à utiliser Microwiki consiste en ceci qu'il ne s'édite pas, à la différence de beaucoup de wiki, en double-cliquant sur les pages. On n'a donc pas besoin de procéder au verrouillage préalable du texte (comme c'est le cas pour TiddlyWiki, lequel suit en cela la règle générale) pour pouvoir afficher les définitions du dictionnaire Alexandria, ce qui ajoute aux atouts que Microwiki présente pour une utilisation pédagogique, ainsi que l'article de présentation d'Almawiki sur Framasoft souligne déjà cette destination privilégiée pour le logiciel. Je suis moi-même parvenu très facilement à insérer sur d'autres logiciels les quelques lignes de code nécessaires pour profiter de ce service gratuit précieux, mais je n'ai pas encore essayé de le faire pour Microwiki, estimant qu'avec les talents pédagogiques qui sont ceux de son auteur, on devrait bientôt avoir droit à une procédure d'installation pouvant servir à toutes les personnes intéressées. Est-ce que je me trompe ? Suggestion : afin de soulager encore plus les utilisateurs, qui ne sont pas tous des geeks, pourquoi ne pas en profiter pour insérer directement au bon endroit ces quelques lignes de code (Alexandria - install) de façon à les en faire profiter par défaut. Après tout, cela est d'autant moins intrusif que pour s'apercevoir de l'installation de ce service, il est généralement nécessaire que l'utilisateur soit prévenu de sa présence du fait qu'il lui vient rarement à l'idée de double-cliquer sur du texte, en dehors des boutons pour lesquels le service ne s'applique pas. Libre à eux d'ailleurs alors de les neutraliser, soit en les commentant, soit en les supprimant tout simplement. Peut-être même est-il possible de prévoir un dispositif permettant depuis l'interface de basculer entre les deux situations : activation/désactivation du service. Merci d'avance.

alain marty le 06/10/2006, 20h

Désolé pour cette réponse tardive, j'étais en déplacement ...
Je note qu'à cette adresse Musiwiki le navigateur affiche maintenant correctement les caractères (UTF-8) mais qu'il est toujours impossible de valider l'édition d'une page (j'ai essayé sur sandbox). Ce n'est surement pas un problème de Javascript, les notes fonctionnent, la prévisualisation locale également. Côté serveur le PHP est fonctionnel (sinon le site ne démarre même pas), mais c'est peut-être dans son paramétrage qu'il y a un problème ; avez-vous des messages d'erreur PHP ? Concernant les autorisations, sur free il n'y a pas le choix, c'est fixé à 644 pour les fichiers, 700 pour les répertoires, impossible à modifier. Heureusement ça marche. Pour l'instant je ne sais quoi vous répondre ... Peut-être qu'un visiteur plus qualifié pourra nous expliquer ce qui se passe ... A suivre.

vickie (06/10/2006, 14h 55 = suite du message précédent)

Bonjour,

Un moment j'ai cru que c'était dû au fait que j'avais omis de créer un dossier « sessions » à la racine de mon site, mais après y avoir remédié (ainsi qu'au même niveau où se trouve mon microwiki, c'est-à-dire dans le dossier « htdocs », comme il est demandé de le faire du fait que le serveur est géré avec VHCS), le problème subsiste.

À noter que j'ai le même problème de validation de page sur un autre espace, géré avec la même technologie, sur lequel j'ai également installé Microwiki, même si là l'affichage est normal (voir : Musiwiki). À tel point que j'en suis venu à penser que l'archive pouvait être corrompue et que j'ai décidé de l'installer chez Free.… où tout fonctionne bien : affichage des caractères spéciaux et enregistrement après validation. Ce n'est pas non plus une affaire de droits : j'ai mis tous les droits de lecture et d'écriture (777) aux dossiers du wiki et des sessions. Alors ? Ces hébergements ne supporteraient pas le JavaScript ? Est-ce possible ? Pourtant je n'ai rien lu de tel sur les sites en question...

vickie (05/10/2006, 19h 40)

Bonsoir,

Je viens d'installer un µwiki sur Jean-Emile.com - Hébergement gratuit et Sans PUB à l'adresse suivante : DyrECT Non seulement l'affichage des caractères spéciaux se fait mal, mais je ne peux modifier aucune page. J'obtiens alors le message suivant : "Could not write page accueil". Je précise que j'ai fait l'essai de placer le site à la racine, mais le résultat est le même. Ce problème est-il connu ? Que demander à mon hébergeur pour trouver une solution ?

Merci.

alain marty le 02/10/2006

Effectivement, il semble impossible d'intégrer directement un formulaire dans la page : le formulaire est affiché dans l'éditeur (et non son code source), les boutons de l'éditeur sont paralysés, et la page est irrécupérable, sauf à passer par l'historique. Bon ! Conclusion provisoire, c'est donc une bonne idée de bloquer l'intégration de balises form et il faudra passer par un iframe pour appeler un fichier html externe contenant le formulaire. Je viens de faire le test, ça marche. Désolé donc, intégrer un formulaire semble hors de portée et il est préférable de bloquer l'intégration directe dans une page.

fred (2/10/2006)

salut,
Je suis en train d'adapter le microwiki à mes besoins et j'ai mis un form sur une de mes pages (j'ai bien autorisé les form dans le config.php).
Un problème se pose pour éditer ma page lorsque ce form contient un textarea, je ne sais pas trop pourquoi mais il m'est impossible de vivualiser et enregistrer les changements. et la fin du form avec la balise < / form > est absente.

alain marty le 28/09/2006 , 20h50

intéressant en effet, et Tiddlywiki est vraiment extraordinaire. Je vais ... étudier ça de plus près (installation, taille du code ?) et en passant je vais rechercher pour µwiki ... une écriture plus lisible pour créer une ou plusieurs stretching note(s) en cascade :) :)

vickie (28/09/2006, 17h 40)

Simplement un élément de réflexion avec ce Tinderbox Stretchtext Writing System dont on trouve déjà une application intéressante du même concept avec les notes si appréciées de µwiki. À noter que l'idée de l'introduire dans TiddlyWiki vient d'être proposée sur un post de TiddlyWikiDev : Stretchtext system for Tinderbox - lovely new way to disclose info.

Fred le 27/09/06, 09h34

En effet, pardon de ne pas avoir fouillé l'aide du microwiki, il a vraiment l'air petit mais costaud ce microwiki... je l'adopte de ce pas. Merci beaucoup !

alain marty 26/09/2006, 17h 00

Non seulement c'est possible, mais c'est bien plus fiable, la page identification donne toutes les explications. Il y a plusieurs niveaux de protection, du blocage total (il faut un accès FTP pour déverrouiller le wiki) à l'état ouvert sous réserve d'une identification (qui peut être bidon...) en passant par le verrouillage/déverrouillage depuis le navigateur avec un mot de passe. De plus, le wiki n'est déverrouillé qu'en local, le responsable du site peut travailler sur un site ouvert pour lui et fermé pour les autres. Par défaut c'est la solution la plus ouverte qui est proposée.

Fred (26/09/2006)

1000 Bravo pour le wiki, simple et joli, je cherchais ça depuis longtemps.
Juste une petite question, pourquoi sur le microwiki n'est t-il plus possible de verouiller tout le wiki ? je trouvais ça pratique lorsque l'on veut pouvoir être le seul à mettre à jour ses pages, même si c'est vrai que ça va un peu à l'encontre du concept wiki je trouvais ça bien pour ce que je veux en faire. Du coup je n'ai pas opté pour le microwiki juste pour cette raison...

vickie (25/09/2006, 18h 40)

Merci Alain, ça va en effet mieux ainsi : tout fonctionne admirablement à présent.

alain marty 25/09/2006, 17h 00

oui, et j'aurais dû le préciser : il y a un div id="visualisation" dans le fichier template.html et une règle CSS correspondante ; le mieux est de remplacer tout le dossier themes (après avoir éventuellement récupéré les fond.jpg et logo.gif personnels).

vickie (25/09/2006, 16h 40)

Quelle réactivité ! Les choses vont vite et on ne va pas s'en plaindre. Pour la mise à jour, j'ai supposé qu'il suffisait de recharger le fichier lib.php ainsi que script.js du dossier meca dont les dates ont changé, mais la prévisualisation locale ne donne rien chez moi (alors que JavaScript est bien activé. Est-ce qu'il y aurait d'autres fichiers qui se trouvent aussi concernés ?

alain marty 25/09/2006, 12h 00

L'éditeur dispose maintenant de 4 boutons [annulation, prévisualisation locale, prévisualisation distante, validation] avec le confort de la prévisualisation sous l'éditeur ; cf microwiki.

vickie (23/09/2006, 23h 23)

Installé, essayé, adopté : bravo ! voilà qui est tout à fait clair.

alain marty 23/09/2006, 18h 40

Pour l'instant, j'ai amélioré le tag (bien visible en tête de page), il n'est pas multiplié par le nombre de prévisualisations et il est automatiquement supprimé à la validation finale. C'est visible sur le site µwiki et l'archive mise à jour est téléchargeable (seul le fichier lib.php a changé) !
La prévisualisation enregistre bien les modifications apportées à la page, mais uniquement dans le fichier page.txt, aucun fichier n'est ajouté dans l'historique afin de ne pas l'encombrer. Donc il y a bien enregistrement.
Concernant la page admin, elle a effectivement disparu au même titre que la page aide ; ces deux pages peuvent être créées à tout moment (comme la page accueil), je viens de le faire pour la page aide et je ferai de même pour admin d'ici peu. Les seules pages codées en dur (et donc créées à la volée et non éditables) sont les pages recherche, index, history, themes, identification, et téléchargement. Ces hésitations viennent de la volonté de tout réduire au minimum pour nettoyer le code et bien distinguer ce qui est une page de données et de liens (accueil, admin, pages utilisateur, ...) des pages de commandes (historique, téléchargement, identification,..).
Concernant l'identification, justement, et la gestion des thèmes en local (non modifiables par tout un chacun), j'ai bien hésité parce que ça entraine la nécessité de passer par des procédures de sessions et des autorisations de cookies ; pas si facile à traiter à tous les points de vue, notamment sur free avec la nécessité de créer un dossier sessions à la racine.
A +

vickie 23/09/2006, 17h et quelques

Merci Alain pour toutes ces précisions. Le choix de jouer sur les deux tableaux JavaScript et PHP me semble judicieux dans le souci de rendre l'utilisation de l'outil la plus universelle possible, même si pour moi la première solution me convient parfaitement.

En parlant de « fusion » des deux projets j'avais bien compris qu'on était en cours de processus, mais je me demandais si le nouveau mode de visualisation ne venait pas d'un choix indépendant de la technique. Me voici rassuré.

Ce qui me rassure moins c'est que, au-delà de la simple question esthétique due à la présence, provisoire, du fameux tag, je ne sais jamais où j'en suis : est-ce que j'ai bien enregistré ou est-ce que je n'ai fait que prévisualiser ? Après avoir testé, j'ai bien l'impression que, pour l'instant, le fait de prévisualiser le document équivaut à l'enregistrer, mais j'aimerais en être sûr, et ce d'autant que cela semble être en contradiction avec ce que je lis plus haut : « Afin de ne pas oublier la validation finale, il devenait nécessaire de laisser une marque et voilà la raison de ce "tag" en tête de page »… Ce n'est pas du tout ainsi que j'expérimente les choses sur mon espace perso chez Free !

Une autre question m'est venue depuis, qui aura peut-être droit à la même réponse : pourquoi la disparition en page d'accueil d'un lien menant vers « la page admin pour faire un peu d'administration » ? Quand on rétablit le lien, celui-ci ne mène évidemment plus à rien en ce qui concerne les points suivants : « pages récentes », « thèmes », et « verrouillage » ?

-> Une question : êtes-vous gêné par la nécessité d'une identification ?
Non, c'est plus conforme à ce qu'on trouve habituellement sur les wiki que l'amusante forme de validation anti-spam d'abord envisagée.

alain marty 23/09/2006, 15h ++

Pour information complémentaire, il est toujours possible de télécharger des fichiers (images, ...) dans le dossier data du wiki, mais j'ai laissé cette fonctionnalité non évidente tant que je ne suis pas sûr d'avoir bien traité les failles de sécurité. Au besoin, sachez que l'appel se fait en écrivant un lien qui ressemble à ça : index.php?action=load. A suivre...

alain marty 23/09/2006, 15h

Message reçu ! La fusion n'est pas encore faite, il faut être prudent. Dans Almawiki la prévisualisation fait appel à un code Javascript, traité en local donc rapide, mais qui ne traite pas complètement le contenu, notamment les groupes d'images et qui ne fonctionne plus si Javascript est désactivé. L'alternative que j'ai étudiée dans µwiki est d'abandonner le traitement Javascript et de ne faire appel qu'au PHP sur le serveur, avec un mode prévisualisation sans sauvegarde dans l'historique et un mode validation avec sauvegarde en fin de cycle d'édition. Afin de ne pas oublier la validation finale, il devenait nécessaire de laisser une marque et voilà la raison de ce "tag" en tête de page qui n'est pas élégant j'en conviens. Dans le sens que vous souhaitez, mon prochain objectif est donc :

de rétablir la prévisualisation sous l'éditeur de texte, ce qui supprimera le marquage du contenu de la page par un tag "prévisualisation",
et de laisser le choix entre le mode Javascript (rapide, mais incomplet et dépendant de l'activation de Javascript dans le navigateur, et le mode PHP (légèrement moins rapide et faisant appel aux ressources du serveur, mais totalement identique au final.

Ceci étant, vous pouvez continuer d'entrer vos données dans votre dossier pages, sans risque d'incompatibilité ; dans le pire des cas il est toujours possible de revenir au moteur Almawiki.
Une question : êtes-vous gêné par la nécessité d'une identification ?
Et merci pour votre intérêt.

vickie (23/09/2006)

Bravo pour le wiki en général et pour la fusion des deux projets en particulier : plus lisible. En effectuant la mise à jour des pages de mon Almawiki sur mon tout nouveau µwiki je constate cependant deux petites choses, peut-être liées d'ailleurs, qui modèrent mon enthousiasme, jusqu'alors sans faille, pour ce logiciel. La première, c'est la suppression de la possibilité de continuer à voir la page sous forme d'édition en mode prévisualisation en même temps que la prévisualisation elle-même. Cela était pratique pour naviguer à la recherche du ou des passages à modifier avant validation. Il conviendrait selon moi d'en rétablir la possibilité, au moins à titre optionnel (case à cocher ?). Le deuxième point qui me gêne (est-ce un bug ou une fonctionnalité ?), c'est la rémanence de la mention « mode prévisualisation » en haut de chaque page en ayant fait l'objet. Ces deux réserves faites, bonne continuation en tout cas.

alain marty (21/09/2006)

En fait Almawiki ne bouge plus depuis la naissance de son bébé microwiki. Mais le bambin a pas mal muri, chaque jour on le voit grandir, se recaler ici ou là, s'étoffer et le jour est proche où il remplacera sa maman ... Tout le travail sur µwiki a été fait en conservant absolument inchangé le dossier « pages », autorisant ainsi les mises à jour sans remettre en question le travail accompli (données, liens, structure). Je vous propose de télécharger la dernière archive µwiki du jour et de la tester : copiez (dupliquez) simplement votre dossier pages dans le dossier µwiki, et ajustez le nom du wiki dans le fichier config.php. C'est tout ... et dites moi ce que vous en pensez, ce qui marche et ce qui ne va pas ! J'ai déjà effectué ainsi le transfert almawiki -> µwiki sur ces deux sites : alain.marty, NTIC.

Mr BOB (15/09/2006)

Ca bouge beaucoup AlmaWiki? où c'est qu'on peut trouver les différentes évolutions?.
Continuez c'est trop cool.

Mr BOB (21/09/2006)

En réponse a PMWIKI qui veut installer AlmaWiki sur une clé USB. Pas de PB j'ai fait la manip avec Movamp (Apache+Php+Mysql App Portable sur une clé USB) et almawiki dézippé sur Movamp\mnt\var\www\wiki.
Ca marche nickel j'ai modifé aucun paramètre.

alain marty (15/09/2006)

modifier la liste des types autorisés pour le téléchargement

Ca se passe dans deux fichiers :

dans le fichier _perso_.php :

define( "WIKI_TITLE", "wikimodele" );
define( "LOGIN", "login" );
define( "PASS", "pass" );
define( "SIZE_MAX", 100 );   <--------- augmenter la taille autorisée, mais attention !!!

et dans le fichier lib.php :

ligne 357 : {	// types valides : *.jpg ou *.jpeg, *.gif, *.png, *.pdf, *.wav, *.qt ou *.mov
ligne 358 :     $types = array( "image/jpeg", "image/gif", "image/png", "application/pdf", "audio/x-wav", "video/quicktime" );

ajouter les types souhaités dans le tableau ci-dessus, ou de façon plus abrupte désactivez la ligne 366 où se passe le contrôle,

ligne 366 :  elseif ( !in_array( $type, $types ) ) $chaine = LOAD_ERR_2;

mais ça devient assez risqué !!!

à + si problème.

pmwiki (15/09/2006)

Cher Alma,
Ne sachant pas exactement où il convient de laisser un message, je me permets de le mettre en plein milieu:
Comment fait-on pour modifier la liste des types autorisés pour le téléchargement ?
J'aimerais en effet pouvoir utiliser mon wiki comme clé USB.

votre nom (jj/mm/2006)

éditez la page pour laisser ici votre message :

...

...

jipi (07/09/2006)

J'ai installé almawiki, voici mes quelques remarques (suite)

alain marty (05/09/2006) ... suite

A part ça, en décompressant l'archive sous Windows (et peut-être sous Linux), vous trouverez un fichier "_MACOSX" et dans chaque répertoire des fichiers ".DS_Store" qui sont des "scories" issues du monde MAC et que vous pouvez détruire sans problème. Ces fichiers contiennent des informations utilisées par le Finder du Mac et inutiles ailleurs. Il se peut que ça génère des warnings dans votre logiciel de décompression, en principe sans incidence.

jipi (07/06/2006)

En fait, sous Windows, il y a un répertoire MACOSX avec toute l'arborescence et dans chaque répertoire juste le fichier DS_store, et le répertoire wikimodele avec toute l'application et dans chaque répertoire là aussi le fichier .DS_store. Pas de problème lors de la décompression

alain marty (05/09/2006)

Mille excuses, c'est maintenant réparé ! Ce qui est étrange est que les chemins sont écrits avec des "/" sous Unix, des "\" sous Windows et des ":" sous Mac ; sur Mac un chemin comprenant des ":" est accepté, le système en fait son affaire en les remplaçant par des "/", et c'est sur sur Windows où le ":" n'est pas utilisé dans un chemin que le système ne l'accepte pas ! Conclusion, ne pas utiliser des noms de page construits sur le schéma prefixe:nom_page. On pourra essayer prefixe-nom_page ou autre chose.

jipi (04/09/2006)

J'ai récupéré le zip pour installer almawiki, mais je ne peux décompresser l'archive (avec Winzip ou Winrar), car cela génère une erreur à la création du répertoire "wikimodele_20060901\history\en:admin" => sous WIndows on ne peut avoir un nom (répertoire ou fichier) qui contienne ":"

alain marty (04/09/2006)

Les adeptes du minimalisme pourront tester un essai de wiki réduit à presque rien, appelé : microwiki. Que pourrait-on encore enlever ?

alain marty (01/09/2006)

Les messages sont à présent traités dans l'ordre chronologique inverse, ça parait plus logique. C'est encore mieux si on met la date, mais rien n'est obligatoire.

Erick

Moi je découvre almawiki et j'ai installé sur une platforme Linux et c'est follement rigolo ! je modifie sur la pointe des pieds mais petit à petit ça avance.
voir le site en question.
Bravo Alain pour le bon boulot.
Erick à Laval

Emmanuel Ostenne

Cela a l'air et cela EST simple.
Tel quel ça marche super.
On peut ensuite mettre les mains dans le moteur pour le bidouiller : ajouter ses balises wiki/html, intégrer des applets à disposition des utilisateurs, ...
Comme c'est léger et clair, on y prend plaisir et on se fait plaisir en informant Alain de ces modifs qu'il répercute quand ça peut vraiment être utile : le coup des caractères spéciaux est un exemple de collaboration grâce au libre !
A consommer sans modération.

??

ça a l'air très simple : je vais essayer de l'installer : Merci !

am

quelques améliorations dans l'archive almawiki v.20060823 : un meilleur affichage des mots recherchés (pas encore idéal...) et un nouveau thème : basic_2.

am

C'est gratuit, Lili, et disponible depuis la page admin. C'est un travail libre d'exploration du concept de wiki, rien de plus, un travail de réécriture à partir du plus petit wiki connu (rowiki aujourd'hui disparu, cf licence). J'ai beaucoup de mal à comprendre un concept si je ne peux pas participer à son "implémentation", comme on dit. A la différence de nombreux autres wikis dont j'ai pu analyser le code, celui de rowiki était assez simple (150 lignes compactes) pour que je trouve le courage de le décortiquer, puis de le réécrire de façon plus lisible (à mon sens). L'avantage de la lisibilité est que il m'a été plus facile d'ajouter quelques fonctionnalités qui me paraissaient utiles, quasi indispensables (insertion de code HTML, verrouillage, téléchargement, thèmes,..). Pendant six mois j'ai pu tester en grandeur nature le concept à l'école d'architecture de Montpellier (http://ensam.wiki.free.fr/), et apprécier peut-être un peu mieux les limites du système et l'utilité de certaines fonctions. Almawiki est une étape, un outil pour aller plus loin dans ce thème qui m'intéresse de plus en plus : la création et l'échange de nos informations.

lili

Où peut-on acheter cette petite merveille ?

am

dernière mise à jour du moteur wiki : 17 août 2006. Disponible depuis la page admin, aide à la mise à jour consultable à la page divers. N'hésitez pas à laisser vos commentaires dans ce forum.

jojo

/\{([0-9a-zA-Z .()/_-]+\.(jpg|gif|png))\|([0-9+-]+)\|([0-9a-zA-Zéèêàùâç :.()_-]+)\}/g toi-même eh banane !!!

am

Il m'a été dit que sur certaines configurations les affichages ne se faisaient pas correctement, empêchant totalement le fonctionnement dans le cas des thèmes "mini" et "lessismore" qui masquent le menu. Il semble que le problème vienne d'une erreur dans le script de visualisation qui bloquent tout le Javascript (masquage/affichage des menus, des notes, affichage des groupes d'images,...), et plus précisément d'erreurs d'écritures dans les expressions régulières. On y travaille. Pour info jetez un coup d'oeil sur l'allure d'une expression régulière : /\{([0-9a-zA-Z .()/_-]+\.(jpg|gif|png))\|([0-9+-]+)\|([0-9a-zA-Zéèêàùâç :.()_-]+)\}/g et vous aurez une petite idée du casse-tête que c'est, sachant que ça peut fonctionner sur un navigateur et pas sur un autre ...
Au fait, n'oubliez pas d'activer Javascript dans vos navigateurs, le pack Windows SP2 le désactive d'office, probablement pour amuser la galerie :-(
-----> PS : J'ai pu constater que les problèmes d'affichage cités plus haut apparaissaient dans le navigateur Firefox 1.0. N'hésitez pas à passer à la dernière version 1.5.x, gratuite et open-source !

am

C'est une bonne comparaison ! On retrouve même les trois niveaux d'utilisation du tableur et du wiki : on se contente dans un premier temps d'entrer des informations élémentaires (sur une grille dans le tableur, texte au kilomètre et images dans les pages du wiki), puis on se hasarde à écrire quelques formules (relations simples entre cellules dans le tableur, enrichissements typographiques et liens internes dans un wiki), enfin on entre dans le monde infini des combinaisons complexes (formules sophistiquées, structures riches dans le tableur, compositions graphiques, interactivité avec l'utilisateur dans un wiki), le tout à son rythme.

jojo

En somme, on redécouvre l'équivalent sur le web du concept génial de tableur, une tableau orthogonal de cellules vides pouvant contenir du contenu et des relations entre cellules « sous l'entière responsabilité du ou des rédacteurs ».

am

Ce qui me parait vraiment essentiel et que je recherche dans le concept de wiki, c'est la liberté de structuration des pages. Les blogs contraignent les interventions dans un corset étroit (et puissant) de billets et de commentaires définitivement organisés de façon chronologique et certains wikis proposent tant de bonnes choses en interaction (sommaires automatiques, placement des images, et puis tracbacks, reto-machins, pings, pongs, stats, ...) qu'on finit par ne plus savoir où l'on est. Le wikimodèle propose peu de choses, quatre pages (accueil, admin, aide, sandbox). Il est conseillé de laisser la page admin intacte, la page aide peut être réduite à un simple lien vers l'aide générale située dans le portail almawiki, on peut faire n'importe quoi avec la page sandbox. Tout commence avec la page accueil qui pourra être entièrement effacée et contenir le plan du site à venir. Toutes les autres pages seront une composition entièrement libre de contenu et de liens laissée à l'entière responsabilité du ou des rédacteurs. Les quelques liens donnés en exemple illustrent différentes possibilités et laissent entrevoir des tas d'autres à venir.

amédée

quand est-ce qu'on mange ?

am

Je contrôle le bon fonctionnement du wiki sur Mac avec Firefox 1.5 et Safari et sur Windows avec Firefox 1.5 et Internet Explorer 6. J'ai pu constater un disfonctionnement du Javascript sur un poste Windows avec Internet Explorer 6. Si vous avez ce genre de comportement, soyez gentil de me le signaler.

am

C'est bon ! Il suffit en effet de faire un test sur l'existence de l'expression %antipiratage% en tête de chaque page pour bloquer le texte écrit par le robot et voir affiché à la place "PIRATAGE" en gros titre. Il suffira de retrouver le contenu précédent dans l'historique. Pour l'instant cette fonction n'est pas activée (cela supposerait de taguer toutes les pages existantes avec l'expression %antipiratage%. De plus il serait préférable d'aller au delà d'un simple blocage et de reconstituer automatiquement l'état précédent. On y travaille ...
----> PS : Pour l'instant, dans la dernière mise à jour, une autre solution est à l'essai ; la découvrirez-vous ?

antoine

On suit ...

am

L'idée au début était de ne pas compliquer la vie des gens avec ce genre de manip. Une expérience de 6 mois ( ensam.wiki ) a bien fonctionné sans problème. Mais les idées peuvent évoluer et il sera toujours temps d'installer ce genre de filtre. J'ai constaté que dans le piratage des pages du site (creuze) le robot avait effacé tout le contenu de la page pour le remplacer par une série de liens (heureusement sans effet du fait d'une erreur sur l'écriture des raccourcis wiki). On peut imaginer «taguer» chaque en-tête de page avec un texte invisible du genre %antipiratage% dont le moteur wiki s'assure de la présence pour afficher la page ; la disparition de ce texte en cas de piratage pourrait bloquer l'enregistrement de la page. A suivre ...

jojo

De nombreux wikis filtrent les contributeurs, en leur imposant au moins de laisser une adresse mail valide, de s'inscrire, voire de recopier des caractères apparaissant sur une image. Pourquoi ne pas prendre ce principe ?

am

Parce que nous sommes entourés de robots sans pitié qui peuvent inonder les pages de centaines de liens vers des saletés diverses (cf http://p.creuze.free.fr/ ), et qu'un wiki ouvert à tous vents doit être surveillé comme le lait sur le feux. Ce qui n'est pas toujours possible.

jojo

Bonne idée cette page "forum", mais pourquoi verrouiller un wiki par essence ouvert à tous ?

page modifiée le 11/06/07 18:07 | date : 6/04/25 10:21 | IP : 3.12.163.14 | cpu : 2 ms | moteur : almawiki v.20070218

ensam