Wikini

SuggestionsFonctionnalites

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-18-226-93-207.us-east-2.compute.amazonaws.com
Ici vos suggestions d'amélioration ou de nouvelles fonctionnalités.

Sommaire de cette page :

Faisant l'objet d'une page propre :

Acces direct vers les commentaires

pourquoi ne pas faire un systeme avec #commenaires dans l'url pour pouvoir descendre directement dessus surtout si la page est longue ?
http:<l'URL>#commentaires
quand on clique sur Afficher les commentaires.
Car quand on veut voir les commentaires et que la page et longue wikini genere la page mais les commentaires sont tout en bas.
Fonctionnailité simple et legere à intégrer facilement.

Extraction en DocBook?

Cette fonctionnalité permet de constituer une documentation en wikini (donc travail collaboratif...), en respectant une norme de formatage basée sur celle de WikiNi mais suffisamment structurée (par celui qui saisit une page) pour sortir du DocBook?.
L'extraction au format DocBook? permet la génération de plusieurs formats : HTML (regroupement de pages wikini en sections ou en un seul document), PDF, ...
Elle commence à être mise en oeuvre sur la FaqEagle.
Le besoin d'origine est :
 Plus d'infos : sur ma page -- BenoitAudouard 20031202

comment vous trouvez l'idée ?

http://martignier.net/test.jpg
j'ai un refresh tout les 60 secondes :-)
mais cest pas encore perfait(perfekt) ....
-- CostalMartignier

hmm, pas de reactions, alors ca vous plait pas ? ou vous voule le voir "in action", alors prene opera (4 me the best browser) et clique ici :-)
-- CostalMartignier

changements du site depuis la dernière visite

je pense a une fonctionalite, qui mes les voir plus vites quesque cest change, depuis ma dernier visitation.-
par le moment cest commeca, quand je viens sur WikiNi le premiez que je fais cest visite les DerniersChangements, et la je doit encore cavoir quesque jai deja vu et quoi pas, apres le prochaine probs cest quand je viens sur une site, par example SuggestionsFonctionnalites, je dois encore chercher que cest change depuis le dernier fois. a quois je pense cest une button a la site ParametresUtilisateur qui me laisse choisir, si je veux deja voir sur la site, queceque cest change depuis mon dernier visitation, si vous voulez dans la couleur verte :-)
-- CostalMartignier (j'aimerais bien que vous me comprendre avec mon charonne de francais)

Costal, j'avais la même idée de fonction en tête et je pense la réaliser très bientôt. J'admire t'es efforts en français, ça ne doit pas être évident.
-- PatrickPaul

Je crois qu'on a peut-être tous pensé à ça ces derniers temps : le site de WikiNi change très souvent en ce moment et c'est fastidieux d'avoir à toujours utiliser les diff.
Il faut qu'on soit bien d'accord sur ce que nous voulons. Voici les cas d'utilisation (use cases) que je propose. (Ces cas supposent que l'utilisateur s'est identifié (à discuter ?))
Proposition 1
Proposition 2
Je pense qu'il faut retravailler un peu ce cas pour tenir compte des cas limites : l'utilisateur qui vient une fois tous les mois (les pages risquent de devenir illisibles) ; l'utilisateur qui ne s'identifie pas (mais qui pourrait néanmoins jouir d'un cookie) ; etc. (je pense qu'il y a d'autres cas limites).

CostalMartignier, nous te comprenons bien. Tu peux écrire en anglais si le français t'est trop difficile.
-- CharlesNepote

uiuiuiuiii j'ais compris la moitche , mais je fais une traduction babelfish, et apres ca vas aler ;-)
Charles, merci, mais je crois ca vas mieux avec le francais, la jecris comment je parle (et parle je sais bien) mais l'anglais je sais seulement lire, et ca bien (?) -- CostalMartignier
ok, babelfish ma donner un peut aide :-)

J'ai déjà réfléchis à la mise en oeuvre de cette nouvelle fonction. J'essayerai de détailler son fonctionnement bientôt. Je m'y mettrait dès que j'aurais terminé toutes les fonctions qui sont EnCoursDeDeveloppement.
-- PatrickPaul

Personnellement je verrais plus les choses ainsi :
- l'utilisateur demande au système la liste des documents (pages/commentaires/fichiers) modifiés depuis sa dernière demande
- le système lui affiche une liste et propose un bouton [Valider] qui va enregistrer la date à laquelle l'utilisateur a validé cette liste
- la date de validation est utilisée comme date de départ pour rechercher les documents modifiés depuis, et est stoquée dans les paramètres de l'utilisateur (qui pourrait éventuellement la réinitialiser)
De cette manière, ce ne devrait être trop difficile à implémenter et ça devrait permettre à quiconque de suivre les modifications à son rythme et sans craindre les coupure réseau (qui causerait problème en cas de mise à jour automatique de la date de validation).
-- ProgFou

Page listant toutes les pages appartenant à XXX


Cette page liste toutes les pages dont le propriétaire est XXX. Une page est créée pour chaque utilisateur.
Par exemple Pages De Charles Nepote (tout attaché).
Cette page permet en outre, et c'est là tout son intérêt, de choisir une ou plusieurs pages et de les réaffecter à quelqu'un d'autre.
L'intérêt, plutôt effectif dans un intranet, c'est de pouvoir réaffecter les pages de quelqu'un lorsqu'il part (ou change de responsabilité) et qu'il est remplacé par quelqu'un d'autre dont la responsabilité est de gérer ces pages.
-- CharlesNepote

La première etape, à mon avis, est d'avoir une fonction listant toutes les pages d'un site WikiNi. Un "refinement" , à la Rebol, permettant ensuite d'avoir cette page par utilisateurs, voire de gerer les reaffectations. -- DavidDelon

Le plan du site est fait (liste simple), la suite est dans les tuyaux.
Je propose de rajouter la fonctionnalité PlanDuSite dans le setup et/ou dans le bandeau. Qu'en pensez vous ?
-- DavidDelon

Je pense que l'administrateur fonctionnel (celui qui fait l'installation guidée) devrait pouvoir choisir s'il veut ou non de cette option dans le bandeau haut.
-- CharlesNepote

