11.1 Agencement du site

La page principale de votre site Wordpress sert essentiellement à configurer le site lorsqu’elle est appelée depuis Moodle (enregistrement des données de l’étudiant dans un localStorage) et donne les instructions principales pour bien démarrer avec le contenu pédagogique. Cette page laisse une large place à gauche pour le login GitHub, quelques liens utiles (accueil, contact) et liste les différents bookdown disponibles, un par cours.

Chaque bookdown est dans une sous section du site, et reprend un numéro de version correspondant au début de à l’année académique : /cours-2022/, /cours-2023/, etc. Une fois la page principale activée depuis le lien Moodle Cours, l’étudiant peut aller vers le bookdown qui correspond à son cours et tout devrait fonctionner correctement. La page principale de chaque bookdown effectue de son côté les vérifications nécessaires, affiche un court compte-rendu, et permet d’effacer les données personnelles (compatibilité RGPD) si souhaité, voir 10.

Le site est complété d’une bannière supérieure dont l’aspect peut être personnalisé à travers les thèmes Wordpress et qui propose des liens vers différents items importants dans le cadre du cours pour obtenir de l’aide (Moodle, Issues, Email, …), et donne aussi accès à l’explication pour installer le logiciel que l’étudiant va utiliser. Et c’est tout. Le but est de faire ici simple et efficace…

11.1.1 Tableau de bord

Dès qu’un utilisateur s’enregistre sur le site, une barre supérieure noire apparaît avec des options supplémentaires en fonction de son rôle. Un étudiant a évidemment un nombre d’options limitées à l’édition de son profil et la consultation de sa progression H5P. Un éditeur (prof) peut aussi créer et modifier des pages. Enfin, un administrateur a accès à l’ensemble des fonctions pour personnaliser le site.

Pour tous les utilisateurs, un tableau de bord est accessible à partir de cette barre noire supérieure. Une fois le compte créé dans Wordpress, un étudiant a la possibilité de s’y connecter via GitHub et de modifier ses informations dans le tableau de bord, dont son adresse email. S’il le fait, cette adresse n’est alors plus la même que celle enregistrée initialement dans d’autres serveurs comme Posit Connect. C’est pourquoi, nous conservons ces deux informations séparément : email pour l’email du site Wordpress et iemail pour l’email institutionnel tel que renseigné à partir de Moodle. C’est toutefois l’adresse email enregistrée dans Wordpress qui est employée pour enregistrer les activités H5P. Pour les learnr et les app Shiny, c’est le login qui fait référence et qui doit être renseigné, sinon aucun enregistrement n’est réalisé (visiteur externe). Lorsque l’activité learnr ou app Shiny ne se fait, cela est indiqué par un message explicite pour éviter qu’un étudiant oublie de se logger, et puis que son travail soit perdu. Par contre, H5xAPIkatchu enregistre l’activité H5P sous un UUID créé à la volée. Nous pouvons toujours filtrer et éliminer ces données-là plus tard.

Par ailleurs, les évènements principaux H5P (début, fin, durée et résultat à la soumission des exercices) sont également enregistrés dans Wordpress directement. Cette information peut paraître redondante avec l’enregistrement H5PxAPIkatchu, mais elle est utile car l’étudiant ou l’enseignant y a accès directement dans son tableau de bord. Il peut y lire les détails de sa progression dans l’ensemble des exercices H5P de tous les cours, s’il le souhaite (voir capture d’écran). Reste à déterminer l’occupation disque de cette fonction afin de décider si nous la conservons activée sur le long terme !

Suivi de la progression H5P dans le tableau de bord accessible aux étudiants.
Suivi de la progression H5P dans le tableau de bord accessible aux étudiants.

Comme nous pouvons le voir, le tableau de bord de l’étudiant est réduit au minimum. En plus de la partie “H5P Content” où il peut voir et filtrer la liste des applications H5P et voir ses propres résultats H5P, il a accès à son profil où il peut modifier des données utilisées par nos outils. Il me semble que la maîtrise et la visibilité des données enregistrées le concernant font partie des contraintes RGPD pour lesquelles Wordpress assure la compatibilité.

