El blog de Javier Aranda

Normalmente estamos acostumbrados a instalar el software necesario para nuestro desarrollo web (servidor web, servidor de bases de datos…) en nuestra máquina de trabajo para probar en modo local que la aplicación que estamos generando funcione tal y como nosotros deseamos. Esto, que por una parte es perfectamente válido y puede ser útil a la mayoría de desarrolladores, presenta algunas desventajas: cada vez que iniciamos el sistema se inician una serie de servicios que puede no sernos útiles en todo momento (por ejemplo si usamos la máquina para consultar el correo o ver una película) y que ocupan cpu y memoria del sistema, y que nuestro sistema de trabajo puede no ser el mismo sobre el cual correrá finalmente la aplicación (por ejemplo, una aplicación desarrollada bajo Windows para ser ejecutada bajo un servidor Linux).

Para evitar eso propongo utilizar VirtualBox (software que permite correr una instancia de un sistema operativo dentro de otro), sobre el cual ejecutaremos el sistema operativo que deseemos como servidor (o sobre el cual finalmente vaya a implementarse las aplicaciones). En el caso de este artículo voy a utilizar Ubuntu Server 10.04 LTS virtualizado sobre un Ubuntu Desktop 9.10 que es el que uso como entorno de desarrollo (y de uso diario también), pero podría darse el caso de virtualizar una distro de Linux sobre un entorno de desarrollo Windows por ejemplo. Veamos como hacer esto.

Esquema general

Nuestro entorno de desarrollo va a quedar de la siguiente forma:

Por un lado tenemos una instancia de un sistema operativo que actuará como servidor (y que a partir de ahora para abreviar me referiré a ella como servidor a secas) sobre el cual instalaremos todo el software necesario para su funcionamiento: servidor web, servidor de bases de datos, servidor de correo, intérprete de scripts, etc. Esta instancia funcionará gracias a VirtualBox. Debe además simular el entorno sobre el cual finalmente correrá nuestro desarrollo, de esta forma nos aseguramos que realmente funcionará sin problemas una vez pase a producción. En esta instancia sólo se ejecutan los distintos servicios, y no se almacenan los archivos de la aplicación.

Por otro lado tenemos nuestro entorno de trabajo (sistema huésped o el sistema actualmente instalado en nuestro equipo). Es aquí dónde se encuentra nuestro editor de código favorito, los distintos navegadores para probar la aplicación y lo más importante, todo el código fuente de la misma. ¿Por qué es esto así? Debido a la constante actualización de un archivo de código, si este tiene que ser subido al servidor (nuestra instancia bajo VirtualBox) cada vez que se modifica, resulta muy poco práctico todo este invento. Para evitar esto, nuestro código permanece en nuestro sistema principal y mediante el uso de las carpetas compartidas que permite VirtualBox, el servidor podrá leer los archivos para servirlos.

Preparando el servidor

Lógicamente para poder ejecutar la instancia del servidor vamos a necesitar dos cosas: la primera es tener correctamente instalado VirtualBox en nuestro equipo y la segunda disponer de una imagen con el sistema operativo a instalar. Tras ello deberemos proceder a instalar dicho sistema en VirtualBox pero esta tarea es algo que se sale fuera del objetivo de este artículo. Para ello San Google siempre tiene la respuesta, aunque aquí dejo dos enlaces interesantes en el caso que el sistema huésped sea Ubuntu: enlace 1 y enlace 2. Una vez instalado, arrancada la máquina virtual y ya cargado el sistema operativo, nos aparecerá una ventana como esta:

Tras iniciar sesión en el sistema con el usuario y la contraseña proporcionados durante el proceso de instalación, tendremos a nuestra disposición la típica consola Linux, sobre la cual vamos a realizar unas operaciones. En primer lugar vamos a instalar un servidor ssh, para que de esta forma podamos acceder a administrar vía consola nuestro servidor sin necesidad de usar la interfaz de VirtualBox (podemos tenerla así minimizada). Quizás esto no sea del todo importante, pues realmente si alguna vez necesitáramos ejecutar algún comando en nuestro servidor (aparte de los iniciales para instalar los servicios que usaremos) podríamos hacerlo directamente desde esta interfaz, pero dado que cuando nos encontremos ante un entorno de producción real administraremos nuestro servidor de forma remota, aquí haremos lo mismo para habituarse a ello.

Para instalar el demonio de ssh en nuestro servidor escribiremos en la consola que nos aparece en la ventana de nuestra máquina virtual:

sudo apt-get install openssh-server

Y el gestor de paquetes del sistema empezará a descargar e instalar el demonio sshd. Una vez finalizado este proceso en teoría ya podríamos acceder de forma remota al servidor, y digo en teoría porque nos encontramos con el primer problema: ¿qué dirección IP tiene nuestra máquina virtual? Sin dirección IP no podemos conectarnos a ningún servidor a no ser que sea nuestro propio ordenador que nos conectamos como localhost. Pero nuestro ordenador tampoco es, pues estamos trabajando con una máquina virtual. El procedimiento para permitir esto es bastante simple: se trata de establecer una traducción entre los puertos de la máquina virtual y los de la nuestra física. Dicho con otras palabras, establezco una regla en VirtualBox que permita escuchar en un puerto de mi SO actual (por ejemplo el puerto 2222) e internamente VirtualBox pasa todo el contenido a otro puerto dentro de la máquina virtual (por ejemplo el 22, que es el puerto por defecto de ssh). Estas acciones desafortunadamente no se pueden hacer con la interfaz gráfica de VirtualBox, así que tendremos que hacerlo desde la consola. Abrimos una terminal en nuestro pc y escribimos:

VBoxManage setextradata "Ubuntu Server 10.04" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" TCP
VBoxManage setextradata "Ubuntu Server 10.04" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" 22
VBoxManage setextradata "Ubuntu Server 10.04" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" 2222

Mediante esas reglas de configuración de VirtualBox le hemos dicho: para la máquina virtual de nombre Ubuntu Server 10.04 crea una regla de nombre ssh que para el protocolo TCP, VirtualBox se ponga a escuchar por el puerto 2222 de la máquina huésped y reenvíe la información al puerto 22 de la máquina virtual. Es importante mencionar que esas reglas deben aplicarse con máquina virtual apagada. Si quieres una explicación algo más detallada, consulta este artículo.

Solamente queda una cosa por hacer: cambiar la tarjeta de red que VirtualBox simula en la máquina virtual. Para ello, en la ventana principal de VirtualBox, seleccionamos la máquina virtual de nuestro servidor y pulsamos sobre el botón Configuración. En la nueva ventana que nos aparece, en la parte de la izquierda, seleccionamos Red, y en la parte de la derecha desplegamos la pestaña Avanzadas y en el cuadro desplegable llamado Tipo de Adaptador, escogemos PCnet-PCI II (Am79C970A) y pulsamos sobre Aceptar. Esto es necesario por que hemos configurado las reglas para el dispositivo de tipo pcnet. Una vez realizado este paso, iniciamos nuestra máquina virtual y cuando en la interfaz nos aparezca el texto de bienvenida y la opción de introducir login y password ya tendremos activo el servidor. Cabe mencionar que para que nuestro servidor funcione no es necesario iniciar sesión en él, eso sólo lo haremos cuando necesitemos instalar o configurar algún servicio.

Para comprobar que todo funcione correctamente, abrimos una terminal en nuestro equipo y escribimos:

ssh -p 2222 usuario@localhost

Dónde usuario es el usuario que hemos configurado cuando se instaló el servidor. Nos pedirá la contraseña y una vez escrita estaremos dentro del servidor si todo el proceso ha ido bien. Cada vez que necesitemos entrar al servidor lo haremos de esta forma, de la misma manera que lo haríamos si estuviéramos trabajando con un servidor remoto.

Configurando las carpetas compartidas

Esta útil opción de VirtualBox nos va a permitir disponer de los archivos fuente de nuestra aplicación en nuestro sistema huésped, siendo la máquina virtual la que los lee de nuestro sistema para servirlos. De esta forma, cada vez que nosotros o un servicio acceda por ejemplo a la carpeta /home/www en nuestro servidor, estará accediendo realmente por ejemplo a la carpeta /home/usuario/desarrollo de nuestra máquina local, que es dónde tenemos todos los archivos fuentes de la aplicación. Es muy parecido a la traducción de puertos que hacíamos anteriormente.

Para realizar esto necesitamos primero instalar en nuestro Ubuntu Server las llamadas Guest Additions. Este procedimiento es algo que se sale del objetivo de este artículo, pero recomiendo leer este artículo que es con el que he aprendido yo en dónde viene todo claramente explicado. Una vez realizado esto debemos configurar las carpetas compartidas en VirtualBox. Esto es algo que también se sale fuera del objetivo de este artículo, por lo que recomiendo la lectura de este artículo en dónde se explica claramente. Lo único a tener en cuenta es que los nombres y las carpetas que usaremos en este artículo difieren de los que se dan en el artículo recomendado. Para evitar confusiones, las equivalencias son las siguientes:

Forma: en nuestro tutorial -> en el tutorial recomendado

Directorio real dónde se encuentra el código fuente: /home/usuario/desarrollo -> /…/Compartida con Virtual Box

Nombre que le damos para compartir: www -> Compartida

Directorio de la máquina virtual dónde se montará la carpeta: /home/www -> /media/compartida

Una vez tengamos configurada las carpetas compartidas y verifiquemos que funciona correctamente tenemos que realizar una configuración adicional que no se especifica en el mencionado tutorial. Tal y como está explicado en él, cada vez que iniciemos la máquina virtual tenemos que ejecutar el comando mount para montar la carpeta compartida. Esto resulta totalmente impráctico, por lo que a continuación vamos a ver la forma de que el sistema realice esto de forma automática por nosotros cada vez que se inicie.

Entramos mediante ssh en nuestro servidor de la forma que hemos visto anteriormente y escribimos en la terminal:

sudo nano /etc/fstab

Y se nos abrirá el editor de consola nano con el contenido del archivo fstab. Este archivo contiene las particiones y los puntos de montaje del sistema que se efectuarán al inicio. Nos vamos al final del todo e insertamos la siguiente línea:

www /home/www vboxsf rw,exec,uid=1000,gid=1000,dev 0 0

Lo más relevante es: www (el nombre que le hemos dado en VirtualBox para compartir), /home/www (el punto de montaje de la carpeta compartida), rw (permisos de lectura y escritura), uid=1000,gid=1000 (la carpeta se montará como si fuese una carpeta creada por ese usuario y ese grupo. 1000 el por defecto el ID del primer usuario y grupo que se crea en el sistema). De esta forma, cada vez que en el servidor accedamos a /home/www estaremos accediendo a /home/usuario/desarrollo de nuestro sistema local.

Con esto ya tendríamos todo preparado para usar nuestro entorno de desarrollo. Cada vez que necesitemos disponer de los servicios (web, bbdd, etc) iniciaremos la máquina virtual y listo. Para evitarnos tener que hacerlo desde la interfaz de VirtualBox podemos crear algún acceso directo en el escritorio para que pulsando en él se inicie o se pare la máquina virtual, ahorrándonos también que se muestre la interfaz gráfica del propio Ubuntu Server. Para ello, creamos dos accesos directos (iniciar y parar respectivamente) y en el comando a ejecutar escribimos:

VBoxHeadless --startvm "Aquí el nombre de la máquina" -vrdp=off
VBoxManage controlvm "Aquí el nombre de la máquina" poweroff

En mi caso he buscado en /usr/share/icons algún icono con un botón rojo y otro verde para asociarselo a los accesos directos.

Para completar los archivos necesarios dentro del directorio db, en esta entrada aprenderemos a especificar las capacidades del módulo y el archivo de actualización por si el módulo que instalamos fuese una versión superior a una que ya existiese.

Definiendo las capacidades

Moodle posee un sistema de capacidades, una especie de sistema de permisos que nos permitirán definir acciones y decidir qué usuarios pueden ejecutarlas. Esto nos resultará especialmente útil para definir acciones de administración o que sólo deban ser ejecutadas por un role de usuario (alumno, profesor, administrador, etc). Estas accionen deben definirse en un archivo llamado access.php que se encuentra bajo el directorio db. Cuando instalamos el módulo, moodle lee este archivo y copia su información en la base de datos, por lo que si lo modificamos, tendremos que aumentar el valor de la versión del módulo (esto lo veremos más adelante) para que moodle vuelva a leerlo y almacenar sus nuevos valores. Veamos su estructura:

access.php

$mod_modsms_capabilities = array(

    //capacidad de enviar mensajes en el tablon
    'mod/modsms:participate' => array(

        'riskbitmask' => RISK_SPAM,

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'student' => CAP_ALLOW
        )
    ),

    //capacidad de administrar el tablón
    'mod/modsms:manage' => array(

        'riskbitmask' => RISK_SPAM,

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    )
);

Como podemos observar en el código anterior, la variable ($mod_modsms_capabilities) incluye el nombre del módulo para diferenciarla de la que pueda existir en otros módulos. Internamente, está formada por un array de tantos elementos como capacidades queramos definir, en la forma nombre_de_la_capacidad => array_de_configuración_de_esa_capacidad. Entre esas configuraciones, caben destacar:

captype: tipo de la capacidad. El valor write indica que la capacidad será usada para la entrada de datos o el cambio de cosas. El valor read por contra se usa para la salida de datos, para mostrar cosas.

legacy: este elemento es a su vez un array que permite indicar que tipo de role posee autorización para realizar la acción indicada en la capacidad.

Para más información sobre las capacidades se puede consultar la documentación oficial en inglés:

• http://docs.moodle.org/en/Development:NEWMODULE_Adding_capabilities
• http://docs.moodle.org/en/Development:Roles
• http://docs.moodle.org/en/Development:Hardening_new_Roles_system

Viendo el código podemos observar que se han definido dos capacidades: la de enviar mensajes al tablón y la de administrarlo. Para la primera, que es de tipo escritura (ya que el usuario envía datos), sólo autorizamos a que sea el usuario cuyo rol es estudiante a que pueda escribir mensajes. En la segunda, de tipo escritura, los roles que pueden hacer uso de esta capacidad son los de profesor (ambos tipos) y administrador. Se podría haber definido un tercer rol de tipo lectura con la capacidad de leer los mensajes, pero como los mensajes pueden ser vistos por cualquier tipo de usuario, no se ha considerado.

Actualizando versiones anteriores del módulo

Si nuestro módulo no es de nueva creación sino que se trata de una versión posterior, es posible que necesitemos realizar actualizaciones en la base de datos existente (ya que al existir una en el sistema no se sobreescriben los datos con el contenido del archivo install.xml visto en entradas anteriores) al necesitar esta nueva versión de campos adicionales por ejemplo. La forma de realizar esto es mediante el archivo upgrade.php que se encuentra también bajo el directorio db. Este archivo contiene en su interior una función llamada xmldb_nombremodulo_upgrade, la cual será invocada por moodle en la instalación del módulo y pasándole como parámetro la versión del módulo instalado actualmente.

upgrade.php

function xmldb_modsms_upgrade($oldversion=0)
{
    global $CFG, $THEME, $db;

    $result = true;

    /*
    And upgrade begins here. For each one, you'll need one
    block of code similar to the next one. Please, delete
    this comment lines once this file start handling proper
    upgrade code.

    if ($result && $oldversion < YYYYMMDD00) { //New version in version.php
        $result = result of "/lib/ddllib.php" function calls
    }
    */

    return $result;
}

Es en esta función donde deberemos implementar las diferentes consultas a la base de datos para transformar los datos antiguos al nuevo formato. En nuestro caso, al ser la primera versión del módulo, no la necesitamos, por lo que devolvemos true indicando que todo ha salido correctamente.

La versión del módulo y otros datos de interés

En los apartados anteriores vimos que resulta necesario para ciertas operaciones conocer el número de versión del módulo instalado actualmente. La forma que tiene moodle de saberlo es mediante el contenido del archivo version.php situado en la raíz del módulo. El contenido del archivo es el siguiente:

version.php

//versión del módulo
$module->version  = 2009101200;

//versión de moodle mínima para instalarse
$module->requires = 2007101509;

//tiempo cada cual debe ser llamada la función de cron del módulo
$module->cron     = 0;

La primera de ellas le indica a moodle la versión de este módulo. La segunda indica la versión mínima de moodle sobre la que corre este módulo. Las versiones siguen la forma AAAAMMDDXY.YY siendo YYYYMMDD la fecha de lanzamiento de la rama (1.9 en el caso de la versión de moodle), X número de release 1.9.[0,1,2,3...] e Y.YY pequeños incrementos de las versiones entre releases. El último parámetro nos permite establecer cada cuanto tiempo moodle debe llamar a la función de cron que se encuentra dentro de lib.php como veremos en futuras entregas de este tutorial. Si se pone a cero nunca se llamará a la función (por que no nos haga falta en nuestro módulo).

Tras un periodo de exámenes, continúo escribiendo este tutorial.

Descripción de modsms

Como ya se ha comentado en entradas anteriores, vamos a realizar un módulo de actividad muy sencillo llamado modsms que nos permitirá tratar todos los aspectos básicos a tener en cuenta a la hora de desarrollar nuestro módulo. Este módulo hará uso de una base de datos para almacenar una serie de mensajes breves escritos por los alumnos (como un chat aunque sin una actualización en tiempo real) que responden a una pregunta del profesor. El diseño relacional de la base de datos queda de la siguiente forma:

Esquema Entidad-Relación modSMS

De color azul tenemos las tablas creadas por este módulo, y de color rosa las ya existentes en moodle pero que son referenciadas desde las nuestras.

Definición de las tablas: db/install.xml

El primer archivo que vamos a crear en nuestro módulo es el archivo de definición de las tablas que se usarán en nuestro módulo y que se crearán cuando lo activemos/instalemos. Este archivo es necesario crearlo aunque no usemos en nuestro módulo nada de las bases de datos, pero, como veremos más adelante, siempre resulta necesario crear una tabla con el nombre de nuestro módulo donde se almacenarán las distintas instancias de nuestro módulo en los cursos.

Este archivo contiene una definición de las tablas en un formato XMLDB modificado por moodle a su manera, por lo que si usamos algún editor existente que soporte ese xml deberemos prestar atención a los cambios. Para facilitarnos esa tarea, el propio moodle lleva incorporado un editor web que es el que usaremos para crear el esquema. Para ello, crearemos la estructura inicial del módulo creando la carpeta modsms bajo raiz-de-moodle/mood, dentro de ella la carpeta db y dentro de esta un archivo de texto llamado install.xml.

El primer paso es dotar de contenido a este archivo con una estructura básica para que el editor de moodle pueda reconocerlo y editarlo:

Como puede observarse, el xml consta de dos partes: la definición de tablas (tables) y la definición de consultas (statements). Por ahora nos olvidaremos de esta última parte y nos centraremos en la primera, la cual define la tabla principal del módulo (modsms) con un único campo (id) que identifica cada instancia de nuestro módulo de forma única.

Ahora entramos como administrador en moodle y en el menú de administración seleccionamos Miscelánea > XMLDB Editor. Una vez estemos en la página, buscamos la línea mod/modsms/db y pulsamos sobre Load, lo cual cargará nuestro archivo xml para su edición. Una vez cargado, en la misma línea tendremos activada la opción de editar (Edit), y pulsando sobre ella accederemos a la interfaz de edición del xmldb.

Vista de la interfaz de edición de XMLDB

Creando la estructura de las tablas

Como puede apreciarse en la página de edición, disponemos ya de una tabla creada, llamada modsms, que se corresponde con la única tabla obligatoria para un módulo de actividad en moodle. En esta tabla se creará un registro/fila/tupla por cada una de las instancias de nuestra actividad en cualquier curso de todo moodle. Y… ¿qué es una instancia? Pues es simplemente una actividad que insertamos en algún curso, que se diferencia de otras instancias de la misma actividad por un número de identificación único que se guarda en la tabla como el campo id. Esta tabla debe contener obligatoriamente tres campos: id, course y name, que identifican de forma unica cada instancia, hace referencia al curso donde está y el nombre que tiene, respectivamente. Para editar la tabla solamente pulsaremos sobre el enlace [Edit] que se encuentra junto al nombre de la tabla bajo la sección Tables.

Como se observa, la tabla ya contiene el campo id mencionado anteriormente. Ahora es el turno de añadir los demás campos que necesitamos en base al diseño realizado arriba. Para añadir un nuevo campo, sólo hay que pulsar sobre [New Field] y rellenar los datos del campo en la siguiente página. En el caso del campo course, el formulario lucirá el siguiente aspecto:

Editando el campo course

Repetiremos este proceso hasta completar todos los campos de la tabla. Es importante que todos los campos tengan la restricción de no nulo (NOT NULL), ya que ninguno debe ser nulo para el correcto funcionamiento del módulo. Una vez creados todos los campos, el siguiente paso es aplicar las restricciones y las relaciones a los campos que lo requieran. En esta tabla, deberemos reflejar que el campo course es una clave foránea (hace referencia a) del campo id en la tabla course. Para informar de esto a la base de datos, pulsamos sobre [New Key] y rellenamos los datos:

Editando las restricciones de clave foranea

Usando el enlace [Back] volvemos hacia atrás hasta llegar a la página que muestra la lista de tablas creadas (solo hay una por el momento). Si pulsamos sobre el enlace [New Table] nos mostrará la interfaz de creación de tablas dónde sólo hay que darle un nombre y el comentario es opcional, y la aplicación se encargará de crear el campo identificativo por defecto (id). En este paso creamos la tabla de nombre modsms_messages donde guardar los mensajes escritos por los alumnos. Y repetimos los pasos anteriores para dotar de contenido a esta nueva tabla.