Oui, mais il faut qu'au moment de l'installation, il sache qu'elle existe ... --DavidDelon

En attendant de le normaliser dans un {{PlanDuSite owner="DavidDelon"}}, on pourrait en faire une simple action {{listpages owner="DavidDelon"}}, non ? Juste pour l'affichage de l'information ... Car les fonctionalités suivantes (actions en masse sur une liste de pages) risque d'être un peu plus longues à développer ... ;-)
-- ProgFou

Une application de Wiki


Avant même de connaitre Wiki, je créais des sites internet. Pour un de ces sites, je souhaitais crééer une interface qui permettrai à une équipe de webmatsters d'éditer certaines pages (selon les rubriques dont ils étaient en charge).
Bref, losque j'ai découvert Wiki la première chose à laquelle j'ai pensé est cette application pour une équipe de webmasters. Je sais que l'on s'éloigne un peu du principe de Wiki mais je serais très interressé à développer Wakka en partie dans ce sens là.

En fait je voudrais suggérer de développer Wakka dans plusieurs "sens" : de l'utilisation toute simple à une utilisation avancée voir même très avancée. On pourrait par exemple permettre l'utilisation sous diverses formes. J'atttends vos idées.
-- PatrickPaul

Pourquoi pas, mais attention à ne pas faire de WikiNi, un machin trop compliqué et trop lourd, comme l'est devenu phpwiki entre la version 1.2 et la version 1.3, une utilisation judicieuse des "handlers" et des "actions" devrait pallier ce problème. (Oui tout à fait -- PatrickPaul)

-- DavidDelon

Option "remonter le temps"


Je sais pas si c'est très clair mais j'ai eu une idée simple de créer une option qui permettrait de naviguer sur un site WikiNi comme si on était à une date antérieure... Je pense que c'est assez facile à faire.
-- PatrickPaul

Je pense aussi que c'est assez facile à mettre en place techniquement :
 Seulement je me pose une question de fond : quid des pages qui auraient existées avant la date spécifiée, mais dont les anciennes révisions seraient déjà purgées ? Actuellement nous n'avons aucun moyen de le savoir car nous n'enregistrons pas la date de création de la page (date de la première version) séparément.
