Plugins FAQ

¿Qué es un plugin (del inglés plugin)?

Un plugin (traducido como extensión [sic] en el Español internacional), que previamente se conocía como un complemento (add-on), o código contribuído, es código que le permite a Usted añadir características y funcionalidad adicionales a Moodle.

Varios plugins están incluidos dentro de la descarga estándar de Moodle. Se pueden obtener plugins adicionales desde el directorio de plugins de Moodle.

¿Cómo instalo un plugin?

Vea Instalar plugins para conocer las instrucciones. Algunos contribuyentes, pero no todos, incluyen un archivo Read me (Léame) con instrucciones dentro de su paquete del plugin.

En una instalación típica, Usted probablemente copiará algunos archivos PHP en una o más áreas del código de su sitio Moodle y después hara click en el enlace hacia la Administración del sitio llamado "Notificaciones", para iniciar el proceso de instalación

¿Cómo aplico un parche?

Vea :dev:How to apply a patch.

¿Porqué mi plugin recientemente instalado no aparece en la lista de plugins?

Primeramente, revise que Usted haya visitado la página de administración de http://su_sitio_moodle.org/admin/index.php para completar la instalación. Después, revise que haya descomprimido el archivo ZIP dentro de la carpeta correcta con el nombre correcto, y que la carpeta del nuevo plugin no esté contenida dentro de otra carpeta.

¿Cómo puedo yo contribuir código a Moodle?

I. INTRO. ARQUITECTURA Moodle

Moodle se presenta como una aplicación web de naturaleza pedagógica. Se trata de una LMS para compartir conocimiento utilizándolo como una potente herramienta para el aprendizaje a través de internet. On line. Moodle como toda LMS, Learning Management System, Sistema de Gestión del Aprendizaje, presenta a nivel técnico una arquitectura basada en 3 pilares fundamentales.

1) Base de datos Por regla general MySQL o MaríaDB. Recoge los datos de usuarios, cursos, calificaciones, etc, y mediante consultas se articulan los contenidos que son visualizados.

2) Moodledata Almacena, por razones de seguridad, de manera encriptada, todos los archivos y documentos que se incorporan a la LMS y que tienen una naturaleza pedagógica. Imágenes, PDF, Scorms, etc. También almacena, por razones de optimización, cadenas de literales de idiomas y la memoria caché.

3) HTML, htdocs Nos referimos a los archivos físicos que forman parte de la estructura material de Moodle y que son los que podemos ver en nuestro browser, al acceder a la aplicación. Cuando vamos a un curso, generamos un informe, participamos en un foro, etc. La gran mayoría son archivos PHP, aunque también encontramos entre otros HTML, JS, CSS, XML, ordenados en carpetas. Estos archivos son los que vemos cuando navegamos. Por ejemplo mod/chat/view.php.

Si abrimos el archivo config.php de nuestra instalación de Moodle, en la raíz principal, podremos entenderlo perfectamente. Por ejemplo.

$CFG->dbtype = 'mariadb'; $CFG->dblibrary = 'native'; $CFG->dbhost = 'localhost'; $CFG->dbname = '3_6'; $CFG->dbuser = 'root'; $CFG->dbpass = 'A.3j230359px'; $CFG->prefix = 'mdl_'; // database $CFG->wwwroot = 'http://127.0.0.1/3_6'; // html $CFG->dataroot = 'C:\\xampp\\moodledata_3_6'; // moodledata

Aunque todos estos tres elementos están interrelacionados, en nuestro desarrollo haremos uso específico del tercer espacio. Lo que vamos a llamar los archivos html.

1. ¿Cómo se organiza Moodle?

Recordamos que esta solución libre tiene una filosofía modular. Esto quiere decir que Moodle está formado por extensiones o plugins. Un plugin se puede incorporar y desligarse de manera sencialla, sin que afecte al funcionamiento convencional del aplicativo. Cuando instalamos un entorno Moodle, ya incorpora unas extensiones por defecto. Chat, foros, tipos de preguntas, bloques, métodos de autenticación, temas y estilos, formatos de cursos, etc. De esta forma podemos ver dos ambientes bien diferenciados. Core y Extensiones, estás últimas pueden, como decimos, instalarse y desinstalarse sin que esto tenga impacto con nuestro Moodle.

