Plugins FAQ

De MoodleDocs

¿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

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.