Si vous souhaitez déployez un site similaire à Khaganat, la page Faire un site web comme Khaganat détaille d'une façon plus “tutoriel”.

Cette page est destiné à tous ceux qui souhaiteraient nous aider à améliorer notre ensemble de sites web.

La charte graphique est sur une autre page.

Nous sommes un projet bénévole. Cela veut dire que nous dépendons des bonnes volontés, du temps et des compétences de chacun pour fonctionner.

Dans ce cadre, nous avons quelques principes à respecter, énoncés ci-dessous.

Il est possible que quelqu'un maîtrisant “tout” le site web parte du jour au lendemain. C'est normal : nous sommes libres, et nous ne maîtrisont pas non plus les aléas de la vie qui peuvent nous éloigner.

Mais dans ce cas, que devient le travail de celui qui part ? Pour que les suivants puissent continuer ce qu'il a fait, il faut que tout soit facile à maintenir.

Cela veut dire :

• Documentez, encore et encore, à chaque test et nouveauté. C'est parfois difficile, c'est souvent brouillon et plein de fautes, mais mieux vaut une doc médiocre que pas de doc du tout, donc notez sur le wiki lorsque vous faites des choses ! Pour le site web, certaines données sont sur le wiki des admins (privés) mais nous tentons de transférer ici toutes les informations qui ne sont pas sensibles.
• Préférez un outil simple et facile à prendre en main à un outil complet mais complexe. Imaginez que quelqu'un n'ayant aucune notion de html soit chargé de gérer le site. Est-ce qu'il peut accomplir la maintenance et la réinstallation avec ces outils et la doc ?
• Limitez la nécessité de bidouiller et pensez aux backups. Si le serveur ou le site subit un aléa, en combien de temps un noob complet peut-il tout remettre en place, de la même façon ?

Lorsque les applications le permettent, donnez les droits d'administration à une des autres personnes considéré comme étant de confiance et régulièrement présente. Sinon, partagez les mots de passe en respectant les consignes de sécurité avec quelques membres ayant des privilèges similaires aux vôtres.

C'est un des choix délicats à propos de la sécurité. Partager le pouvoir et utiliser Teampass augmente un peu les risques, mais permet aussi de ne pas trop perdre de choses lorsque un admin disparaît.

On le répète sans cess, mais c'est vraiment vital pour reprendre derrière…

Vous avez le droit d'utiliser ce que vous voulez pour naviguer, créer, jouer… Par contre, les outils que Khaganat promeut doivent être libres et hébergeables. Nous voulons garder le “contrôle” sur nos données et laisser chacun libre de réutiliser notre travail. Nous acceptons de relayer nos infos sur les plate-formes propriétaires (youtube, dailymotion, facebook, github), mais nous n'en faisons pas la promotion pour autant et nous vous invitons, autant que possible, à venir “à la source”¹⁾.

Donc si vous voulez nous proposer un outil, une fonctionnalité, veillez à sa licence. Nous ne travaillerons pas sous Slack et Asana.

Nous n'hébergeons pas forcément tous nos outils, mais nous essayons de le faire aussi souvent que possible. Nous utilisons les services de Jabberfr.org pour XMPP, par exemple, et les services de certains CHATONS régulièrement, mais ces services sont libres et nous pourrions aussi les mettre sur le serveur… simplement le service offert par ces organismes et leur philosophie nous conviennent²⁾.

Nous sommes conscients des problèmes que peuvent rencontrer certains utilisateurs dans leur navigation sur internet. Nous souhaitons que l'ensemble de nos services soit accessible, quelque soit le handicap physique ou technique de nos utilisateurs.

Ce n'est absolument pas le cas actuellement, car nous manquons de développeurs en CSS… Lorsque cela nous est possible, nous intégrons ce questionnement en amont des développements.

Si possible, faites en sorte que :

• Le site soit confortable et sympathique pour tous les écrans : smartphone, écran d'ordinateur, de netbook ou de 21 pouce… donc prévoir des feuilles de style différentes suivant la taille détectée.
• Permettre un changement de thème adapté aux divers problèmes visuels : plus contrastés, avec des couleurs adaptées…
• Permettre que chaque partie du site puisse être lue par un logiciel vocal.
• Décrire les images si elles sont utiles ; préciser sinon qu'il s'agit d'une image “pour remplir” dans le code.
• Faciliter la navigation par touches.
• S'interdire autant que possible de recourir à des technologies bloquant la police, les couleurs…