On pourrait effectivement stoquer cette information (une colonne createtime dans wikini_pages) et indiquer alors à l'utilisateur qui tente d'accéder à l'une de ces pages que les anciennes versions sont déjà purgées. On peut aussi éventuellement lui proposer d'accéder à la version la plus ancienne en archive, mais ça risque de ne pas répondre à la réalité de la date choisie.
De plus, quid des liens entre pages ? La table wikini_links contient les liens concernant toujours la dernière révision de chaque page ; cette table ne serait donc plus utilisable en l'état (en particulier pour la plupart des actions) ! On pourrait éventuellement revoir le moteur pour en tenir compte et recalculer dynamiquement ces infos dans le cas de cette remontée du temps, mais ça demandera pas mal de boulo...
Bref : pas si trivial que ça finalement !
-- ProgFou

Effectivement il y a pas mal de considérations pour effectuer ce genre de "pirouette". Je me demande d'ailleurs si ce n'est pas en partie la raison pour laquelle elle n'a pas aboutit... De plus à l'époque ou je l'avais proposée (cad dans les débuts de Wikini) la situation était assez différente de ce qu'elle est devenue maintenant. Nous avons actuellement plus de recul et plus de maturité dans nos idées concernant Wikini et ce que chaque modification peut impliquer.
-- PatrickPaul

Permettre la syndication avec un autre site


Grace à cela nous pourrions imaginer faire migrer automatiquement les modifications effectuées grace à wakka dans de l'html classique voir dans des systèmes plus complets tels que spip voire GSite
-- FuRax37 qui a des idées mais peu de compétences en programmation...

Recherche portant sur des parties de MotsWikis?


La recherche du terme "chan_gelog" (en retirant le "_") ne donne aucun résultat actuellement.
Il faut rechercher WikiNiChangeLog pour trouver quelque chose. Je pense que c'est un défaut.
-- CharlesNepote

En effet, mais cela est dû à MySQL lorsque l'on fait une recherche "FULLTEXT" car la recherche se fait sur l'indexation des mots de chaque page. Il est possible de faire une recherche plus juste au pris d'une perte de performance en utilisant la requête SQL suivante dans la méthode wiki::FullTextSearch?($phrase) :
<?php
   function FullTextSearch($phrase) {
      $sql = "select * from ".$this->config["table_prefix"]."pages ".
             "where latest = 'Y' ".
             "and (".
             "     ucase(tag) like ucase('%".mysql_escape_string($phrase)."%') ".
             "     or ucase(body) like ucase('%".mysql_escape_string($phrase)."%') ".
             ")";
      return $this->LoadAll($sql);
   }
?>

Avec ce code, l'indexation FULLTEXT n'a plus d'interêt.
A noter que à partir de MySQL 4.0.1, il existe la possibilité d'utiliser une recherche avec des options booleen ( Recherche FULLTEXT de MySQL ) :
Par exemple une recherche de "apples*" permet de trouver "apples", "applesauce'' et "applet".
--GarfieldFr

Enregistrer dans la base SQL les informations non techniques du fichier de configuration


Certaines informations du fichier de configuration (voir plus bas) ne sont accessibles qu'à l'administrateur technique alors qu'elles ressortent plutôt de l'administration fonctionnelle. Je propose donc de migrer ces informations directement dans la base de données.
 Pour l'interface, on peut envisager (à approfondir) une actions du type {{config data="XXX"}} ou {{config}} qui permette de consulter/modifier chaque donnée de configuration.

Informations de configuration techniques :
Informations de configuration fonctionnelles :
 -- CharlesNepote

D'accord sur le principe, par contre nous n'avons pas défini de scénario de création d'administrateur fonctionnel. Un moyen simple serait de le faire créer à l'installation par l'administrateur technique, ensuite l'administrateur fonctionnel pourrait accorder des droits administrateurs fonctionnel à d'autres administrateurs.
-- DavidDelon

Pour la création de l'administrateur fonctionnel, je vois deux solutions :
 En ce qui concerne l'enregistrement des données dans la base SQL, voir la BaseDeDonneesEvolutive.
-- CharlesNepote

Gestion des repertoires

Gestion des repertoires pour les pages, chaque repertoire/page pouvant donc être assignée à un repertoire

avantages
inconvénients
[EDIT]





-- GeoffreyBachelet