Guardando el nuevo archivo

Por razones que desconozco, pese a contar el archivo con permisos 777 en linux, resulta imposible guardarlo desde moodle con la opción [Save] que aparece junto a la ruta en la lista de archivos editables de la interfaz de edición de xmldb. Por ello, la única manera de guardar los cambios es, estando en la interfaz de edición, pulsar sobre [View Edited] con el botón derecho del ratón y darle a Guardar como…, sustituyendo el antiguo archivo por este nuevo.

Cuando todo esté terminado, el contenido del archivo install.xml debe ser muy parecido a este:

Nota sobre los nombres de tablas y campos

En moodle, el nombre de la tabla principal de un módulo debe llamarse igual que este, y las demás tablas que necesitemos deben empezar por el nombre del módulo. En nuestro caso, el módulo se llama modsms, su tabla principal modsms y la otra que necesitamos modsms_messages.

Si en una tabla hacemos referencia al campo de otra tabla, este campo deberá llamarse de la forma nombredelatablanombredelcampo. Así, para hacer referencia al campo id de la tabla user, en nuestra tabla modsms_messages hemos creado un campo llamado userid.

Todos estos requerimientos pueden consultarse en la documentación en inglés sobre las bases de datos en moodle.

Estructura de archivos de un módulo

Para que moodle reconozca nuestro módulo de actividad este debe seguir una estructura de archivos (algunos necesarios y otros opcionales). Para ello, a partir de este momento vamos a considerar que nuestro módulo de prueba va a llamarse “modsms“. Por tanto la estructura sería:

• / – raíz de moodle.
• /mod – carpeta de módulos.
  • /modsms – carpeta raíz de nuestro módulo. Aquí dentro irán todos nuestros archivos y carpetas.
    • /db – carpeta con datos a introducir en la base de datos durante la instalación/actualización del módulo.
      • /access.php – contiene las capacidades/permisos del módulo.
      • /install.xml – esquema de la base de datos en xmldb para la instalación del módulo.
      • /upgrade.php – procedimientos de actualización del módulo.
    • /icon.gif – icono de la actividad que se muestra en el curso (entre otros sitios).
    • /index.php – muestra la lista de instancias de actividades de nuestro módulo que hay en el curso.
    • /lib.php – funciones requeridas por moodle para comunicarse con nuestro módulo.
    • /locallib.php – funciones propias que necesitemos para nuestro módulo.
    • /mod_form.php – formulario de configuración de la actividad al ser creada o editada.
    • /version.php – información sobre versiones relacionadas con el módulo.
    • /view.php – página de inicio de la actividad (cuando entra en la actividad un alumno por ejemplo).
    • /styles.php – definición de estilos css para nuestro módulo.
    • /backuplib.php – funciones para realizar la copia de seguridad del módulo.
    • /restorelib.php – funciones para realizar el restablecimiento de una copia de seguridad del módulo.
    • /lang – directorio de idiomas
      • /es_es_utf8 – directorio de idioma correspondiente al español de España versión UTF8.
        • /modsms.php – archivo con las cadenas usadas en el módulo en el idioma de arriba.
          • /help – carpeta con los archivos de ayuda.
            • /modsms – ayuda de este módulo.
              • index.html – índice con enlaces a los demás archivos de ayuda de este módulo.
              • mods.html – información general de nuestro módulo.
              • miayuda5.html – archivo de ayuda propio con ayuda sobre algo de nuestro módulo.
    • /miarchivo.php – también podemos crear tantos archivos (páginas) como necesitemos.

Los archivos en negrita son los archivos “obligatorios” que deberemos tener en nuestro módulo, siendo el resto opcionales.

Referencias básicas a la hora de desarrollar un módulo

Dado que como comentábamos en la anterior entrega de este tutorial la documentación de moodle es bastante escasa, cuando estemos desarrollando nuestro módulo o mirando cómo están hechos los otros (algo muy recomendable por otra parte) nos encontraremos con funciones que no sabemos qué hacen o que parámetros se le pueden pasar. Para ello moodle posee dos webs donde tiene subido la documentación generada por phpDocumentor y PHPXref que nos van a ser muy útiles para lo anterior:

• Moodle phpDocs
• Moodle PHPXref

Una vez conocida la estructura de archivos de los módulos, en la siguiente entrega comenzaremos de lleno a programar nuestro módulo modsms.