L'accessibilité est un sujet extrêmement complexe, mais il est impératif de chercher à l'améliorer. Vous trouverez plus d'informations et d'outils sur la page Accessibilité.

Notre architecture est, techniquement, assez complexe. Tout est hébergé sur de gros serveurs dédiés et les services sont dans des VM sur ces serveurs.

Voici comment les services sont répartis³⁾ :

• Une VM (jukni) hébergeant la majorité des services web
• Une VM pour etherpad, parce que ce service nous a causé des soucis à certains moment et comme ça il ne met pas le bazar partout.
• Une VM réservée à Gitlab (branaz), afin de lui allouer toutes les ressources en cas de compilation.
• Une VM pour le serveur de jeu (liria), qui héberge aussi les comptes des joueurs et donc l'application pour créer leurs comptes.

Il y a aussi, de façon temporaire⁴⁾, des espaces de test. Les droits sur ces VM peuvent être ouverts si vous avez besoin de faire des tests sur un serveur⁵⁾.

Au 02 septembre 2018, nous avons entre autre les CMS suivants qui sont installés (voir plus bas pour le détail) :

• Dokuwiki, sous forme de “ferme”
• Simple Machine Forum
• Etherpad-Lite
• Photoshow-gallery
• Gitlab
• AMS (sur le serveur de jeu)
• Weblate
• Nextcloud

Nous avons quelques pages “faites maison” :

• La partie XMPP/IRC
• La barre de navigation générale, qui se retrouve sur presque toutes les pages du site
• Le convertisseur Dokuwiki vers Mediawiki
• Divers petits outils, comme un générateur de nom pour Khanat, des étoiles pour Célestia, etc.

Un site en Django a commencé à être développé. Voir :

• Khaganat web
• Installer Django et le site web Khaganat

Il a déjà plusieurs modules codés :