https://moodle.org/plugins/

Es TOTALMENTE DESACONSEJABLE manipular archivos que formen parte del Core Moodle. En su caso haremos personalización en estas diferentes extensiones, o sobrescribiremos el Core refactorizando el theme, pero dejando intacto en todo caso el Core. En Administración del Sitio. Extensiones, podemos comprobar que tenemos instalado en nuestro Moodle.

Toda la información la tenemos además disponible en la Comunidad. https://docs.moodle.org/dev/Plugin_types

En este Curso vamos a afrontar el desarrollo de una extensión concreta, que pueda satisfacer nuestras necesidades. Un informe específico. La extensión o plugin que nos hace falta será un plugin tipo report. https://docs.moodle.org/dev/Reports

Las diferentes extensiones están ordenadas en sus correspondientes carpetas. Por ejemplo, estilos y colores dentro de la carpeta /theme. Los bloques en la carpeta /blocks. Los formatos de curso en /course/format, etc.

2. Frankenstyle

¿Es una palabra de broma? En absoluto, quizás se trate de un guiño. Nos referimos a la convención de nomenclatura que se utiliza para identificar de forma única un complemento de Moodle según el tipo de complemento y su nombre. Se utilizan en todo el código de Moodle (con una notable excepción como los nombres de clase css en los temas).

Martin Dougiamas, creador de la iniciativa Moodle inventó la palabra 'frankenstyle' para describir este sistema de nombres que inventó Petr Škoda Es imprescindible tener esto claro y hacer un correcto uso del mismo, en otro caso nuestra extensión no funcionará correctamente y podría originar problemas en el resto de la LMS. Por ejemplo, nuestro proyecto será el desarrollo de una extensión report. Lo primero que tendremos que hacer es ponerle un nombre. Nosotros vamos a llamarlo informe success. El Frankenstyle se forma mediante el prefijo tipo de plugin, guión bajo, nombre de nuestro plugin. En nuestro caso el Frankenstyle que tendremos que utilizar durante todo el desarrollo será.

report_success

El archivo version.php de nuestro plugin report será identificado así $plugin->component = 'report_success'; // Full name of the plugin (used for diagnostics)

3. Arquitectura de una extensión

Para ser posible la correcta instalación y desinstalación de un complemento, es preciso respetar una precisa arquitectura en los archivos y su identificación.

Quizás sea buena idea acceder a la carpeta html/report de una instalación Moodle y comprobar cómo se encuentran estructurados otras extensiones y utilizarlos como modelo para el desarrollo del nuestro, o bien podríamos descargarnos un plugin tipo report desde la Comunidad.

Los desarrollos se realizan en entornos previos de Desarrollo que luego son pasados a ambientes de Preproducción. En ningún caso directamente en sitios en Producción. Crearemos una carpeta a la que denominaremos success. El preciso nombre con el que hemos bautizado a nuestro plugin

1) Empezaremos con el archivo version.php que será el encargado de recoger las características de nuestra extensión para comprobar si es compatible o no con el Core de nuestro Moodle

Recuerda hacer uso de las buenas prácticas Moodle en la elaboración de tu código. Todas las páginas php deberían incluir en la cabecera esta información

<?php // This file is part of Moodle - http://moodle.org/ // // Moodle is free software: you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation, either version 3 of the License, or // (at your option) any later version. // // Moodle is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with Moodle. If not, see <http://www.gnu.org/licenses/>.