J'ai codé un système de catégories pour Wikini.
Pour l'instant je n'ai pas de gestion de sous-catégories, mais ca doit se faire sans trop de souci.
L'ajout/modification/suppression de catégories se fait via une page Wiki. Tout le monde peut donc modifier cette liste.
Chaque page peut-etre rattachée à une ou plusieurs catégories (checkbox lors de la validation). Celles-ci ne sont pas figées, on peut les modifier à chaque édition de la page.
Au niveau de la DB, cela se traduit par l'ajout de 2 tables supplémentaires, les tables "noyau" ne sont donc pas affectées.
J'essaye de mettre en ligne dans la soirée ce que ca donne.
Si vous pensez que ce genre de choses peut s'intégrer directement dans Wikini (y'a pas mal de modifs pour en faire un plug-in, mais si vous pensez que ca doit plutot se faire de cette façon je peux tenter), je ferai ca avec plaisir.

-- AlexandrePassant


Bon je met ça ici vu que je sais pas trop où poster cette contribution.

Toujours sur mon PlanDuSite, je trouve la fonction par défaut vraiment trop basique à mon goût car elle va faire apparaître des pages en doubles si on veut un arbre plus grand, mais il est vrai que c'est très dur de réaliser une fonction qui va réagir comme on le souhaite vraiment, surtout sur un site de grande envergure. J'ai réalisé des fonctions qui vont générer un arbre des pages par niveau sans doublons et (en cas de doublons) conserver les pages les plus proches de la racine. Voici le code :
-- J o N

<?php

function getLinksFromPage($node, &$node_array)
{
    global $wiki;

    $node_to_build = array();

    $head=split(" :: ",$wiki->GetConfigValue("navigation_links"));
    $pages = $wiki->LoadAll("select to_tag from ".$wiki->config["table_prefix"]."links where from_tag='".mysql_escape_string($node)."' order by to_tag asc");
    if (is_array($pages))
    {
        foreach ($pages as $page)
        {
            // we don't want page from the header
            if (!in_array($page["to_tag"], $head, TRUE))
            {
                if ( !($wiki->GetConfigValue("root_page")==$page["to_tag"])  )
                {
                    // Ignore users too ...
                    if (!$wiki->LoadUser($page["to_tag"]))
                    {
                        //page already used
                        if( !in_array($page["to_tag"], $node_array) )
                        {
                            $node_array[] = $page["to_tag"];
                            $node_to_build[$page["to_tag"]] = TRUE;
                        }
                    }
                }
            }
        }
    }
    if( count($node_to_build) > 0)
    {
        return $node_to_build;
    }
    else
    {
        return FALSE;
    }
}

function setPageArrayFromLevel($root_array, $lvl, &$all_nodes)
{
    reset($root_array);
    if($root_array == FALSE) return;
    if($lvl == 0)
    {
        $array = array();
        while( list($key, $val) = each($root_array) )
        {
            $array[$key] = getLinksFromPage($key, $all_nodes);
        }
        if(count($array)>0)
        {
            return $array;
        }
        else
        {
            return FALSE;
        }
    }
    while( list($key, $val) = each($root_array) )
    {
        if( is_array($val) )
        {
            $root_array[$key] = setPageArrayFromLevel($val, $lvl-1, $all_nodes);
        }
    }
    return $root_array;
}

function displayTree($tree, $level=0)
{
    global $wiki;
    while( list($key, $val) = each($tree) )
    {
        print((str_repeat("&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;",$level)).$wiki->Link($key)."<br/>\n");
        if( is_array($val) )
        {
            displayTree($val, $level+1);
        }
    }
}

function TreeView2($start_page, $count)
{
    $all_nodes = array();
    $array[$start_page] = TRUE;

    for( $i=0 ; $i < $count ; $i++)
    {
        $array = setPageArrayFromLevel($array, $i, $all_nodes);
    }
    displayTree($array);
}
?>


Table des matières (Toc)


Concevoir une action permettant de générer automatiquement la table des matières d'une page, ou plus simplement reprendre l'action Toc de WackoWiki:HomePage (interwiki).
-- DavidDelon

Une proposition la-dedans : TableDesMatieres
-- DavidDecotigny

Actions d'information sur l'utilisateur et le système


Deux actions qui pourrait être bien utile pour rendre WikiNi facilement modifiable au niveau de la présentation:
Ces deux actions vont dans le même sens : la possibilite de générer le menu grace à une page et a l'action {{include}}. Il serait alors possible d'avoir dans la page "MenuDuHaut" (cf: ActionInclude ) un texte du genre :

{{wikinivar var="root_page"}} :: DerniersChangements :: DerniersCommentaires :: ReglesDeFormatage :: ParametresUtilisateur :: Vous êtes {{userinfo info="name"}} ( {{userinfo info="logout"}})