• remplaçant du pastebin
• pages statiques (qui seront entre autre utilisé pour l'accueil)
• la barre de navigation générale, comprenant la prise en charge de l'internationalisation
• gestion des utilisateurs, bref la base d'une authentification unifiée avec un profil.
• Page pour voir les logs de XMPP avec une gestion du “NSFW”. Parce que parfois faut avoir un avertissement avant de lire… pas mal d'outils utiles autour de ces logs dans ce module.

Django va peu à peu permettre de faire l'interface entre les divers CMS et le jeu.

Tout ce qui est utile pour contribuer au site web est disponible sur le dépôt "Site internet".

Dokuwiki est un excellent moteur de wiki.

• Nous aurions besoin de refaire les templates des wiki. Nous sommes basés sur une vieille version qui ne prends pas en compte de nouvelles fonctionnalités du moteur (qui lui, est à jour) et ça a été modifié à la R.A.C.H.E. De plus, ça ne passe absolument pas sur mobile… Bref, si vous maîtrisez le css, le html et un chouïa de php, ça devrait bien se passer ! Au printemps 2020, Zatalyz a entrepris de refaire un thème accessible, responsive, en accord avec la charte graphique. Vous pouvez trouver ça sur https://git.khaganat.net/zatalyz/khum1.
• Certains plugins qui nous étaient utiles ne sont plus maintenus et ont été cassés lors de mises à jour. Si vous avez envie de les reprendre, toute la communauté Dokuwiki en profiteras. Cela demande de bonnes connaissances en PHP et l'envie de bien comprendre comment fonctionne Dokuwiki.

Téléchargez le thème propre à la partie qui ne va pas.

La difficulté actuelle des thèmes tient premièrement à l'intégration de la barre de navigation générale. En effet, il faut arriver à intégrer la nouvelle version. Sur les wikis, c'est encore l'ancienne qui est en place… parce que ça marche ; il doit y avoir quelque chose dans la nouvelle qui entre en conflit avec les thèmes ou qui est mal finalisé.

Notez que la “nouvelle” nouvelle version est celle de Django ; nous n'avons pas encore tenté son intégration ! Django génèrera la barre en html pour l'intégration dans les wiki.

• Installez Dokuwiki en local.
• Partez du thème par défaut et modifiez-le ; ne partez pas des thèmes de Khaganat. Mais vous pouvez regarder comment ils sont faits et vous en inspirer. Le thème par défaut est responsive et relativement bien conçu.
• Intégrez la barre de navigation générale de Khaganat, puisqu'il faut que ça marche avec.
• Soumettez vos idées de design à la communauté, cela vous évitera de bosser pour rien si vous partez sur quelque chose de vraiment différent.
• Internationalisation : le thème doit pouvoir s'internationaliser, donc utilisez des variables pour les textes qui s'affichent.
• Responsive : si vous êtes partis du thème de base et si la barre de navigation a été finalisée, l'aspect responsive ne devrait pas être trop complexe.
• Accessibilité : le maximum de monde doit pouvoir utiliser les wikis, peut importe le handicap.

Sur Khaganat, Dokuwiki est organisé sous forme de ferme. Cela veut dire qu'il y a un wiki “maitre”, où le moteur est installé, et des wiki “animaux” qui contiennent uniquement les datas et quelques particularités (genre certains thèmes ou plugins). Tous ces animaux utilisent la même base d'utilisateur.

Voici la liste des animaux :

• bienvenue qui héberge la page d'accueil, les mentions légales et la page de contribution. Bien que ce soit techniquement un wiki, sa modification est réservée aux membres du Collège de l'association et sa présentation imite un site statique.
• wikhan : c'est le wiki sur lequel vous vous trouvez. Il héberge la documentation généraliste.
• blog : le blog, avec certains plugins qui permettent d'avoir des fonctions de blog. Cela permet à tous les inscrits de poster un article de blog.
• mediateki : Ce wiki est destinée à recevoir des histoires sur le monde de Khanat.
• um1 : c'est l'encyclopédie du monde de Khanat. Les onglets animation, dev et gameplay hébergent aussi des informations concernant le serveur de jeu (comme les quêtes).
• un wiki spécial administrateurs, avec des infos sensibles donc pas accessible au public !
• des vieux tests qu'il faudrait que j'archive et nettoie un jour et qui sont sans importance dans le cas présent…

Notre forum.

Notre choix en matière de forum se base sur deux choses :

• Un certain attrait pour le visuel “phpbb2”. Non, je n'aime pas ces trucs à la mode sans catégorie et avec l'avatar qui n'est pas à gauche du texte.
• La nécessité de pouvoir lier un compte principal à plusieurs sous-comptes. À terme, l'idée est de se connecter avec son compte utilisateur (le même que pour les wikis, le jeu, etc) mais de pouvoir intervenir sur le forum soit sous ce pseudo, soit avec le pseudo de ses personnages en jeu, afin d'aider le roleplay. SMF propose un plugin gérant les sous-comptes, qui n'est pas vraiment à jour mais qui fonctionne tout de même.

En dehors de ça, nous sommes ouverts aux suggestions. SMF est sympa, mais plein de fonctionnalités dont nous n'avons pas vraiment l'usage, finalement… Et dans l'absolu, nous aimerions un forum offrant d'autres fonctionnalités aux joueurs, comme le fait d'héberger son sous-forum de guilde directement, lié aux persos, avec la possibilité de mettre des parties publiques et d'autres privées. Le Forum-CMS de nos rêve est un vague projet, qui demanderait un vrai programmeur.

La seule chose qui nous manque réellement sur le forum, actuellement, c'est de pouvoir lier ça à une connexion unique. Voir plus bas.

Cependant, si vous avez envie d'aller plus loin, nous avons prévu d'utiliser Django pour l'API du serveur de jeu ; développer un forum avec Django, ou reprendre ce qui existe déjà avec ce framework et l'adapter à nos envies, est donc une très bonne idée.

Si vous avez envie de coder un forum en tant que module pour Django, nous avons déjà un cahier des charges ! Yaplukal'faire !⁶⁾

Un module a été développé pour Django. Les pastebin nous servent régulièrement au sein du projet.

Il faudrait qu'on arrive à mettre Django en prod, on verra le reste ensuite…

Une installation d'Etherpad, avec quelques plugins, dont “Mypads”. Il est lourd et gourmand en mémoire mais les pads nous servent souvent, cet outil est donc vraiment utile pour nous.

Améliorer son css et lui intégrer la barre de navigation serait un plus.

Pouvoir le lier à l'authentification unique serait pratique, mais ça marche sans aussi, donc… : Mise à jour : on va avoir un truc sécurisé, on va éviter d'ouvrir une faille en liant ça avec etherpad qui n'a pas toute ma confiance.

Ce CMS sert à héberger nos images. Il nous a rendu service, mais à présent il correspond de moins en moins à nos besoins. Je ne lui ai pas trouvé de remplaçant.

J'apprécie le fait qu'il fonctionne sans base de donnée. Mais sinon :

• Je ne vois pas comment le lier à l'authentification unique et ça m'embête
• J'aimerais bien que ça puisse se lier aux guildes et aux comptes joueurs, qu'il y ait automatiquement la possibilité d'héberger des images privées et publiques pour ces deux types de comptes.
• Les media associés à des tags, c'est sympa aussi
• Une meilleure gestion du cache et de la prévisualisation. En l'état, c'est vite lourd à charger.
• Mettre en avant des galeries, genre en page d'accueil “les meilleurs screens du moment” en diaporama.
• Pouvoir y héberger aussi nos vidéos, même avec un player très basique.

Bref il nous faudrait de quoi gérer les médias. Si vous connaissez un bon truc pour ça, parfait. J'ai testé quelques CMS, dont Piwigo (l'un des meilleurs dans le lot) sans être complètement convaincue pour autant.