/**

* Version info
*
* This File contains information about the current version of report/logs
*
* @package    report_success     
* @copyright  1999 onwards Martin Dougiamas (http://dougiamas.com)
* @license    http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later

Es preciso identificar nuestra extensión haciendo uso del correspondiente Frankenstyle report_success

Nuestro archivo version.php incluirá además.

defined('MOODLE_INTERNAL') || die; // Avoid access to the information. Every internal file that doesn’t render

$plugin->version = 2018120300; // The current plugin version (Date: YYYYMMDDXX) $plugin->requires = 2018112800; // Requires this Moodle version $plugin->component = 'report_success'; // Full name of the plugin (used for diagnostics)

La versión requerida de Moodle es importante a la hora de afrontar versiones de PHP y clases y funciones empleadas en nuestra extensión y que pudieran ser incompatibles con las del Core Moodle.

2) Archivos complementarios

a) Literales

Nunca debemos escribir un texto directamente sobre los archivos. Hay que hacer uso de los diferentes paquetes de idioma a través del método get_string().

echo ‘My Success Report’; // avoid this way :( echo get_string('pluginname', 'report_success'); // :)

iguiendo la lógica, los literales se encuentran en la carpeta lang de nuestro plugin. Será el propio Moodle quien muestre el literal correcto de acuerdo con el paquete de idioma activo. Para ello crearemos una subcarpeta con la correspondiente identificación del idioma. Esto funciona de esta manera en todas las extensiones, no sólo en las de tipo report.

En este ejemplo tenemos literales en inglés y en español. El inglés se aplicará por defecto. Dentro de cada carpeta estará el php que contiene la traducción de los literales. Recuerda tiene que respetar el Frankenstyle. En nuestro plugin se llamará report_success.php Este será el archivo de idiomas del plugin.

/**

* Lang strings.
*
* Language strings to be used by report/successs
*
* @package    report_success
* @copyright  1999 onwards Martin Dougiamas  {@link http://moodle.com}
* @license    http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

$string['allsources'] = 'All sources'; $string['eventcomponent'] = 'Component'; $string['eventsuccessgedas'] = '{$a->realusername} as {$a->asusername}'; $string['pluginname'] = 'Success Report';

Vea Guidelines for contributed code.

¿Hay información acerca de cómo crear un nuevo plugin?

Si! Vea dev:Developer documentation. More coming soon!

Vea también

• Using Moodle General add-ons forum
• Moodle 2015 favorite plugins discusión en foro en idioma inglés por Gavin Henrick, con mucha información útiul sobre plugins de Moodle.

Para hacer referencia al literal haremos uso de las propias funciones Moodle, haciendo uso de nuevo del Frankenstyle

get_string('pluginname', 'report_success');

La salida que se mostrará en pantalla será la que nos indique report_success.php En el ejemplo. Success Report

Los literales arrastran un fuerte caché. Si aunque los modifiquemos no lo vemos actualizado en nuestro Moodle tendremos que utilizar la opción Purgar Cachés.

b) db

En esta carpeta encontramos un importante archivo.

access.php

Este es significativo para ver qué privilegios tienen los usuarios ante nuestro plugin. ¿Pueden ver los informes todos los alumnos? ¿Todos los profesores, sólo los matriculados en el curso? Por ejemplo, quién puede acceder al contenido de los datos de nuestro informe. Entramos en el ámbito de las capacidades. Capabilities.

defined('MOODLE_INTERNAL') || die();

$capabilities = array(

   'report/success:view' => array(
       'riskbitmask' => RISK_PERSONAL,
       'captype' => 'read',
       'contextlevel' => CONTEXT_COURSE,
       'archetypes' => array(
           'teacher' => CAP_ALLOW,
           'editingteacher' => CAP_ALLOW,
           'manager' => CAP_ALLOW
       ),

       'clonepermissionsfrom' => 'coursereport/success:view',
   ),

}

Esta capabilidad o privilegio es, en este caso, clonada. https://docs.moodle.org/dev/Access_API

3) lib.php

Este archivo recogerá funciones y métodos de nuestro plugin. El Core Moodle hace uso de ella de manera automática, por ello es preciso generar el archivo con este preciso nombre. Con independencia de que todavía no hayamos desarrollado ninguna función, es preciso que incorpore una, en otro caso, nuestro report podría generar un error cuando accedemos a un contexto de curso.

Eso ocurre porque en este contexto se muestran enlaces a los diferentes informes . Es tan fácil como extender el bloque de navegación con nuestro propio informe. Para ello, volvemos a hacer uso de nuestro Frankenstyle. Esto obedece a que en un origen había 2 tipos de reports, reports de sitio y reports de curso, coursereport. Desde la versión 2.1 se unificaron en report

function report_success_extend_navigation_course();

defined('MOODLE_INTERNAL') || die; // Avoid access to the information. Every internal file that doesn’t render

• This function extends the navigation with the report items

*
* @param navigation_node $navigation The navigation node to extend
* @param stdClass $course The course to object for the report
* @param stdClass $context The context of the course
*/