Les enseignants sont enregistrés comme éditeurs sur le site. Dès lors, ils peuvent aussi modifier le contenu du site, et surtout, modifier et créer du contenu H5P avec des éditeurs conviviaux. Ainsi, l’ensemble des outils nécessaires pour l’édition du contenu sont regroupés dans ce tableau de bord… à l’exception des bookdowns et des applis Shiny/learnr. Ces dernières sont mise à disposition via un serveur RStudio Connect, totalement différent donc. Par contre, les bookdown doivent, eux, être intégrés dans le site. La façon de réaliser cette intégration est expliquée dans la section consacrée à bookdown (5).

11.1.2 Authentification des étudiants

Avec un site Wordpress correctement configuré pour s’intégrer dans la plateforme LearnIt::R LRS, l’authentification des étudiants se fait comme suit :

  1. Vous ajouter un item de type “URL” dans Moodle pour transmettre au site Wordpress des informations relatives à l’utilisateur authentifié dans votre institution (“query string”, c’est-à-dire la partie “?…” de l’URL). On obtient de cette façon, entre autres, son numéro de matricule, son adresse email, son nom et son prénom, le cours qu’il suit, … Les détails sont dans la section correspondante (voir 12) et ne seront donc pas discutés ici.

  2. Dans Wordpress, vous pouvez intégrer une authentification sur base de leur compte GitHub via le protocole OAuth2 au travers d’une application qui fait le pont entre Wordpress et GitHub.

Écran de login via GitHub la première fois que l’étudiant se connecte à GitHub via Wordpress au travers de l’application dédié qui est nommé ici “BioDataScience”.
Écran de login via GitHub la première fois que l’étudiant se connecte à GitHub via Wordpress au travers de l’application dédié qui est nommé ici “BioDataScience”.

C’est doublement intéressant car vous obtenez ainsi leur login GitHub, et aussi, vous êtes certain•es que leur compte GitHub est créé et actif dès le moment où ils sont enregistrés dans Wordpress avec le même login. Que des avantages, donc. De plus, dans l’implémentation choisie, la connexion via GitHub montre clairement à l’étudiant s’il est connecté ou non.

Exemple de page principale du site lorsque l’utilisateur n’est pas connecté.
Exemple de page principale du site lorsque l’utilisateur n’est pas connecté.
La même page principale du site lorsque l’utilisateur est enregistré et connecté via GitHub.
La même page principale du site lorsque l’utilisateur est enregistré et connecté via GitHub.

Afin d’éviter que n’importe qui ayant un compte GitHub ne s’enregistre dans Wordpress, vous pouvez faire en sorte que vos étudiants doivent rappatrier leur identité à partir de Moodle avant de pouvoir se connecter via leur compte GitHub.. Dès que l’étudiant s’est enregistré, les données utiles venant de Github sont rentrées dans la table des utilisateurs Wordpress. Vous combinez les données provenant de Moodle et de GitHub pour établir un profil complet de l’étudiant dans votre site Wordpress automatiquement. A noter que Wordpress tente de récupérer aussi d’autres informations venant de GitHub, dont l’email. Cependant, ce dernier peut être caché dans le compte GitHub (c’est d’ailleurs le cas par défaut), et n’est donc pas accessible. La plupart du temps, vous n’avez donc que l’email institutionnel à disposition. Dans la plateforme LearnIt::R LRS, vous pouvez utiliser l’email Wordpress, l’email institutionnel, ou le login Github de manière interchangeable selon le contexte comme identifiant, mais seule la présence du login est vérifiée pour activer l’enregistrement de l’activité dans H5P/learnr/Shiny. Il reste souhaitable que l’étudiant indique le même email que son email institutionnel comme email primaire dans son compte GitHub, sans quoi, ses commits ne pourront peut-être pas lui être attribués dans GitHub. C’est de sa responsabilité et actuellement, nous n’avons aucune visibilité sur l’email utilisé sous GitHub par l’étudiant dans l’implémentation mise en place2.

11.1.3 Variables contextuelles

Pour l’enregistrement de l’activité des étudiants, nous avons besoin de définir un certain nombre de variables reprises dans le tableau ci-dessous. Toutes ces variables sont obtenues directement à partir de Moodle, si cette plateforme est utilisée. La colonne origine indique d’où nous obtenons ces informations (il faut que l’étudiant ait cliqué sur l’item qui envoie ces informations depuis son compte Moodle et à partir de la page de cours correspondante).