Une tel page donnerait exactement le menu standard de WikiNi qui deviendrait completement modifable !

-- GarfieldFr

Très bonne idée !! -- ProgFou

Il y a pas mal de discussion autour de ces problèmes : cf. MacroWikini. Je pense que le sujet n'est pas encore tout à fait mûr. Peut-être y apporterais-tu quelques idées nouvelles. -- CharlesNepote

Gestion des bugs

Il est clair que la gestion des bug utilisé sur ce site n'est pas terrible, alors je me suis mis au travail pour voir comment on pourrait faire une gestion des bugs plus correct. J'ai pas mal avancé et ca marche à peu près. En terme de fonctionnalitées, voila ce qu'il y a/aura:
 Voila c'est tout pour l'instant.
Ce gestionnaire de bug se presente sous la forme d'une action qui n'a pas de paramètres (pour l'intant). J'ai commencé ce travail pour voir ce qu'il était possible de faire avec une action et visiblement on peut faire beaucoup de chose. Si cette action vous semble utile, je vous la communiquerais dés que je l'aurais fini. Voila typiquement une action à ne pas mettre dans le paquet de base de WikiNi mais plutôt dans un paquet séparé.
--GarfieldFr

Oui, on peut certainement aller très loin avec les actions et ça fait pas mal de temps que j'y pense. C'est la raison pour laquelle j'ai expliqué la notion de base de données évolutive, base d'un WikiniSemantique. Mes cogitations ce sont transformées concrètement dans le prototype suivant que tu peux maniupler à ta guise : http://wikisem.wikini.net/
On peut parfaitement envisager la réalisation de la gestion des bogues sur la base de ce prototype.
-- CharlesNepote

En effet, le principe des métadonnées est très interressant, mais au prix d'une réécriture totale de WikiNi (sauf les formatters). Pour ma part, le gestionnaire de bug est très basic, il utilise sa propre table, et je pense utiliser une page WikiNi pour garder la description de chaque bug, ce qui me permet, à moindre frais, d'avoir la gestion de version dans la description d'un bug.
--GarfieldFr

Non, non : il n'est pas du tout question d'une "réécriture totale de WikiNi' !... La gestion des métadonnées comme proposée dans mon prototype est complètement fondée sur WikiNi et ajoute à peine : quelques dizaines de lignes de code dans wakka.php (fonctions de gestion des triplets RDF), quelques dizaines de lignes dans /handlers/show.php et une petite table dans la base. Pour le reste : rien ne change. (Et encore je pense qu'il est possible d'intégrer ces fonctions de gestions des métadonnées de façon modulaire, par exemple en passant par des fichiers externes sans presque rien toucher de WikiNi. Ce que je propose est encore néanmoins largement à l'état de prototype...). L'avantage c'est que je suis capable de gérer des besoins très larges : c'est un système très extensible. -- CharlesNepote

Donc, le système de métadonnées ne concernerat que les extensions. Une page de WikiNi ne sera pas définie et stocker grace à une description via les métadonnées ? Je trouve ca un peu dommage, mais il est vrai que cela donnerait beaucoup de travail.

En attendant, j'ai fini mon gestionnaire de bug. Il est en démo sur mon site de test : http://codedb.delphicenter.com/wiki/wakka.php?wiki=BugReport
Il y a encore des choses à modifer/ajouter, mais l'essentiel est présent. Si il vous semble utile pour la gestion des bugs de WikiNi, cette action est très simple à installer.
--GarfieldFr

Pour ma part je pense qu'une fois le système des métadonnées bien mis au point, il vaut mieux faire un outil de migration de base afin de convertir tout le WikiNi selon ce concept (vraiment génial d'ailleurs) ! D'autant plus maintenant que vous avez introduit la notion de révision wikini ! ;-)
-- ProgFou

Insertion d'une action au sein du code d'une action


Il serait souhaitable que les valeurs des paramètres passés à une action soit évalués par le formateur avant d'être passé à l'action. L'interêt d'une telle chose réside dans la configuration dynamique des actions. Je pense en particulier à l'utilisation des MacroWikiNi dans une action(Voir ma reflexion dans CollaborationsMultilingues ). Cela permettrait d'avoir le genre de code suivant par exemple : "navigation_links" => "{{include page=\"Menu{{var name="langue"}}\"}}", qui utilise une page localisé comme menu en fonction du langage choisi par l'utilisateur. Je suis sur que l'on peut trouver d'autres utilisations. A priori, l'évaluation de la valeur du paramètre peut être fait soit dans l'action elle même, ce qui implique que les actions ne faisant pas l'évaluation ne pourront pas être utilisées comme cela, soit avant d'exécuter l'action, ce qui implique une modification de wakka.php (mineur je pense). La seconde solution me semble la plus judicieuse pour des raisons d'homogénéïté du fonctionnement des actions.
--GarfieldFr