function report_success_extend_navigation_course($navigation, $course, $context) {

   if (has_capability('report/artic:view', $context)) {
       $url = new moodle_url('/report/success/index.php', array('id'=>$course->id));
       $navigation->add(get_string('pluginname', 'report_success'), $url, navigation_node::TYPE_SETTING, null, null, new pix_icon('i/report', ));
   }

}

Pues con todo esto sólo tenemos una pregunta. ¿No crees que va siendo hora de empezar,  :) ?

II. report_success

Recordemos los objetivos que nos hemos propuesto siguiendo los pasos de manera detenida de acuerdo con los principios de la ingeniería del desarrollo del software.

Nuestra Organización plantea una necesidad. Precisa conocer los datos de los alumnos de nuestros Cursos Online, en particular el tiempo de conexión y si ha participado o no en algún foro, como elemento que justifique su participación e implicación en la formación e interacción con profesores y otros alumnos.

Esta utilidad no la encontramos en una instalación de Moodle convencional, ni tampoco en las numerosas extensiones de la Comunidad. https://moodle.org/plugins/?q=report

Decidimos desarrollar una utilidad que pueda automatizar esta tarea. Tenemos claro unos principios. No debemos alterar el core Moodle, de manera que al tratarse de una extensión tipo informe, resolvemos que lo más lógico sería utilizar una extensión tipo report.

A nivel técnico lo podríamos resolver así.

Necesidad en mi Organización Informes Peronalizados por Curso Instalación como extensión report_success

Aterrizándolo, tendremos que presentar la información. La primera vista a la que accederemos será html/report/success/index.php Será preciso hacer unas indicaciones en este archivo.

1. Importaciones require('../../config.php'); require_once($CFG->dirroot.'/report/success/lib.php');

require_login();

El config.php de nuestro Sitio nos permite accede a las APIS Moodle y gran mayoría de funciones y métodos. La otra será la llamada a nuestra librería, la de nuestra extensión donde incorporaremos las clases, funciones y métodos que podamos utilizar.

https://docs.moodle.org/dev/Core_APIs

Tras esta importación sería preciso obligar al acceso sólo a usuarios que se encuentren debidamente registrados en el sistema. El tema no es baladí, se tratan de datos sensibles que no podemos dejar con acceso público, donde pudiésemos incluso cometer alguna infracción legal. A nivel técnico lo resolvemos con require_login(); que obliga a estar dado de alta en el Sistema para poder ver la página

2. Recogida de parámetros

Si la url arrastrara algún parámetro, por ejemplo, id=3, es necesario su recogida. Por motivos de seguridad, inyección de código malicioso en la url, está totalmente desaconsejado hacerlo mediante las sentencias PHP $_GET["id"] o en su caso $_POST["id"]

Demos hacer uso de la metodología Moodle. Indicando si el parámetro es opcional o no, el tipo y en su caso el valor por defecto.

$id = optional_param('id', 0, PARAM_INT);// Course ID. $modid = optional_param('modid', 0, PARAM_ALPHANUMEXT); // Module id or 'site_errors'. $modaction = optional_param('modaction', , PARAM_ALPHAEXT); // An action as recorded in the module

3. Set Page

Es conveniente el seteo de toda vista en Moodle a través de la variable global $PAGE.

$PAGE->set_url('/report/success/index.php', array('id' => $id)); $PAGE->set_pagelayout('report'); // type of view

$PAGE->set_title(get_string('pluginname', 'report_success')); $PAGE->set_heading(userdate(time()));

// $output = $PAGE->get_renderer('report_success'); // own renderer

l plugin permite incluso la renderización personalizada a través del método del objeto $PAGE->get_renderer(); Cómo es obvio indicamos como parámetro nuestro Frankenstyle. Para ello, dentro de la carpeta classes podríamos incluir dos archivos

1) renderer.php Hereda la clase plugin_render_base para sobrescribir la vista

