Normalement, XMLDB Editor ne sert qu'à créer le fichier install.xml que tu trouves dans le répertoire db des plugins.
Il te permet egalement comme tu as pu le voir, de générer la séquence ce PHP qui va bien dans le fichier upgrade.
Au tout début d'un bloc, il ne faut rien mettre dans upgrade.php, et laisser l'installation du bloc se faire toute seule par les notifications du menu Administration.
Une fois la première installation faite, tu peux générer les différences et corrections par l'upgrade, mais tant que le bloc n'est pas publié, cela reste à déconseiller. Le fichier upgrade.php est surtout utile pour mettre à jour des sites qui ont installé ton bloc. Tant qu'il reste expérimental, il n'y en a pas.
L'upgrade sera activé chaque fois que tu augmenteras la valeur de version de ton bloc. Il est donc tout à fait inutile de changer la version du bloc s'il n'y a ni changement de la base de données, ni changement des capacités ou définitions d'événements à enrgistrer dans Moodle. Cependant, certains développeurs augmentent tout de même ce numéro de version pour mieux gérer les demandes d'assistance (plutôt que de fouiller le code du demandeur pour savoir le code de quel jour c'était !!).
En général, les blocs ne produisent pas de table dans XMLDB, car l'existance des blocs est marquée par un enreigstrement générique dans "mdl_block_instance".
Ce n'est pas vrai pour les modules qui ont besoin d'une table nouvelle pour chaque module.
Continue à poser des questions aussi pertinentes, ça sera un plaisir que de te guider... et fera de la matière pour les prochains candidats développeurs !!
Valery Fremaux
Forumindlæg af Valery Fremaux
Variable à examiner pour savoir ce qu"on a sous la main :
$CFG
$SITE
$THEME
$USER
(donne déjà plein de choses à manger, toutes globales).
T'inquiète pas, ça va venir....
En tout cas continue à poser des questions bien ciblées comme ça et on va pouvoir te répondre illico !!
Pour l'examen du contexte, du disposes d'une variable globale $COURSE qui contient beaucoup d'informations sur le "cours" courant.
Tu est, hosmis des pages très externes (certaines pages d'Admin), plus ou moins toujours dans un cours.
Pour la page d'acceuil : $COURSE->id == SITEID
Il existe aussi un id standard pour MyMoodle. (c'est un faux cours), visualise (print_object) ta variable $COURSE dans la page /my/index .php et tu verras.
Pour que ton bloc puisse donner accès à des pages "annexes", il vaut mieux en effet mettre ces pages dans le répertoire blocks/monbloc pour en faire ce qu'on appelle un "sideapp" (ou application "à côté" de Moodle). Ceci n'empêche pas de pouvoir récupérer et utiliser TOUT le contexte moodle.
Ce n'est en général pas le rôle des blocs que de faire çà (plutôt destinés à produire une petite "vue de données" encartables dans le portail), mais j'avoie que c'est une technique la plus utilisable pour amener une "sideapp" comme un plugin et non comme une modification centrale du code.
Donc revenons à la structure de base de ta page : appview.php par exemple, dans ton répertoire blocks/monbloc
Le canevas standard est :
/**
* Requires and includes
*/
require('../../config.php'); // super important évidemment !!
// TOUT CE DONT TU AS BESOIN ICI **/
$id = required_param('id', PARAM_INT); // en général l'id du cours contexte ce qui permet de le donner à require_login()
$course = get_record('course', 'id', "$id"); // pas sûr que ça serve, on a $COURSE
/// Capability trap
// s'assurer de l'accès et de l'enrollement
require_login($course->id);
// logguer dans le journal
add_to_log($course->id, 'osia_sessions', "$view/$action", "manageall.php?id=$course->id", "$course->id");
// attraper le contexte courant, une alternative est d'obtenir le contexte de niveau "bloc"
$context = get_context_instance(CONTEXT_COURSE, $COURSE->id);
if (!has_capability('block/monbloc:macapcite', $context)){
error("Je vérifie encore quelques accès !!");
}
// je fabrique une navigation
$navlinks[] = array(
'name' => get_string('managingsession', 'block_osia_session'),
'url' => NULL,
'type' => 'title',
);
// j'imprime le header standard
print_header_simple(get_string('managingsessions', 'block_osia_session'), get_string('managesessions', 'block_osia_session'), build_navigation($navlinks));
// JE METS MON CODE A MOI //
// queqlues variantes de sortie, avec ou sans paramètre -> http://phpdocs.moodle.org
print_footer();
Good luck !!
Cheers.
Hi All, I've found a silly bug that was resulting in same effect :
The fix is :
in lib/blockslib.php
function blocks_get_by_page($page) {
$blocks = get_records_select('block_instance', "pageid = '". $page->get_id() .
"' AND pagetype = '". $page->get_type() ."'", 'position, weight');
$positions = $page->blocks_get_positions();
$arr = array();
foreach($positions as $key => $position) {
$arr[$position] = array();
}
if(empty($blocks)) {
return $arr;
}
foreach($blocks as $block) {
// very important fix. Fixes lost blocks in flexipage and front page format
// renumbers the duplicate weights in order...
while (array_key_exists($block->weight, $arr[$block->position])){
$block->weight++;
update_record('block_instance', $block);
}
$arr[$block->position][$block->weight] = $block;
}
return $arr;
}
Maybe it has something to do with the error you're experimenting. It fixed all weird behaviour definitively in our instances. I'll seek for a tracker entry... may help.
Problem is that some block moves do not calculate correctly the weight of the landing block, and weight duplicates appear in database. This fix recalculates dynamically the weights of the blocks in the page so they are in correct order, and no one is forgotten. Beware : you may have some ghosts reviving !!
Cheers.
Si j'ai à peu près compris la question, il doit s'agir de la fonction get_content() qui génère un objet $this->content avec deux sous attributs texte :
$this->content->text
et
$this->content->footer
Il faut retourner cet objet à la fin :
return $this->content
C'est ce qui est affiché à la place où le bloc est inséré.
(PS. Nicolas, peux-tu déplacer ce thread en Développement de Moodle). Thanks.