Faciliter les traductions de contenu

J'ai vu la page WakkaLocalization (et l'exemple opérationnel) qui ne concerne que l'interface et je souhaiterais le même genre de comportement pour le contenu... je n'ai pas réussi à trouver d'équivalent (qui existe peut-être ?)

Le besoin pour faciliter les traductions de contenu serait d'avoir des liens "transversaux" automatiques d'un même document dans des langues différentes.
Cela permet à une équipe internationale de travailler sur un ensemble de documents et de les garder en cohérence, en permettant aux traducteurs de passer rapidement d'une page à l'autre.
Il reste possible de le faire "à la main" mais cela est particulièrement pénible (ajouts de liens systématique en haut de chaque document)

Cela nécessite les points suivants :
- Gérer un profil utilisateur de langue (au moins) qui sera utilisée pour l'affichage par défaut et la liste des langues disponibles
- Les contributeurs devront créer les documents en conséquence avec une extension. Par exemple DocumentSpecification_FR DocumentSpecification_EN DocumentSpecification_SP respectivement pour Français, Anglais, Espagnol
- en visualisation, affichage du document dans la langue choisie par l'utilisateur et - si le doc n'existe pas - dans la langue où il existe (+ navigation proposée automatiquement pour passer de l'un à l'autre : affiche classiquement un point d'interrogation pour créer la page)
 - Le choix du nommage du préfixe (et sa compréhension d'une langue à l'autre...) est à la charge des gestionnaires de contenu, le suffixe _LANG permet d'identifier des pages dans des langues différentes
- évolutions ultérieures : identifier le document de "référence" (le plus à jour), ça pourrait passer par l'ajout de la date de dernière modification à côté du lien (pour identifier ce qui est plus à jour que le document en cours)
C'est une suggestion, si vous avez d'autres idées ou un existant, je suis preneur (et testeur !) à défaut d'être développeur...
BenoitAudouard 20031202 j'ai creusé des suggestions sur ma page

Quand une page est supprimée, elle reste visible à l'écran. Ceci peut surprendre l'utilisateur. Serait-il possible d'être automatiquement renvoyé sur la page principale ? Merci -- FidelioEspoir

Oui tu as raison ce serait mieux. Il y a deux possibilités :
 -- CharlesNepote

RechercheTexte
Par erreur j'avais détruit la page RechercheTexte. Aussi la recherche d'une page existante prétendait-elle qu'elle n'était pas créée ! Comment prévenir cela ? -- FidelioEspoir

Si l'objectif est simplement d'empêcher l'effacement de la page RechercheTexte, il suffit d'en changer les permissions je pense. En principe seul le propriétaire peut effacer la page, et ce uniquement si elle est orpheline. Il suffirait donc d'en donner la propriété à WikiNiInstaller (ce qui est sensé être le cas juste après une installation), en éventuellement de faire un ou plusieurs liens vers cette page depuis une autre page. Est-ce que ça répond à ta question ? -- ProgFou

Oui, c'est ça, empêcher un wikiniste noviste de faire l'erreur. Il y aurait en quelque sorte des cartes, euh! des pages, dont le propriétaire serait ...WikiNi. -- FidelioEspoir

Je te suggère de vérifier car en principe c'est déjà le cas si tu as installé la version 0.4.1rc ! Les pages mises en place par la procédure d'installation appartiennent à WikiNiInstaller. Malheureusement, vu que WikiNiInstaller n'est pas un utilisateur réel, je suppose que WikiNi doit proposer à n'importe qui de s'approprier la page ? Dans ce cas il faudrait également créer un utilisateur WikiNiInstaller au moment de l'installation, avec un mot de passe invalide pour bloquer ce compte. -- ProgFou
Oui. c'est cela. Je ne sais pas si le WikiNiInstaller actuel pourrait être un "utilisateur" patenté. Mais il en est un pratiquement pour l'utilisateur non informaticien. L'utilisation est toujours un dialogue entre l'utilisateur-moi et un "autre" (objet,soft,utilisateur,développeur...) -- FidelioEspoir

Je viens d'installer les styles variables : superbe ! Aussitôt j'ai envie de voir changer le style à chaque type de page...J'ai donc "besoin" d'une action (aujourd'hui changestyle, mais demain une autre, du genre questionAposer...musique..ouverture d'une fenêtre...) qui s'exécuterait à l'ouverture d'une page....en tenant compte ou non d'un paramètre inscrit dans la page...Bon, d'accord, le vieil hypercardophile est nostalgique : j'ai l'âge de mon premier Mac SE ! ( + quelques années d'ignorance précédentes...). -- FidelioEspoir