class report_log_renderer extends plugin_renderer_base { }

2) renderable.php Contiene la clase que implementa la renderable y que escribe los métodos que puede ser utilizados por renderer.php

class report_succes_renderable implements renderable { }

En nuestro report_success, no vamos a hacer uso de esta opción. Por eso no haremos la llamada a $PAGE $PAGE->get_renderer('report_success');

4. Privilegios

¿Quién está autorizado a ver mi report? No es suficiente con que el usuario esté logueado. ¿Puede un simple alumno ver los datos de nuestros informes?

Recordamos que Moodle opera mediante contextos. Un curso es un contexto, un determinado informe otro, un foro tiene otro contexto. En cada contexto cada rol posee unas determinadas capacidades. En otras palabras, qué puede hacer cada rol en cada usuario. ¿Ven la misma información un profesor que un alumno? Vamos a indicarlo en nuestro index.php https://docs.moodle.org/37/en/Context

$context = context_system::instance(); // it is a context system $PAGE->set_context($context);

require_capability('report/success:view', $context); Recuerda que esta capabilidad report/success:view ha sido definida previamente en db/access.php

5. Render

Vamos a renderizar la página de manera convencional. Ofrecerla en la pantalla. echo $OUTPUT->header(); echo $OUTPUT->heading(get_string('choosesuccesss');

/* report_success code

• /

echo $OUTPUT->footer();

Hasta ahora tenemos un plugin que podríamos instalar y desinstalar en nuestro Moodle, cuyo acceso también estaría debidamente restringido. Pero nuestro objetivo es que report_success nos dé información sobre datos de los cursos. Para ello lo primero que vamos a hacer es mostrar todos los cursos de la LMS con su correspondiente enlace a otro archivo php, que será donde se mostrará el informe.

En la medida de lo posible evitaremos hacer abuso de las consultas a la base de datos. Es más recomendables utilizar funciones y métodos Moodle que podemos encontrar en sus diversas librerías y que han sido optimizados. Podemos obtener el mismo array de todos los cursos que se encuentran en nuestro Moodle, bien mediante un método ya programado en Moodle, bien mediante una consulta directa. Es preferible lo primero.

$mycourses = get_courses(); // better way :) $mycourses = $DB->get_records_sql('SELECT * FROM {course} WHERE id > 1 ORDER BY category DESC');

En todo caso optimice su consulta y utilice siempre la Data API, a la que puede acceder simplemente importando el config.php de su sitio Moodle. https://docs.moodle.org/dev/Data_manipulation_API

Vamos a visualizar la información. En una tabla. Utilizamos para ello la propia API Moodle y la clase table. No es necesario recordar que deberíamos hacer uso de la API OUTPUT evitando en la medida de lo posible el uso de simple echo en el PHP y el uso directo de div y otros elementos HTML.

$table = new html_table(); $table->head = array(get_string('course', 'report_success'), get_string('fullname', 'report_success'), get_string('visible', 'report_success')); foreach ($mycourses as $mycourse) {

 if ($mycourse->id > 1) { // courseid = 1 is System
     $myurl = html_writer::link(new moodle_url('/report/successs/successs',     ['id' => $mycourse->id]), $mycourse->fullname);

$table->data[] = array( ' '.$myurl, $mycourse->shortname, $mycourse->visible);;

   }

echo html_writer::start_tag('div', array('class' => 'myclass')); echo html_writer::table($table); echo html_writer::end_tag('div');

7. Vista tiempo de acceso de Usuarios por curso

En nuestra solución cada enlace monta una dirección incorporando la id del curso de referencia, que deberemos recoger en el archivo success.php. No hay ningún convencionalismo en utilizar este nombre, success.php, para el archivo. Podíamos haber elegido otro cualquiera.

                report/successs/successs.php?id=2

index.php id = 2 success.php

Eso es precisamente lo que vamos a hacer. Generamos success.php, dentro de la carpeta report/success

Recordamos que es preciso incorporar el código en la cabecera que ya desarrollamos en index.php. Es importante recibir la variable int del id del curso, en este ejemplo, 2. En este caso el parámetro es requerido, no opcional, pues de otra manera no podríamos identificar el curso. $id = required_param 'id', PARAM_INT);// Course ID.

Seteo de la página, indicando el nombre del nuevo archivo $PAGE->set_url('/report/success/susccess.php', array('id' => $id));

El contexto debería ser diferente, porque hace referencia a un curso en específico. Es decir, ¿queremos que un profesor no matriculado en ese curso pueda acceder a estos datos? En este sentido exigimos capacidad en contexto curso, es decir, profesores matriculados. También hacemos una comprobación del id recepcionado, por si este es correcto y corresponde a un curso.

if (!$course = $DB->get_record('course', array('id'=>$id))) {

   print_error('invalidcourse');

} $context = context_course::instance($course->id); require_capability('report/success:view', $context);

Ahora plantamos nuestra necesidad que pretende ser resuelta por el report_success

Comencemos las tareas.

a) Obtener los usuarios por curso.

Háganos uso del propio código Moodle que nos ofrece estos datos y así evitamos generar nosotros mismos la query. $students = get_enrolled_users($context, $withcapability = , $groupid = 0, $userfields = 'u.*', $orderby = 'id', $limitfrom = 0, $limitnum = 5000);

b) Calcular el tiempo estimado de conexión a la Plataforma.

Se trata en todo caso de un tiempo de conexión estimado basado en los clics realizados por el usuario y recogidos en los logs, en la tabla de datos correspondiente. Podemos hacer en este caso uso de la magnífica función desarrollada por nuestro Compañero Aday Talavera, y que podemos encontrar en la Comunidad. Nosotros la hemos retocado un tanto. Lo más coherente es que esta función se encuentre en un nuevo archivo, lib.php

Recuerda que debemos comentar correctamente el código, así como identificar las clases, métodos y funciones. Como supones, aquí también es conveniente hacer uso del Frankensyle. Delante del nombre de la function es preciso indicar report_success_

/**

• Returns the total sum of dedication time of the user to the system
• This function returns a estimated dedication time which is configurable by appreciated times between registered logs
• This function has been developed & updated thereupon Blocks:Course dedication lib @author Aday Talavera
• @param int $u userid
• @param int $c courseid to get access time in course otherwise returns access time in system
• @param optional int $limit seconds between logs access otherwise 7200 seconds
• @param optional int $f return in timestamp or human readable format
• @param optional int $iss time in seconds to ignore session, otherwise 59 seconds
• @return dedication time */

function report_success_getmytime($u, $c = 0, $limit = 7200, $f = 1, $iss = 59) { … }

La función nos exige al menos dos parámetros. Courseid, y userid. Tenemos ambas variables en nuestra página php.

$id; // course id receipt by get foreach ($students as $mystudent) { $mystudent->id; // every user id, every row in the table }

Dentro del bucle por cada usuario obtenemos de esta manera, el tiempo de conexión, con la función que nos la calcula.

foreach ($students as $mystudent) { $connection = report_success_myusertime($mystudent->id, $id, $limit = 7200, $f = 1, $iss = 59); … }

Generaríamos una vista con la presentación de datos

$table = new html_table(); $table->head = array(get_string('id', 'report_success'), get_string('firstname', 'report_success'), get_string('lastname', 'report_success'), get_string('time', 'report_success')', get_string('ispost', 'report_success')); foreach ($students as $mystudent) { // every student $tconnection = report_success_myusertime($mystudent->id, $id, $limit = 7200, $f = 1, $iss = 59); // we get conection time of user in the course $ispost = report_success_ismypost($myforum, $mystudent->id); // we get if the user has posted in any post of the course

      $table->data[] = array( ' '      .$mystudent->id, 
     $mystudent->firstname, 
     $mystudent->lastname,
     $tconnection,
     $ispost);

}

echo html_writer::start_tag('div', array('class' => 'myclass')); echo html_writer::table($table); echo html_writer::end_tag('div');

Podemos enriquecer la vista incorporando un botón que nos vuelva al panel de selección de cursos. echo $OUTPUT->continue_button(new moodle_url('/report/success/index.php',array('id'=>0)));

1) settings.php

