Ici vos suggestions sur l'interface utilisateur de
WikiNi.
Sommaire :
- Différencier visuellement les liens internes au Wiki des liens externes
- Affichage automatique des derniers changements de toute page visitée
- Gérer les commentaires dans la page
- Option de configuration permettant de ne pas utiliser les commentaires
- Option de configuration permettant de ne pas afficher "Valid XHTML" et "Valid CSS"
- Amélioration des possibilités de mise en page
- Liens non cliquables lors d'un aperçu
- Système de thème
- Configuration de l'affichage des dates
- Lien "connecter
- Interface administrateur
- Ajouter un bouton pour le fil RSS directement sur la page DerniersChangements pour permettre de suivre l'ensemble de l'évolution du Wiki.
- Faciliter l'inscription pour les nouveaux utilisateurs
- Personnalisation des messages d'erreur ou d'aide
Faisant l'objet d'une page propre :
Différencier visuellement les liens internes au Wiki des liens externes
Si ça ne coûte pas (ou quasi pas) de temps de traitement.
A l'image de
WikkiTikkiTavi ou
PhpWiki.
Attention : il faut alors créer un nouveau style dans Wakka.css.
--
CharlesNepote
Beaucoup de gros sites (CNN, TF1...) indique par un petit logo comme
i.a.cnn.net/cnn/.element/img/1.0/misc/icon.external.links.gif devant l'URL les pages externes à leur site et ces pages s'ouvrent dans un nouveau navigateur. Le seul souci est que les pages consistant en des listes d'URLs (comme celle sur
Mozilla) obtiennent ce logo en face de chaque URL, ce qui peut paraitre répétitif, mais reste très clair.
-- Gniarf
Je propose une solution immédiatement opérationnelle, uniquement en modifiant la feuille de style, avec les sélecteurs CSS3 sur la page
LienInterWiki. Le problème c'est que ça ne fonctionne pas sur
InternetExplorer. --
CharlesNepote
Affichage automatique des derniers changements de toute page visitée
Prévoir une option utilisateur qui permette l'affichage par défaut des modifications de chaque page consulté depuis la dernière visite.
Exemple : j'ouvre la page d'accueil, je consulte la page
VosSuggestion? et apparaît par défaut, au lieu de la page
VosSuggestion? normale, les modifications survenues sur la page
VosSuggestions depuis ma dernière consultation de cette page. C'est peut-être un peu difficile à coder mais quels confort d'utilisation !
--
CharlesNepote
Oui tout à fais d'accord ! J'avais exactement la même idée. --
PatrickPaul
Oui, j'avais pas bien compris la proposition ... à retenir.
--
DavidDelon
Facile (une simple table id utilisateur/id page/version de la page) mais peut vite prendre une place folle, à réserver aux personnes enregistrées.
-- Gniarf
Gérer les commentaires dans la page
La gestion des commentaires offre un grand intérêt pour les wikis qui gèrent les droits d'accès aux pages : elle permet aux utilisateurs de s'exprimer même si ils n'ont pas accès à la page. Deux solutions ont alors été proposé :
- Les commentaires sont gérés en dehors de la page
- Pour : les commentaires sont bien identifiés ; il n' y a pas de risque de mélange entre les commentaires et les contenus de la page ; les commentaires peuvent être manipulés (affichage ou non par défaut) ;
- Contre : il faut coder la gestion des commentaires (ajout, suppression, etc.) ; il faut gérer des champs supplémentaires dans la base de données.
- Les commentaires sont gérés dans la page
- Pour : peu de code supplémentaire pour les gérer ; pas de champs supplémentaires dans la base de données
- Contre : il faut marquer une différence visuelle entre les commentaires et le contenu ; les commentaires pourraient rapidemment polluer la page (discutable)
La deuxième solution nous paraît plus intéressante. Au moins faudrait-il peut-être songer à fusionner les données de
DerniersChangements et
DerniersCommentaires en une seule page.
--
EricSegui et
CharlesNepote
Option de configuration permettant de ne pas utiliser les commentaires
Ca ne devrait pas être très compliqué à mettre en oeuvre. Je veux bien m'en charger.
Coûte un peu de traitement ?
--
CharlesNepote
Si j'ai bien compris ce que tu veux, il suffit de passer default_comment_acl de wakka.config.php à "[rien]". Ca peut
s'intégrer dans un chantier plus général de configuration de l'ensemble des options pour un utilisateur avancé lors du setup.
--
DavidDelon
Option de configuration permettant de ne pas afficher "Valid XHTML" et "Valid CSS"
Ces liens "Valid XHTML" et "Valid CSS" ne fonctionnent pas dans un contexte intranet ; on peut proposer une option de configuration (dans wakka.config.php) qui permette :
- soit de ne rien afficher ;
- soit de remplacer les liens par un texte.
C'est très facile à mettre en oeuvre. Je veux bien m'en occuper.
Coûte un peu de traitement ?
--
CharlesNepote
Amélioration des possibilités de mise en page
Toujours autour du sujet de la mise en page via les CSS, je remarque, lors de mes nombreux essais actuels, que certains éléments fonctionnels sont "prisonniers" d'une boîte alors même qu'ils auraient vocation à être des boites autonomes pouvant faire l'objet de variations de mise en page.
J'ai repéré, pour le moment les éléments fonctionnels suivants :
- le lien vers la page d'accueil
- l'identité de l'utilisateur
- la recherche.
Mes premiers essais de modification de la feuille de style se heurtent à ses problèmes.
Vous pouvez aller voir, sur mon site, un de mes
premiers essai de modification en profondeur de la feuille de style (un conseil : tester avec
Mozilla le bas à sable et faites défiler...). Notez que je n'ai touché qu'à la feuille de style, pas à une seule ligne de code HTML.
--
CharlesNepote
Wow ça donne super bien ! J'ai hate de voir tes modifications appliquées au projet. --
PatrickPaul
Oui franchement sous Mozilla c'est fantastique! Mais c'est dommage que rien ne fonctionne sous
InternetExplorer...
--
JeanPascalMilcent
Liens non cliquables lors d'un aperçu
- Lorsqu'on clique sur le bouton "Aperçu", les liens dans la page sont cliquables. Si on clique sur l'un d'eux, on change de page. Si on avait des modifications en édition, tout est perdu. Il faudrait pouvoir éviter cela.
- Deux solutions :
- un message dans une fenêtre Javascript pour prévenir des risques
- des liens dans la page d'aperçu qui ne sont pas cliquables.
--
JeanPascalMilcent
Ça m'est arrivé aussi au début de faire cela. Depuis je ne fais plus cette erreur. Je suis prêt à suivre ta proposition en fonction de ce que veulent les autres.
--
PatrickPaul
C'est sans doute arrivé à pas mal de monde... (j'en fait évidemment partie). Et je suis totalement d'accord pour essayer de changer ça.
Je pense qu'il faut envisager cependant d'autres solutions :
- pour une solution qui concilie les deux comportements, c'est de faire ouvrir les liens de l'aperçu sur une nouvelle page (avec en HTML un target="_blank") : on conserve les liens et on ne perd pas la page d'aperçu
- le mot "Aperçu" est bien timide en haut de page et l'utilisateur n'a pas en effet une attention suffisante face aux risques de perdre des infos (celui qu'évoque JeanPascalMilcent n'est pas le seul) : je propose de changer l'aspect de ce mot (avec une couleur et une taille plus soutenues) ainsi que de changer la couleur du cadre environnant, permettant immédiatement de repérer que l'on est en mode "Aperçu". Ceci dit, les utilisateurs de terminaux braille ou vocaux ou de navigateurs en mode texte ne verront pas la différence ; aussi je propose pour eux d'ajouter des balises qui leurs sont adaptés (par exemple <strong>ATTENTION ! Vous êtes en mode Aperçu</strong> qui sera, pour les autres utilisateurs, caché par un "Hidden" dans la feuille de style). Je ne suis pas pour la solution JavaScript qui alourdi la page sans assurance de fonctionner.
- il faut qu'on regarde également le comportement des navigateurs lorsque, voyant que l'on s'est trompé, on fait un retour en arrière (on devrait pouvoir conserver les données de l'aperçu...).
--
CharlesNepote
Après avoir regardé le code, j'ai constaté que la classe de style CSS utilisée pour le mot "Aperçu" (.commentinfo) est celle qui est utilisée pour la signature et la date des commentaires.
Je pense qu'il n'est pas bon d'affecter une même classe de style à plusieurs contenus de natures différentes. Aussi je propose de créer une nouvelle classe de style pour l'alerte de l'aperçu : .prev_alert. Cette classe peut être ainsi définie :
.prev_alert { background-color:red; color: white; font-size: 1.7em; font-weight: bold; margin-bottom: 5px; }
Donnant un gros et gras "Aperçu" en blanc sur un fond rouge s'étalant sur la largeur de la page. Cette barre rouge attire le regard et incite à la vigilance. Ces valeurs peuvent évidemment être changées dans la feuille de style.
Il faut aussi modifier /handler/edit.php et changer la ligne suivante :
- $output .= "<div class=\"commentinfo\">Aperçu</div>\n";
en
- $output .= "<div class=\"prev_alert\"><strong>Aperçu</strong></div>\n";
(J'ai ajouté <strong></strong> pour les clients web ne supportant pas les CSS.)
Cette première modification corrige le problème que j'évoque et répond partiellement à la demande de
JeanPascalMilcent.
Sans réaction de votre part, je met en oeuvre cette modification mineure mardi 20 mai.
--
CharlesNepote
Pour ce qui est des liens en prévisualisation, je vote pour le compromis de
CharlesNepote (avec en HTML un
target="_blank") car il faut aussi pouvoir tester les liens en prévisualisation pour voir si on ne s'est pas trompé. --
JmPhilippe
Système de thème
Un peu plus haut dans cette page, on parle de la possibilite de choisir sa feuille de style, mais pourquoi se limiter au style ? On peu très bien choisir aussi une présentation complète. L'idée est la suivante : un utilisateur identifié peut choisir un thème (structure et couleur des pages) depuis sa page de paramètres utilisateur. Le fonctionnement devrais être assez simple, en effet, il suffit de tester dans header.php le nom du thème sélectionner et ensuite d'inclure le code correpondant au thème choisi. La même chose peut se faire pour footer.php. Un thème comprendra donc un fichier themeheader.php contenant le haut (au sens code) de la page HTML, une page themefooter.php contenant la fin de la page et éventuellement un ou plusieurs fichier annexe nécessaire (par exemple une feuille de style propre au thème). Il y a biensur des contraintes à l'écriture d'un thème comme par exemple le nom de certain élément des feuille de style. Je vais regarder la faisabilité d'une tel chose si j'ai le temp, mais à première vue, cela ne devrait pas poser de problèmes important.
Pour vous donner une idée du système de thème, vous pouvez aller sur
http://www.multiweb.be/GarfieldFr/wikini/ ou
http://codedb.delphicenter.com/wiki/ (site de test
WikiNi). En vous identifiant, vous pouvez choisir un thème à utiliser. Pour l'intant, les thèmes présent sont simplement des modifications des couleurs, mais il est tout à fait possible de modifier complètement la mise en forme d'une page (écran).
--
GarfieldFr
Mmh, le problème c'est que ca ajoute un champ a la base de donnée. N'est il pas possible de faire pareil avec un simple liste déroulante pour tout le monde, et stocker la préférence de chacun dans un cookie ? C'est exactement ce qui est fait dans
FeuillesDeStyleMultiples
La gestion des themes m'interesse, j'ai quelques css sous le coude avec tous mes tests :)
Pour uen action pourquoi pas, mais je vois plutot ca comme une liste déroulante mise dans le header, ca m'etonnerais que les utilisateurs créent des css, ils ont deja parfois du mal a comprendre le fonctionnement de wikini (et sans parler du "vandalisme"). dès que j'ai un moment, je me penche la dessus...
--
DaOuar
Configuration de l'affichage des dates
Il serait interressant de fournir un paramètre de configuration permettant de définir le format des dates affichées. Pour un français, je trouve qu'une date "2003-10-15 15:14:32" n'est pas très parlante, je préfèrerais "15 octobre 2003 15h14" par exemple. Les fichiers impacté serait wakka.php en ajoutant une fonction de formatage des dates, wakka.config.php pour le paramètre et action/footer.php pour l'affcihage de la date de modification.
--
GarfieldFr
Voici ma proposition:
AffichageDeDatePersonnalise
--
OlivierPoncin
Lien "connecter"
j'ai fait un petit changement trivial pour l'identification, pour avoir un lien "connecter" quand on est pas identifié, comme il y'a un lien déconnecté quand on est identifié.
ParametresUtilisateur n'a alors plus lieu d'être, ca permet d'ajouter autre chose...
Pour le code, c'est sur ma page wikini :
DaOuar
Pour voir le résultat :
http://rezal404.org/wikini/wakka.php?wiki=PagePrincipale
Format des dates de modification
Je me demande si le format "2004-03-05" est bien du français?
--
NguyenDaiQuy
L'usage français indiquerait en effet 05/03/2004 mais l'usage inverse est quelquefois employé notamment lorsqu'il s'agit de lister des dates (meilleure lisibilité).
Les anglo-saxons, qui utilisent souvent mois/jour/année, semblent venir également progressivement à cette notation. La raison en est notamment, qu'un tri alphabétique d'une série de dates "année/mois/jour" donne aussi leur tri chronologique ce qui facilite beaucoup les choses. --
CharlesNepote
Désolé mais cette explication ne me donne pas de satisfaction :-) Ici, on parle de l'interface, de la présentation des pages aux lecteurs dans sa propre langue et non du tri "informatique" :-) --
NguyenDaiQuy
- L'affichage AAAA-MM-JJ fait partie de la norme internationale ISO-8601:1988 (voir man date sous Linux ;-)). Cette norme permet entre autres d'éviter l'habituelle confusion anglo-saxons/reste-du-monde (au niveau de l'ordre JJ/MM/AAAA ou MM/JJ/AAAA). -- ProgFou
- Euh... J'ai oublié de préciser le plus important : je suis tout à fait d'accord sur le fait qu'il serait bien de permettre à l'utilisateur de choisir son format d'affichage de la date et même son fuseau horaire, et plus généralement ses paramètres de L10N (localisation, mais là c'est plus chaud niveau compatibilité avec les hébergeurs). -- ProgFou
Interface administrateur
Avoir une interface admin permettant à un administrateur de supprimer n'importe quelle page sans avoir à passer par le maniement de la base SQL, ainsi que d'overrider les autorisations afin de resoudre plus facilement les problemes. Pouvoir aussi supprimer des utilisateurs facilement et donner à chaque utilisateur le possibilité d'éditer/effacer ses commentaires. Pouvoir lister tous les commentaires d'un même auteur dans une page (c'est peut etre deja possible ca d'ailleurs mais je ne sais pas comment).
--
PapYrus
Cf. l'
InterfaceDAdministrationWikiNi. --
CharlesNepote
Interface développeur
Jugeant utile telle ou telle modification, j'ouvre un fichier, modifie le script et referme... Si je suis sur un serveur distant, je télécharge la modif.
Peut-on créer une page-formulaire (avec naturellement toutes les précautions d'accès!) où apparaîtrait le script à modifier avec un "Sauver" qui modifierait non la page mais le fichier du script lui-même ?...
Ma question est naïve...
--
FidelioEspoir
Oui, c'est possible. Mais c'est
très risqué. Si quelqu'un découvre un moyen de modifier le script wakka.php, par exemple, il peut, au choix : effacer la base, pourrir discrètement la base, introduire des vers, etc. En tout cas, ça ne sera pas une priorité de
WikiNi à court terme (sauf si un codeur fait des propositions "béton").
J'ai lancé le débat il y a déjà quelques temps sur
CraoWiki :
http://wiki.crao.net/index.php/ToutLeMondePeutD%E9velopper. Au total, j'ai proposé quatre distinctions :
--
CharlesNepote
Suppression des commentaires
Que c'est difficile de supprimer un commentaire ! --
FidelioEspoir
Paramétrage du mode d'affichage par défaut des commentaires
Pour les visiteurs non identifiés, les commentaires sont cachés. Il faut cliquer sur "Afficher commentaires/formulaire" pour les voir. Il serait bien que l'administrateur puisse choisir d'inverser cette situation : ainsi, pour les visiteurs non identifiés, les commentaires seraient affichés, et il faudrait cliquer sur "Cacher commentaires/formulaire" pour les cacher. Il serait bien que l'administrateur puisse décider de ce choix (pour les visiteurs non identifiés, par défaut, cacher ou afficher les commentaires ?). Cette décision se ferait via une case à cocher dans une interface administrateur (s'il y en a une), ou via un fichier de config. Ce choix ne concernerait que les visiteurs non identifiés.
Nicolas Barbulesco
nbarbulesco@yahoo.no-spam.fr
Lien avec Ancre pour les commentaires
Actuellement quand on clique sur "Afficher commentaires" on se retrouve en haut de la page, si la page est longue on doit scroller jusqu'en bas pour apercevoir les commentaires. Est-il possible de mettre une ancre #comments soit dans le lien "Afficher commentaires" soit en haut de la page pour atteindre directement les commentaires ? -- Jarod
Intégration de Spaw Editor dans Wikini
Pour des besoins professionnels j'ai du réfléchir à l'intégration de
Spaw Editeur dans Wikini. Cet Editeur fonctionne uniquement avec IE 5.5 ou >. J'ai rajouté une variable de configuration définissant si Spaw Editeur est utilisé ou pas. Je test aussi la version du navigateur et n'active pas Spaw si ce dernier n'est pas compatible. Les pages peuvent être éditées indifférement avec l'éditeur Wikini ou Spaw Editor. Tout n'est pas parfait mais c'est un début. Si certain sont interréssés je peux décrire la méthode que j'ai utilisée. Vous pouvez aussi voir ce que cela donne à cette adresse
http://www.planete-couleurs.com/wikini/wakka.php?wiki=BacASable --
GoubS
Pouvoir différencier les différentes parties d'une page en édition
Lorsque j'édite une page pour pouvoir y écrire, je me retrouve devant une page où les nombreux codes peuvent géner le repérage de la partie que je désire modifier. Serait-il possible de pouvoir insérer des caractères invisibles à la lecture et qui le permettraient (exemple : une barre fait de caractères identiques...) -- (rédiger page) 2004/05/20 - 09 : 52 --
FidelioEspoir
Ne serait-il pas possible de mettre les boutons "sauver Apercu Annulation" en bas ET en haut de page ? (Jeg)
Les adresses email
devraient être reconnues et intégrées comme liens (ex: mailto:jacques.chirac@elysee.org)
- Je pense que c'est un bug de Wikini car d'apres le code les adresses email devraient être traitées. J'ai proposé une correction a la page BugWikiGoubs --GoubS
Ce n'est pas un bogue mais c'était jusau'à présent non documenté :( Je viens de corriger dans
ReglesDeFormatage : il faut faire [[toto@example.org]] --
CharlesNepote
- Je sais que cela fonctionne avec des doubles crochet mais cela me semblait plus pratique de saisir simplement l'adresse email --GoubS
Faciliter l'inscription pour les nouveaux utilisateurs
La page
ParametresUtilisateur sert à trois choses dans
WikiNi :
- s'inscrire sur le Wiki pour la première fois
- s'identifier lorsque l'on est déjà inscrit
- paramétrer son profil
La personne qui découvre les Wiki pour la première fois est souvent un peu perdue. C'est clairement l'élément le plus complexe pour aborder le Wiki et du coup, il devient difficile d'expliquer cela par mail ou téléphone seulement et on est souvent obligé d'expliquer en présentiel (même si 10 minutes suffisent dans ce cas ;-).
Nous avons formé des dizaines de personnes pour participer à nos Wikini en France, Europe et Amérique latine (
http://www.videontv.org/wikini/ et
http://www.nib-jiq.org/). Mais ce serait super s'il était possible de simplifier l'inscription en séparant les trois fonctions dans certains cas.
cela pourrait etre fait en modifiant l'action "
UserSettings" en lui ajoutant deux paramètres :
- "type" qui pourrait prendre deux valeurs "inscription" ou "identification" pour n'afficher que la partie de l'action qui concerne l'inscription (sans le bouton "identification") ou la partie qui concerne l'identification (sans la deuxième partie du formulaire et le bouton "connexion").
- Dans le cas "identification" on pourrait même imaginer deux simples champs sur une seule ligne "vrai nom : * mot de passe : * [identification]" pour pouvoir le mettre facilement en header ou dans un coin de page.
- "next" qui donnerait la page suivante (la page ParametresUtilisateurs? de nouveau par défaut comme actuellement, mais qui peut être également PagePrincipale ou toute autre page)
Ainsi la version actuelle utilisée dans
ParametresUtilisateur reste compatible (fonctionnement par défaut), il est même bien qu'il reste telquel. Mais il devient possible d'ajouter des actions :
- pour l'identification seule : {{UserSettings type="identification" next="PagePrincipale"}} dans la page principale, un header, etc.
- pour l'inscription seule : {{UserSettings type="inscription" next="AccueilDesNouveaux"}} dans une page InscriptionDesNouveaux?
Normalement il suffirait d'une simple modification de l'action "
UserSettings" que l'on peut mettre dans les
ContributionsClesEnMain rapidement (enfin je pense)
Par la suite on peut améliorer l'intégration en :
- modifiant header.php pour que si la personne n'est pas inscrite on remplace son nom (plutôt disgracieux et inutile dans ce cas "vous êtes ASte-Genev-Bois-152-1-9-176.w82-121.abo.wanadoo.fr"...) par un "{{UserSettings type="identification" next="PagePrincipale"}} ou InscrivezVous?"
- ajoutant la page InscrivezVous? (avec dedans {{UserSettings type="inscription" next="AccueilDesNouveaux"}})
- ajoutant la page AccueilDesNouveaux? (avec des liens vers ReglesDeFormatage et BacASable)
Mais le plus urgent me semble de faire une nouvelle version de l'action
UserSetting. Cela n'offre pas de nouvelles fonctionnalités mais abaisse encore le ticket d'entrée pour devenir acteur sur un Wikini.
(Au passage : bravo pour la page
http://www.wikini.net/contrib/ c'est exactement ce dont je pouvais rêver de mieux pour simplifier l'installation. J'explique immédiatement à ma concierge comment elle peut installer son propre Wikini :-)
Amicalement --
JeanMichelCornu
Affichage de "Derniers Changements"
Lors de modifications mineure d'une page, style modification orthographique ou autre modification de ce style serait il possible de ne pas l'afficher dans derniers changements ou alors de mettre une option pour ne pas l'afficher, ou alors l'afficher en petit, ou encore, comme sur je ne sais plus quel wiki (
WikiPedia ?) preciser que c'est une modification mineure entre parentheses pas exemple... je ne sais pas... Mais je pense que ce ne serait pas bete de trouver une solution a ca tout d'abord parce je pense que ca peut etre mis en place assez facilement (créer une boite a cocher "modification mineure" dans la fenetre d'edition, et tant qu'on y est pourquoi pas rajouter un petit formulaire pour definir l'objet de sa modif comme sur
WikiPedia) et puis ca ferait gagner un temps fou a tous ceux qui passent souvent sur ce site. Je pense donc que la quantité d'enegie dépensée a créer/energie que ca fait economiser a l'avenir tend plutot vers zero! Non? ^_^ --
ArTemiS
- Oui je trouve aussi que ce sont deux évolutions intéressantes (c'est bien dans wikimedia qu'il y a ça au fait ;-)). Pour l'objet de la modif j'y vois tout de même quelques inconvéniants:
- Ca ralentit l'édition
- Ca peut inciter à ne pas consulter certaines modifications
- [c'est justement fait pour ça : éviter à tout le monde de consulter toutes les modifications, même celle qui ne concernent que les fautes d'orthographe ; si je vois que LordFarquaad a effectué une modification mineure de TellePage? en signalant une faute d'orthographe, je ne vais pas regarder le changement car j'ai confiance en lui et le changement est de peu d'intéret. -- CharlesNepote]
- Ca peut être falsifié afin de cacher un spam
- [non, car les "administrateurs" du site (ou les lecteurs réguliers), eux, lisent la liste des derniers changement intégrant les corrections mineures : cf. sur CraoWiki les et les . -- CharlesNepote]
- Ca peut être erronné ou même contenir aussi un spam -> il faut aussi pouvoir le changer
- [oui : peut-être vaut-il mieux ne pas interpréter ("formatter") ce contenu. -- CharlesNepote]
- ... mais les avantages sont les suivants:
- Se rappeler facilement d'une modification qu'on a déjà consultée (il m'arrive souvent de consulter deux fois la même page car je ne sais plus ce qui y a été dit)
- Consulter en priorité les modifications importantes ou intéressantes
- Ne pas consulter les modifications qui ne nous intéressent pas (corrections orthographiques etc.), eh oui...
- Je pense que ça peut tout de même être intéressant mais qu'il faudrait une option pour l'activer/désactiver, suivant les besoins du webmaster. Le deuxième point des inconvéniants (ainsi que le troisième) est d'ailleurs aussi valable pour le système de modifications mineures, je pense qu'il serait bon d'y adjoindre une vérification de l'empleur de la modification (vérifier le nombre de lignes affectées et le rapport de ce nombre avec le nombre total de lignes par exemple). Je pense que ceci devrait donc être étudié en parallèle avec le troisième point des SuggestionsRapiditeDeTraitement que j'ai faites au sujet de l'"Optimisation de l'utilisation de la base de données".
- Au passage je trouve que tant qu'à faire, on pourrait faire un système de "nouvelles modifications depuis votre dernière visite". Cependant cela ajouterait des requêtes sql... -- LordFarquaad
- Ta dernière proposition est un problème à part qui complique pas mal... -- CharlesNepote
Personnalisation des messages d'erreur, d'aide ou de bienvenue...
Peut-on envisager un fichier qui contienne des variables pour des messages personnalisés ? Par exemple, la formule «
Vous n'êtes pas autorisé à lire cette page » me semble bien sèche donc je la transforme en «
Pour lire cette page, vous devez vous identifier ». Le hic, c'est que ce sont une bonne poignée de fichiers à modifier. Si un seul fichier regroupe les messages, dans le type
$onepassepas = Cette page ne te calcule pas"; :-) ce serait bien pratique, y compris lors des mises à jour ultérieures.