Variable Contenu Origine
login Le login GitHub de l’étudiant WP via GitHub
email Le mail renseigné dans Wordpress WP via GitHub si public
displayname Nom utilisateur Wordpress(/Github) WP
firstname Prénom comme indiqué dans Wordpress WP
lastname Nom de famille comme indiqué dans Wordpress WP
iemail Le mail UMONS (institutionnel) de l’étudiant Moddle iemail= Adresse de courriel
iid Numéro de matricule de l’étudiant Moodle iid = Nom d’utilisateur
ifirstname Prénom comme indiqué dans Moodle Moodle ifirstname = Prénom
ilastname Nom de famille comme indiqué dans Moodle Moodle ilastname = Nom
institution Institution (ici UMONS) Moodle institution = Institution
icourse Nom de code Moddle du cours (ex.: S-BIOG-006) Moodle icourse = N° d’identification du cours
iurl URL du serveur institutionnel (Moodle) Moodle iurl = URL du serveur
iref Identifiant unique dans Moodle Moodle iref = Numéro d’identification
ictitle Titre du cours (ex. Science des Données I: visualisation) Moodle ictitle = Cours
icflag Indicateur pour les étudiants suivants plusieurs cours simultanément WP (éditeur des utilisateurs en mode admin)
user_login2 Second login GitHub pour le même utilisateur WP (éditeur des utilisateurs en mode admin)

A noter que nous croisons différentes sources (Moodle, GitHub, Wordpress), et les infos peuvent différer entre ces sources. Considérant un étudiant qui a “installé” ses outils correctement, à savoir :

  • Son compte est créé au préalable dans Wordpress via un enregistrement approprié (voir au début de la section),
  • Il a créé un compte GitHub et y a renseigné son adresse mail UMONS,
  • Il a au moins une fois lancé la page https://wp.sciviews.org depuis le lien Moodle “Cours” dans la section “Ressources en ligne” de son cours,
  • Dans la page qui s’ouvre, il s’est connecté dans Wordpress à partir du bouton de login via GitHub/BioDataScience.

A ce moment-là, tout sera en place pour gérer correctement son identité dans les différents matériels pédagogiques (bookdown, H5P, learnrs, apps Shiny, etc.). Le seul point sur lequel il faudra rester vigilant est l’identifiant de l’étudiant pour ses commits, pour lequel nous n’avons pas de contrôle automatique pour l’instant. Il ne lui restera plus alors qu’à installer la SciViews Box pour être pleinement opérationnel. Cela semble être un nombre important d’opérations à réaliser pour arriver à cela, mais l’étudiant est guidé de manière naturelle : il va dans Moodle, se connecte et sélectionne le cours dans la liste (il a déjà l’habitude). A partir de là, il clique naturellement sur “Cours”, d’où la page qui l’enregistre et lui propose de créer un compte GitHub. Une fois que c’est fait, il peut cliquer sur le gros bouton bleu “GitHub/BioDataScience” pour se connecter dans le site “Science des Données Biologiques”, et il sélectionne le manuel correspondant à son cours dans la liste. A ce stade, c’est fait. Il est enregistré3 !

Faut-il forcer le login de l’étudiant dans Wordpress ? Autrement dit, il n’aurait accès aux cours que s’il est connecté. Il existe des plugins Wordpress qui permettent de faire cela, et aussi d’exclure les pages qui peuvent être vues par tous. Un de ces plugins est Force login. Nous verrons à l’usage…

Toutes les informations de son compte sont accessibles à l’étudiant dans Wordpress, et il peut librement les modifier dans le tableau de bord, sauf son login. Donc, cela signifie que l’information cruciale pour identifier un étudiant est login qui est par ailleurs toujours le même que le login GitHub, et iemail, son adresse email de l’UMONS fournie par Moodle. Nous avons éventuellement besoin aussi de email, son email Wordpress sous lequel les activités H5P sont enregistrées.