En este archivo podemos configurar algunas utilidades para nuestro plugin. Por ejemplo puede sernos muy útil que aparezca el enlace en el menú de navegación. Esto lo conseguimos mediante $ADMIN. // Just a link to course report. $ADMIN->add('reports', new admin_externalpage('reportsuccess', get_string('pluginname', 'report_success'), $CFG->wwwroot . "/report/success/index.php?id=0", 'report/success:view'));

2) Estilos

Podemos incorporar nuestro propio css. Deberíamos denominarlo styles.css

En ese caso podemos hacer una llamada a este archivo. El mejor método es $PAGE->requires->css($CFG->wwwroot . "/report/success/style>);

Se recomienda en todo caso hacer uso de Templates a través del lenguaje Mustache. De esta manera el archivo, en nuestro ejemplo, success.mustache, estará, en nuestro plugin, dentro de la carpeta template.

A template is an alternative to writing blocks of HTML directly in javascript / php by concatenating strings. The end result is the same, but templates have a number of advantages:  It is easier to see the final result of the template because the code for a template is very close to what the final HTML will look like  Because the templating language is intentionally limited, it is hard to introduce complex logic into a template. This makes it far easier for a theme designer to override a template, without breaking the logic  Templates can be rendered from javascript. This allows ajax operations to re-render a portion of the page.

https://docs.moodle.org/dev/Templates

Para estas tareas puede sernos enormemente útil una extensión para algunos exploradores. MAGIC CSS, que nos ayudará a previsualizar los estilos en temas de diseño, complemento perfecto para el Inspector de Elementos.

3) Javascripts