Note au 22 Juillet 2017 : pour les vidéos, Peertube est extrêmement prometteur et une instance sera probablement installé quand nos besoins seront là.

Pour la partie images, il faudra peut-être voir les modules de Django, simplement.

Cette partie là ne pourra être remplacée qu'avec un cahier des charges décrivant précisément nos besoins. Donc si vous voulez aider, participez à la rédaction de ce cahier des charges !

Gitlab sert à gérer les dépôts. Il prend beaucoup trop de ressources, mais il est vraiment très utile aussi…

Arriver à intégrer la barre de navigation générale serait vraiment bien. Mais Gitlab n'est vraiment pas évident à bidouiller, et il faut arriver à faire une bidouille qui survive aux mises à jour trop régulières sur logiciel. Connaissances en Ruby nécessaire.

AMS est l'outil web de Ryzom Core qui sert, entre autre, à gérer les comptes des joueurs sur le serveur de jeu.

Il n'est pas finalisé et mal documenté… Voir plus bas “Développements futurs”.

L'équivalent de Limnoria pour XMPP. Voir ici.

Nous avions installé Piwik à un moment (devenu Matomo depuis). Mais pister nos utilisateurs nous déplaît et Matomo est trop facilement intrusif. Nous avons donc supprimé tout ça.

Notre intérêt pour ce genre d'outil tiens à peu de choses :

• Lorsque le MMORPG sera en route, savoir si on a du monde dans d'autres fuseaux horaires, histoire de chercher des modératrices suivant les populations.
• Voir si la com qu'on fait, parfois, a un impact (les gens viennent-ils voir chez nous ?). Mais en vrai, on s'en fout un peu, ce qui compte c'est quand ils viennent pour de bon et se mettent à papoter, et ça, on le sais.
• Potentiellement, savoir quelles sont les pages les plus visitées, afin de les améliorer et de veiller à leur traduction en premier.

Un outil d'analyse du site, comme présenté ici, ou encore GoAccess, serait plus pertinent, afin de chercher les trucs qui ne vont pas : erreurs sur les pages, etc.

Permettait de partager des mots de passe. Mais nous avons eu le passage d'une pro de la sécurité, qui a pointé de nombreuses failles. Depuis, il est désactivé, sans lui avoir trouvé un remplaçant aussi ergonomique.

La barre en haut, censée se retrouver sur tous les sites et permettre de naviguer rapidement d'une partie à l'autre

