Valery Fremaux

Quelle version de MySQL ?

"Ne suis par exemple pas parvenu à saisir si seule la base de données devait subir ce traitement vers l'utf8 ou si d'autres fichiers de Moodle devaient être eux aussi convertis ?"

Non en principe seule la base nécessite une conversion, les fichiers de la nouvelle distribution de Moodle étant convertis par ailleurs. Il est par contre possible que de nombreux fichiers d'une distribution 1.6, actuellement considérée comme assez ancienne n'aient pas été complètement convertis. L'effort de mise à jour et de maintenance portant aujourd"hui sur des versions de 1.7 à 1.9.

L'installation de la 1.6 est elle effectuée sur une copie de la base en 1.5.4 ?

Oui en effet, en générant le config.php à la main, tu fais penser à Moodle que la phase de récolte des paramètres d'environnement est terminée et qu'il a lui même écrit ce fichier. Du coup, il s'attend à ce que les tables soient dans la base et qu'il puisse recharger les valeurs de configuration posées par les scripts de génération de base.

J'ai encore du mal à visualiser le point de blocage. Est-ce après la saisie des paramètres serveur et base de données ou avant ?  

Dans les plates-forme PHP, pour assurer un démarrage (et parfois un plantage) "propre" (à l'écran, pour l'utilisateur final), la sortie des messages d'erreur est désactivée.

En PHP, la fonction error_reporting permet de modifier le réglage de la sortie d'erreur PHP. Si n=4096 toutes les erreurs PHP sont affichées.

Sur de nombreux serveurs d'hébergeurs, la valeur de l'error_reporting est faible, voire très faible. Ceci évite que du code PHP mal écrit lance des tones de warnings à l'écran alors que le développeur (souvent novice) n'a rien vu sur son PC.

Moodle gère en interne le niveau de rendu des erreurs, mais une fois installé. Le script d'install et de génération de la configuration que je n'ai (je l'avoue) pas dépouillé à la ligne près peut lui-même modifier ce niveau d'erreur.

L'écran que tu as montré montre (!) précisément du vide là ou on attend quelque chose. Si les erreurs PHP sont désactivées, la génération PHP s'arrête... et tu ne vois rien.

Une première idée est de repérer le nom de la page php (install.php ??) et de glisser au tout début un

error_reporting(4096);
set_ini('display_errors', 1); // ce qui ne devrait pas manger de pain...    

et si ça suffit pas un :

set_ini('display_startup_errors', 1);

bien que la dernière ne me semble pas très utile : pour affichr les erreurs de lancement de PHP (donc avant le code), on voit mal comment on peut les réactiver après le lancement.

On devrait essayer de pouvoir voir qque chose...

Libérer un slot du rendez-vous sans détruire la disponibilité du slot : facile.

"La ligne épaisse", beuark aussi. J'ai mis "en gras" dans le nouveau fichier de langue.

Priorité des recherches de langue :

    [0] => d:\wwwroot\www-moodle1_8_2-php\moodledata/lang/
    [1] => D:\wwwroot\WWW-MOODLE1_8_2-PHP/lang/
    [2] => D:\wwwroot\WWW-MOODLE1_8_2-PHP/mod/scheduler/lang/

Le module arrive donc en dernier.

Stratégie d'implantation des langues : pour des raisons de modularité et de maintenance, nous DEVONS favoriser une implantation locale des fichiers de langue. Le grand problème de Moodle dans les années à venir sera probablement la maîtrise de sa complexification et des offres divergentes, voire contradictoires de fonctionnalités.

Par exemple, au même moment où nous essayons de résoudre le problème de la mise à jour du scheduler, Kenneth Newquisk travaille également sur une reprise du module. Mais pas forcément dans la même direction que nous. Ce n'est pas tant cette profusion d'initiative qui est problématique (j'ai proposé d'échanger nos codes pour voir si nous allions dans le même sens - probablement pas à priori), que de disposer d'une structure qui permette d'accepter ces alternatives facilement. Or seule une bonne modularité peut le garantir (vécu d'expérience). Tout ce qui peut donc favoriser "l'encapsulation" propre et complète d'une fonctionnalité à UN SEUL endroit est stratégique.    

A rough solution is changing something in the HtmlArea code itself :

in the file %%dirroot%%/lib/editor/htmlarea/htmlarea.php §731 shows something like :

        html += '<style type="text/css">\n' + editor.config.pageStyle + "td { border: 1px dotted gray; }</style>\n";

The purpose of this line is to apply some style rules to the internal frame, that would come from the editor.config.pageStyle parameter (didn't go further).

A straight way to do what you need is to add a regular style sheet call just here, adding the line :

        html += "<link rel=\"stylesheet\" href=\"<?php echo $CFG->wwwroot/<path to stylesheets in theme> ?>\" />\n";

Adding as many stylesheet calls as you need shoud shape the content nicely. Take care with the quote escaping. 

Remember that you cannot rely on "named styles", unless you edit the content turned to raw HTML (may not be exactly the way you want to have it used !?!), so your style sheet should shape only simple HTML elements.

(applying named styles is not a feature of HTMLArea, but there are other editors that do allow it).