Es posible la llamada a un .js e incluso a mensajes modales ADM, que incorpora la propia estructura de Moodle $PAGE->requires->js($js); $PAGE->requires->js_call_amd('frankenstyle_path/your_js_filename', 'init');

En el último caso necesitaremos crear la carpeta amd, y dentro 2 subcarpetas  build  src

Disponemos de la información en

https://docs.moodle.org/dev/Javascript_Modules

IV. BONA PRAXIS

Moodle es una gran Comunidad con miles de participantes. Es muy importante que a la hora de afrontar el desarrollo de nuestro código sigamos las pautas establecidas, para que cualquier otro compañero pueda también aprender y mejorar nuestros desarrollos.

Las reglas están en https://docs.moodle.org/dev/Coding_style

Otra excelente idea es hacer uso del plugin local CodeCheker soportado por los Compañeros Tim Hunt y Eloy Lafuente (que han aportado numerosísimas líneas al código de Moodle) Esta utilidad nos alertará del código que, pese a que pueda funcionar correctamente, no está redactado de la manera académica más conveniente https://moodle.org/plugins/local_codechecker

V. Compartir tu desarrollo

En tu desarrollo puedes hacer uso de una potente herramienta para controlar las versiones que es además open source. De esta forma es posible que puedas compartir tu código fuente, es decir que múltiples personas pueden trabajar en equipo, para que si así lo deseas, otros miembros de la Comunidad, puedan mejorarlo o introducir correcciones y depurar errores (issues)

Se trata de una plataforma de desarrollo colaborativo, o también llamada la red social de los desarrolladores donde se alojan los repositorios, el código se almacena de forma pública

https://guides.github.com/ Para evitar que varios desarrolladores puedan estar trabajando simultáneamente en un mismo archivo, desvitalizando el trabajo, este útil software nos permite mantener un adecuado control de las diferentes versiones.

V. ¿POR QUÉ NO AYUDAR A LA COMUNIDAD?

Una vez finalizado nuestro plugin y si creyésemos que pudiera ser útil para otros Compañeros, tal vez podríamos plantearnos subirlo a Moodle para que poder compartirlo con la Comunidad, si consideremos nuestro código bajo licencia copyleft.

Para ello es necesario registrar nuestro plugin. Lo podemos hacer en sencillos pasos. Nos dirigimos a

https://moodle.org/plugins/registerplugin.php

Lo primero es confirmar una declaración previa

I declare that I have checked the plugin contribution checklist. I believe my plugin fulfils all requirements and is ready to be reviewed and published in this plugin directory.

Posteriormente lo subimos a Moodle.org y lo dejamos a disposición de la Comunidad.