Nous avions récupéré et customisé la Framanav (il y a longtemps), d'une façon assez “sale”. Résultat, cette barre nous pose des soucis, en faisant appel à des classes et/ou des fonctions qui sont aussi utilisées dans les CMS (bootstrap/jquery), ce qui met le boxon régulièrement. Sinon, on aime bien la façon dont elle fonctionne.

Osquallo a proposé une nouvelle version ici en 2016. Elle a été mise en place sur toutes les parties qui ne sont pas des wikis (par exemple sur le forum).

Elle n'est pas finalisée car il manque la gestion sur les petits écrans (portables) et elle fait aussi un truc bizarre à charger le css avec un peu de latence. Son intégration sous chrome et autres navigateurs est parfois étrange. Son accessibilité pourrait aussi être meilleure. Elle méritait d'être encore travaillée.

Il suffit d'avoir des bonnes connaissances en css/html. Se baser sur un framework type bootstrap est hors de question, chaque appel doit être spécifique à la barre de navigation, sinon ça met du bazar dans les CMS ensuite.

Cette barre doit impérativement être accessible. Si c'est horrible avec un logiciel comme Links2, ce n'est pas bon. Tout le menu ne peut donc pas être en javascript.

Vous voulez l'améliorer ? Voici les axes :

• Sur petits écrans, la transformer en un “hamburger” en position absolute dans un coin, qui une fois déplié affiche les sections “khanat” et “khaganat”, sur lesquelles on clique pour déplier et voir tous les liens ; chaque lien a une icone propre à la version minimisé qui permet d'afficher la description, sinon on ne voit que le nom).
• Accessibilité : y'a-t-il un moyen d'afficher la description des items uniquement à la demande dans un mode texte style links ?
• Navigateurs : trouver comment la faire fonctionner sur tous les navigateurs modernes, parce qu'avoir des horreurs sous Chromium, ça le fait pas, c'est quand même un navigateur bien utilisé.
• Ergonomie : dans le cas d'une navigation avec javascript activé, mettre en place la fonction pour que le menu s'ouvre et reste ouvert lorsqu'on clique dessus ; le menu doit rester utilisable si javascript est désactivé.
• Internationalisation : permettre que la langue de la barre dépende de la langue de l'utilisateur ; par défaut détection automatique suivant le navigateur, mais il faudrait pouvoir le changer (cookie, drapeau de langue ?)

Nous souhaitons qu'un utilisateur utilise le même couple mot de passe/pseudo sur tous les éléments du site web.

Nous aimerions surtout que l'utilisateur ait, dans la barre de navigation en haut, la possibilité de “se connecter/s'inscrire”, ce qui le redirigerait vers une page de connexion/inscription (ou ouvrirait une fenêtre dépliante ?) et qu'une fois son compte créé/connecté là, il soit d'office connecté sur les divers éléments du site, de dokuwiki à gitlab en passant par SMF et autres.

Il semblerait que Oauth2 permette ça. Gitlab fournit justement un serveur Oauth ; dokuwiki et owncloud semblent pouvoir utiliser ce protocole aussi. D'après un webadmin qui nous a présenté cette solution, connecter un CMS qui n'a pas de plugin Oauth n'est pas très complexe ; c'est ce qu'utilisent Google, Facebook etc et donc il suffit de modifier ce genre de trucs.

L'utilisation de Django pourrait peut-être aussi servir.

Une autre solution consisterait à utilise l'authentification XMPP, mais cela demande du développement.

Il y a un gros boulot à faire de ce côté.

Si vous maitrisez Oauth, Django, Gitlab, Dokuwiki, XMPP… ou autre, aidez-nous !

Nos chantiers prioritaires sont :

• Le chantier de longue haleine de l'authentification unique
• Bidouiller Django pour les API avec le serveur de jeu

Django est un framework en python. Nous avons des développeurs en python.

Les API fournis avec Ryzom Core sont un sacré bazar. Sans documentation, rarement finies, impossibles à déployer, elles sont, en l'état, inutilisable. Il est apparu que ce serait moins long et plus facile de tout reprendre à zéro, ce que certains se proposent de faire au sein de l'équipe. Il est possible que les possibilités de Django soient aussi mises en œuvre pour le forum et le gestionnaire de média ; en fait, pour faire un CMS adapté à nos besoins. À condition toutefois que la documentation et la maintenabilité soient là…