Il me semble que cela rejoint les MacroWikiNi, dans la possibilité de mettre du contenu dynamique dans les en-tête et pied de page. Le changement de style à chaque page pourrait alors être mis en place au travers d'une de ces macros. -- ProgFou

Suite à des problèmes de pages effacées sur le FriWikiWiki, voici quelques petites suggestions :
  1. serait-il possible de configurer le nombre de sauvegardes d'une page pouvant être conservées dans la DB ? personnellement, je l'ai implémenté en ajoutant l'option "versions_to_keep" (avec la valeur par défaut "2" dans wakka.php et une valeur pouvant être personnalisée dans wakka.config.php) et en modifiant une ligne de la fonction PurgePages() : remplacer group by tag having count(*) > 2 order by tag par group by tag having count(*) >" .$this->config["versions_to_keep"]. " order by tag (Wikini version 0.4.1rc).
    • C'est une idée intéressante. Pour ma part je la garde "sous le coude". Merci. -- ProgFou
  2. serait-il possible d'avoir une option permettant de limiter l'accès au Wiki aux utilisateurs enregistrés ? En effet, le FriWikiWiki a été victime d'une attaque de spammeur et d'un petit malin avec comme résultat la perte de 5 pages dont 3 de manière définitive (plus aucune sauvegarde correcte n'existait).
    • Il suffit d'éditer les permissions d'accès aux pages pour y remplacer * par +. On peut le faire massivement dans la base de données pour les pages déjà créées via une requête SQL du genre update wikini_acls set list='+' where privilege='write' and list='*'. Ne pas oublier de changer "default_write_acl" => "+" dans le fichier wakka.config.php. -- ProgFou
Voilà, merci d'avance -- ZeFredz

Merci beaucoup !! -- ZeFredz
Beaucoup d'info dans les wiki ne sont pas datées. Elles deviennent inutiles (sauf pour l'historien, archiviste) et surchargent les pages demandant plus temps de consultation. Malheureusement leurs auteurs se sont éloignés et ne songent plus à effacer leurs anciennes contributions. Pire encore, je pensais effacer mes questions après qu'ils aient reçues réponse. J'y ai renoncé pour que l'info qui m'était gentiment donnée reste accessible à tous. Comment faire ? Dater systématiquement ? Quelle stratégie intelligente (= utile à tous) adopter ? devant l'accumulation ? y répondre par une meilleure hiérarchisation ? mais comment ? laisser à d'autres le "subtil coup de pied dans la fourmilière" ? le wiki deviendra-t-il un noeud gordien ? -- FidelioEspoir.....7av04-12h42 !? ;-o)

Oui, il est évident qu'un wiki peu devenir très vite complètement illisible à cause du désordre. La règle voudrait que :
 Je pense qu'il faut éviter d'ajouter des commentaires en bas de la page mais plutôt juste après l'endroit à commenter et en signant. Dans le cas d'une page de bug par exemple, il est nécessaire de dater le bug.

Une hiérarchisation des pages serait peut être en effet un plus pour organiser les page par thèmes, mais cela n'empêcherait pas le désordre à l'interieur d'un thème.
Une évolution possible : GestionDeGroupeDePages
--GarfieldFr
Peut-ête serait-il bien de prendre l'habitude de changer le style du texte italique/plain pour indiquer qu'il s'agit d'un dialogue


A titre d'information, voici la technique que j'utilise personnellement pour suivre le Wiki sans avoir de souci de lecture :
 -- ProgFou

une Backlinks commentée Le lien commenté