Si nous continuons à utiliser Discord, ce serait bien d’avoir le login Discord de l’étudiant aussi. Mais ici, il a le droit d’y poser des questions de manière anonymisée (c’est notre souhait). Néanmoins, il serait utile d’avoir un champ où nous pouvons éventuellement rentrer cette info à la main si souhaité dans la liste des utilisateurs enregistrés dans Wordpress (TODO: vérifier si c’est possible). Une autre colonne comment serait aussi utile. Nous pourrions y indiquer par exemple si un étudiant a des difficultés particulières, ou la date de son arrivée pour les étudiants étrangers en passerelle, par exemple.

11.1.4 Redirection d’URL d’iframe bookdown

Les contenus de type {bookdown} forment l’essentiel de l’information contenue dans le site. Cependant, ces pages sont générées indépendamment des pages Wordpress. Elles sont servies à partir du même domaine, mais pas réellement intégrées dans le site Wordpress lui-même. Elles y sont insérées dans un iframe géré par le plugin “Advanced Iframe Pro”.

Une conséquence visible de cette organisation est l’URL qui présente de manière explicite le fait que la page bookdown est contenue dans un iframe. Par exemple pour https://wp.sciviews.org/sdd-umons-2023/nuage-de-points.html en présentation directe hors iframe, la même page est servie par le site Wordpress à https://wp.sciviews.org/sdd-umons/?iframe=wp.sciviews.org/sdd-umons-2023/nuage-de-points.html. Jusqu’ici tout va bien. L’adresse est un peu longue, mais ce n’est pas tellement grave en pratique.

Tout fonctionne bien, à part une petite subtilité concernant les ancres. Une ancre est un signet placé dans une page. Elle permet de l’afficher à partir de cet endroit au lieu d’afficher juste le haut de la page. Par exemple, la page nuage-de-points.html ci-dessus peut être affichée à partir du point “2.2.1 Echelles de graphiques” correspondant à l’ancre échelles-de-graphiques à l’aide de l’URL suivante : https://wp.sciviews.org/sdd-umons-2023/nuage-de-points.html#échelles-de-graphiques. Mais si nous rajoutons #échelles-de-graphiques à la fin de l’URL correspondante de Worpress, il ne se passe rien. La page s’affiche au début, et non pas au point 2.2.1 comme demandé. En fait l’ancre est interprétée pour la page de base Wordpress, pas pour la page contenue dans l’iframe. Pour corriger cela, il faut URLencoder l’ancre, qui consiste à remplacer le # par son code qui est %23. Ainsi, si on écrit https://wp.sciviews.org/sdd-umons/?iframe=wp.sciviews.org/sdd-umons-2023/nuage-de-points.html%23échelles-de-graphiques, alors l’ancre fait maintenant partie de l’URL de l’iframe et cela fonctionne comme prévu.

Vous noterez aussi que les ancres ne sont pas rajoutées automatiquement à l’URL lorsque vous cliquez dessus dans une page {bookdown} contenue dans un iframe. Vous devez donc effectuer le rajout à la main si nécessaire pour enregistrer correctement cette URL. En effet, “Advanced Iframe Pro” ne gère pas encore correctement les ancres de manière automatique. Une façon simple de découvrir l’identifiant d’une ancre consiste à cliquer bouton droit dessus et à choisir “Ouvrir dans un nouvel onglet” dans le menu contextuel. A ce moment, la redirection du lien cliqué dans l’iframe s’affiche dans une page séparée hors iframe, avec son URL complète, y compris son ancre. Copiez cette ancre et collez-là à la fin de l’URL de la page de départ avec iframe après modification du # en %23, et le tour est joué.

À part ces petits tracas relatifs aux ancres, les pages {bookdown} dans les iframes se comportent très bien par ailleurs et permettent de combiner le meilleur des deux mondes : Wordpress et ses nombreuses fonctions et plugins et {bookdown} pour un contenu riche créé à partir de documents R Markddown.


  1. Pour les enseignants, lors des premiers commits réalisés par vos étudiants, veuillez vérifier s’ils sont clairement identifiables. Sinon, faites corriger l’information (identifiant git et email).↩︎

  2. Il est conseillé aux enseignants de tester la procédure auparavant pour vérifier qu’ils en maîtrisent bien la logique.↩︎