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);