La réflexion est bonne conseillère : j'ai mis un backinks sur ma page comme ça je m'y repère Ca me donne une idée d'un "backlinks commenté" :
Exemple :
Actuellement : ceci est un SujetUrgent? >> La page SujetUrgent? contenant un backlinks m'indiquera dans la liste : SuggestionsFonctionnalites
Proposition : ceci est un SujetUrgent?(FidelioEspoir le pense parce que c'est important) >> La page SujetUrgent? contenant un backlinks m'indiquera dans la liste : SuggestionsFonctionnalites (FidelioEspoir le pense parce que c'est important)
On devrait généraliser cette suggestions :
Un wikini, c'est un ensemble de liens, l'utilisateur créant le lien se contente de le créer en laissant à sa page le soin d'en définir une sémantique possible. Inventons le lien commenté : CeciestleLien? (ceci est le commentaire de ce lien écrit ici). Lorsqu'une action style backlinks repère le lien, elle le signale AVEC son commentaire (ceci peut être une option 1/0)
Ceci permet de différencier le lien et le lieu où il est inscrit....
-- FidelioEspoir

Liste des utilisateurs connectés

(JH) Ne pourrait on pas avoir une action listant les utilisateur actuellement connectés (et ce qu'ils font ?) ?

Pouvez-vous préciser "et ce qu'ils fonts" ? Il n'est pas possible de développer une telle action sans modifier le noyau de WikiNi -- ces développements ne seraient pas simple. Il faudrait encore juger de l'utilité d'une telle fonction. Quelles sont les cas où vous pensez qu'elle puisse avoir une utilité. -- CharlesNepote

Protection des inscriptions

Il est possible de restreindre l'édition des pages et des commentaires aux seuls inscrits, mais n'importe qui peut s'inscrire sans aucune vérification, ce qui diminue l'intérêt de cette inscription obligatoire.

Pour mon usage personnel, j'ai ajouté à actions/usersettings.php quelques lignes de code pour restreindre les inscriptions, qui nécessitent de fournir en plus des informations standard de WikiNi un code de souscription (propre au Wiki) pour pouvoir s'enregistrer comme nouvel utilisateur. On obtient ainsi à peu de frais un Wiki utilisable par un groupe de travail, en évitant toute pollution extérieure. Le code de souscription pourrait parfaitement être placé dans wakka.config.php, son absence laissant WikiNi dans son état ouvert classique. Si d'autres sont intéressés, je peux fournir le code ajouté.
-- GamDra

Faire le ménage dans les commentaires


Permettre de faire le ménage dans les commentaires d'une page, parce que - par exemple - on les a pris en compte dans la page elle même.
Je n'ai rien trouvé qui permette de supprimer les commentaires, une page CommentSupprimerCommentaires? serait bienvenue.

J'ai rencontré le même problème, un premier pas de solution consiste à permettre aux utilisateurs de retirer facilement leurs commentaires, avec un lien "EffacerCommentaire?" à côté de chaque commentaire, visible uniquement pour l'auteur. Il n'y a qu'un petit bout de code à ajouter dans handlers/show.php :
if ( $comment["user"] == $this->GetUserName() )
          echo '&nbsp;[&nbsp;<a href="' . $this->href("effacercommentaire", $comment["tag"]) . '">EffacerCommentaire</a>&nbsp;]';

... juste après la ligne 126 environ (en WiKiNi 0.4.1) qui contient
echo "<div class=\"commentinfo\">\n-- ",$this->Format($comment["user"])," (".$comment["time"],")";


Puis mettre un handler "effacercommentaire.php" qui est exactement comme le deletepage mais sans la vérification 
php
	if ($pages = $this->IsOrphanedPage($this->GetPageTag()))


-- SergiO?

MotWikiPedia?


Comme dans spip un racccourci du style
?Wikini qui emmenerais sur la page du wiki correspondant à la définition du mot :) dans http://wikipedia.org
cerise sur le gateau il pointerait vers la bonne langue du style fr.wikipedia.org pour un wiki français. ;)

Vous croyez que ce serait possible ?

Tant qu'à prendre le meilleur de tous les mondes, un raccourci
~~~ qui serait un alias pour login?
~~~~ qui serait un alias pour login? + date de création
-- JulienTayon?

ResultatDeRechercheAlphabetique?

Savez-vous comment faire pour que la page de recherche affiche les résultats par ordre alphabétique ?
Ce n'est pas indiqué ici : ActionTextSearch
AnDre
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2013-04-18 01:21:27 :: Propriétaire : CharlesNepote :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)