Oodles of Moodles

09MOD: Moodle Module Development - Adding Our Custom Code to the Module

2010-05-18T06:50:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

After the Module is setup and configured correctly, it's time to add our own logic. This is what we had been waiting for!

The bulk of our logic goes into three scripts in our module's directory:

view.php
lib.php
locallib.php

THE MODULE'S VIEW.PHP SCRIPT

This script handles the display of the activity once it is added to a course section. If we look at the code provided in the template, it already handles the following:

Determining the instance of the module for the current course
Entering the view as an the activity to the Moodle log
Displaying the Moodle header and footer

In essence, all we need to find is the marker where we can enter our own code. Let's open the view.php script and look for the following snippet:

/// Print the main part of the page



echo 'YOUR CODE GOES HERE';

Let's test it out by modifying it a little, and looking at the values of the Moodle $COURSE global. Modify the snippet above so it now looks like this:

/// Print the main part of the page



echo '<pre>';

var_dump( $COURSE );

echo '</pre>'

When we navigate to our course, and look at our activity, it now displays our variable dump:

Click Image to Zoom

THE MODULE'S LIB.PHP SCRIPT

The lib.php script serves two distinct functions:

1. It is where Moodle looks for a number of standard functions that SHOULD be implemented for every module:

Add Instance
Update Instance
Delete Instance
User Outline
User Complete
Recent Activity
Cron handler
Get Participants

Each of these sections will be linked to an article dedicated to implementing its specific functionality. This article will be updated as these articles become available.

2. A starting place for building our own custom variables and functions.

OUR OWN LOCALLIB.PHP SCRIPT

Although we could place our code inside the lib.php script, it is better to reserve lib.php for the Moodle handlers. It is a better practice to create our own locallib.php file, and place our functions within it.

Open up the editor, and create a new file called locallib.php in our module's root directory (,\mod\inyourface). Create the locallib.php file with the following contents:



<?php

/**

 * Returns the current course id

 *

 * @return int The Course Id

 */

function inyourface_getcourseid()

{

global $COURSE;

return $COURSE->id;

}

?>

Notice that the function is commented in the phpDoc format. That is a subject all to itself, and one we should dedicate to a completely separate tutorial.

Once the locallib.php file has been created, we can now reference it within our view.php script. Open view.php and modify its references on the very top of the script so it looks like this:



/**



* InYourFace Module Instance

*

* @author Leo Cunha 

* @version $Id: view.php,v 1.6.2.3 2009/04/17 22:06:25 skodak Exp $

* @package mod/inyourface

*/



require_once(dirname(dirname(dirname(__FILE__))).'/config.php');

require_once(dirname(__FILE__).'/lib.php');

require_once(dirname(__FILE__).'/locallib.php');

Now we can call our new function from view.php. Replace our original snippet - the one that displayed the $COURSES variable with the following code:



/// Print the main part of the page 





$courseid = inyourface_getcourseid();

echo 'We are editing course number '.$courseid.'<br />';

That's it - we now have added our first piece of custom code to the module. When we execute the module from the Moodle course, it now displays the course id:

Click Image to Zoom

08MOD: Moodle Module Development - Generate Upgrade snippet with XMLDB Editor

2010-05-13T22:50:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

During our initial setup of the Module we modified the install.xml file. We are now faced with a dillema - while modifying the module's form we introduced a new database column. This value is needed by the module's logic and needs to be saved to our inyourface table (mdl_inyourface if your installation uses the default table prefix).

To handle this new challenge, we have to set up our first module upgrade. We accomplish the upgrade by following a number of simple steps:

We generate XMLDB code that we use in our module's .\mod\inyourface\db\upgrade.php script
We paste the new code into the upgrade.php script
We update our .\mod\inyourface\version.php file
We run notifications from the Moodle admin menu

When we finish these steps, we can verify that our changes took effect by changing the Post Limit value in our module's form, and making sure that the change took place.

THE MOODLE XMLDB EDITOR

The XMLDB Editor is a nifty little tool that generates code we can use to update our module's database structure. The editor can read existing XMLDB files (like our install.xml file) and generate code in SQL, XML or PHP.

For our immediate need, we need to generate PHP code for use in our module upgrade.

We start by accessing the XMLDB Editor

Navigate to Moodle's Site Administration Menu and select Miscellaneous
Select XMLDB Editor

Click Image to Zoom

The editor opens to a Main View, listing all of the available XML files. We need to scroll down to the listing for our module, mod\inyourface/db and click on the entry's "Load" link. The page refreshes and enables the "Load" link, Yes - we click on it as soon as it becomes available!

Click Image to Zoom

After the Edit XML File page loads, we scroll down to the Tables section and find our table's "Edit" link This will open the module's XML file.

Click Image to Zoom

The Edit Table screen displays, where we can select to add a New Field:

Click Image to Zoom

From this screen we can enter the details of our new field, which will be of type integer:

Clicking on the "change" button saves our changes and returns us to the Edit Table screen, where we can select to view PHP Code. We need this snippet so we can set up our update.php script and initiate the version update.

Basically, we are using the XMLDB Editor to generate
the snippet of HTML code needed for the update.php file.

Once we have the snippet, we have all we need for this module upgrade.

So let's generate and fetch our snippet:

Click to Zoom Image

The PHP Code form defaults to the first field in the table, so we need to use the Select Field dropdown to pick our new field (postlimit). We then click on the "View" button:

Click Image to Zoom

We now have the piece of the puzzle we need to complete our first module upgrade!!!

Click Image to Zoom

The snippet generated by the editor is:



if ($result && $oldversion < XXXXXXXXXX) {

    /// Define field postlimit to be added to inyourface

    $table = new XMLDBTable('inyourface');

    $field = new XMLDBField('postlimit');

    $field->setAttributes(XMLDB_TYPE_INTEGER, '2', XMLDB_UNSIGNED, null, null, null, null, '1', 'timemodified');

    /// Launch add field postlimit

    $result = $result && add_field($table, $field);

}

Copy the code to your clipboard and open the .\mod\inyourface\db\upgrade.php file.

ABOUT MODULE MODULES VERSION NUMBERS:
Version numbers are based on the date of the change, followed
by a sequence number. The first update on a
given day is given sequence number 00.

For example, our upgrade is being completed
on May 14,2010 and it is the first and only update.
Our new version number is 2010051400.

Notice that we did not run a search and replace on the upgrade.php file. We will erase all of its contents and replace it with the following code:



<?php 

function xmldb_inyourface_upgrade($oldversion=0) {

    global $CFG, $THEME, $db;

    $result = true;

    if ($result && $oldversion < 2007040200) 

    {

        /// Define field postlimit to be added to inyourface

        $table = new XMLDBTable('inyourface');

        $field = new XMLDBField('postlimit');

        $field->setAttributes(XMLDB_TYPE_INTEGER, '2', XMLDB_UNSIGNED, null, null, null, null, '1', 'timemodified');

        /// Launch add field postlimit

        $result = $result && add_field($table, $field);

     }

     return $result;

}

?>

The upgrade.php script should have a snippet for every upgrade that we make. It is an additive process, so we need to make sure that we safeguard our upgrade snippets.

OK.. so now we have an upgrade script that updates our mdl_inyourface table by adding a new column called postlimit.

Looks like a lot of work to generate a
simple SQL statement

BUT - the cost of managing upgrades
in the future will be well worth it!!!

Before we can complete the upgrade . . .

We need to update our .\mod\inyouface\version.php file to force Moodle to recognize that an upgrade is required. When we are done, the version.php file should look like this:



<?php // $Id: version.php,v 1.5.2.2 2009/03/19 12:23:11 mudrd8mz Exp $



/**

* Code fragment to define the version of newmodule

* This fragment is called by moodle_needs_upgrading() and /admin/index.php

*

* @author Your Name <your@email.address>

* @version $Id: version.php,v 1.5.2.2 2009/03/19 12:23:11 mudrd8mz Exp $

* @package mod/newmodule

*/



/// $module->version = 2007040200; // The current module version (Date: YYYYMMDDXX)

$module->version = 2010051400; // The current module version (Date: YYYYMMDDXX)

$module->cron = 0; // Period for cron to check this module (secs)

?>

So far we have . . .

Used the XMLDB Editor to generate the code snippet to add a new column to our module table
Modified the upgrade.php script
Modified the version.php script

With these changes in place, we can navigate to the Moodle Site Administration Menu, and select the Notifications option. And VOILA! Our upgrade executes!!!

07MOD: Moodle Module Development - Testing the module's form

2010-05-13T12:33:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

We have just completed our changes to the module's form. This form is called when the user adds our activity to a Moodle course. Let's test the form, and make sure that it works correctly.

1. Let's navigate to a Moodle course

Click Image to Zoom

2. Add our activity to one of the course's topics or weeks.

In our case, I am adding it to the second week, where I also have a corresponding forum discussion that will use to feed our module.

Click Image to Zoom

3. Fill out our form

WOW - Notice how much cleaner the form looks since we made some slight modifications. And look - our custom block and dropdown list are both rendered!

Click Image to Zoom

4. Save and Display the Form

Click Image to Zoom

Now we have a working module form. Making a few changes to the module template and adding less than 10 lines of code has left us with a registered, functioning Moodle module.

If we look at the database, we notice that we have populated table mdl_inyourface with a row that ties our new entry to the course:

WAIT!

We just introduced a new variable to our module - postlimit. This is new data that was not part of our original installation. When the user saves our activity to a course, our new data element gets lost.

It's time to look at how Moodle module updaetes work. We will also need to take a detour and look at the Moodle XMLDB Editor.

Next Article in Series

06MOD: Moodle Module Development - The module's form

2010-05-13T08:47:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

Moodle follows a very specific pattern for activity modules:

User selects a course
User turns editing on
User selects a topic or week
User selects an activity to add

Once the activity has been selected from the dropdown box, the module's form is displayed. In our case, selection of the "Facebook Integration" activity calls the form described in the .\mod\inyourface\mod_form.php script.

In this post we will go over the purpose of the form, how to customize the form, and how to handle the pre/post processing of data in the form.

NOTE: During this exercise, we will also have to modify our
module's database structure. We will cover these steps in detail in a separate post.

We will start by examining our mod_form.php file. Bascially, it generates a new form that is based on the Moodle Form module (notice at the top of the file, it "extends moodleform_mod").

The form is divided into 3 basic sections:

1. GENERAL: Elements required for every activity type
2. CUSTOM: Elements required by our module
3. STANDARD: Elements that are common to all modules

These sections correlate to the following areas of the activity creation form (the form that comes up after the user chooses to add an activity to a course's section or topic):

Click Image to Zoom

For our module, we will create a single custom element. A simple drop down where the user can select the number of forum posts that the student can submit using our Module.

We will only concentrate on the custom section o four mod_form.php script. Open the file for editing and find the following section:



EDITING .\mod\inyouface\mod_form.php



//-------------------------------------------------------------------------------

/// Adding the rest of inyourface settings, spreeading all them into this fieldset

/// or adding more fieldsets ('header' elements) if needed for better logic

$mform->addElement('static', 'label1', 'inyourfacesetting1', 'Your inyourface fields go here. Replace me!');



$mform->addElement('header', 'inyourfacefieldset', get_string('inyourfacefieldset', 'inyourface'));

$mform->addElement('static', 'label2', 'inyourfacesetting2', 'Your inyourface fields go here. Replace me!');



//-------------------------------------------------------------------------------

We actually start by modifying the .\mod\inyourface\lang\en_utf8\inyourface.php file! We need to change the "inyourfacefieldset" variable. Open the file in your editor and change that variable to "Feed Options".

We will also add one more variable that we'll use as a label for our dropdown list.

The completed inyourface.php file will look like this when you are done, with our changes in red:



EDITING \lang\en_utf8\inyourface.php



<?php

    $string['inyourface'] = 'Facebook Integration';

    $string['modulename'] = 'Facebook Integration';

    $string['modulenameplural'] = 'Facebook Integration';

    $string['inyourfacefieldset'] = 'Feed Options';

    $string['inyourfaceintro'] = 'Post to Facebook Intro';

    $string['inyourfacename'] = 'Post to Facebook';

    $string['postlimit'] = 'Maximum Posts';

?>

We can now concentrate on the form itself. We start by commenting out the annoying labels - label1 and label2 that the NEWMODULE template uses as a place holder. Comment out these lines, so your mod_form.php custom block now looks like this:



EDITING .\mod\inyouface\mod_form.php



//-------------------------------------------------------------------------------

/// Adding the rest of inyourface settings, spreeading all them into this fieldset

/// or adding more fieldsets ('header' elements) if needed for better logic

/// $mform->addElement('static', 'label1', 'inyourfacesetting1', 'Your inyourface fields go here. Replace me!');



$mform->addElement('header', 'inyourfacefieldset', get_string('inyourfacefieldset', 'inyourface'));

/// $mform->addElement('static', 'label2', 'inyourfacesetting2', 'Your inyourface fields go here. Replace me!');



//-------------------------------------------------------------------------------

That leaves one active line of code in the block - the one that adds the header element to our block. We want to add our drop down list immediately below the header. When we are finished our custom block will look as follows:



EDITING .\mod\inyouface\mod_form.php



//-------------------------------------------------------------------------------

/// Adding the rest of inyourface settings, spreeading all them into this fieldset

/// or adding more fieldsets ('header' elements) if needed for better logic

/// $mform->addElement('static', 'label1', 'inyourfacesetting1', 'Your inyourface fields go here. Replace me!');



$mform->addElement('header', 'inyourfacefieldset', get_string('inyourfacefieldset', 'inyourface'));/// $mform->addElement('static', 'label2', 'inyourfacesetting2', 'Your inyourface fields go here. Replace me!');



$choices = array();

$choices[0] = 1;

$choices[1] = 2;

$choices[2] = 3;

$mform->addElement('select', 'postlimit', get_strin('postlimit','inyourface'), $choices);

WE CAN NOW CHECK THE EFFECT OF OUR CHANGES
TO THE MODULE'S FORM.

THAT'S COMING UP NEXT!

Next Article in Series

05MOD: Moodle Module Development - The module's language file

2010-05-13T05:32:00.001-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

When we first set our module up, we simply completed a series of search & replace for the the phrase "NEWMODULE" and replaced them with our Module's name. This is enough to get the Module registered, but it leaves a very ugly footprint in Moodle.

Our goal right now, is to start some cleanup of these references so the user interface of our Module starts to take shape.

1. UPDATE THE .\mod\inyourface\lang\en_utf8\inyourface.php FILE

Inside the Moodle interface, the text that is displayed during the addition of our activity is controlled by the language file. These string variables are contained in the module's language file. Any modifications we make will take effect immediately.

2. !!! IMPORTANT !!! MOVE THE .\mod\lang folder to the Moodle root directory (move it to .\lang).
If you browse through your Moodle's .\lang directory, you will notice that each module has its own language file.

Here is the contents of the inyourface.php file after a little clean-up.



<?php

    $string['inyourface'] = 'Facebook Integration';

    $string['modulename'] = 'Facebook Integration';

    $string['modulenameplural'] = 'Facebook Integration';

    $string['inyourfacefieldset'] = 'Custom Fields';

    $string['inyourfaceintro'] = 'Post to Facebook Intro';

    $string['inyourfacename'] = 'Post to Facebook';

?>

After making these changes, when you navigate to a course and enter edit mode, you will notice the following changes:

Add Activity Drop Down When Editing a Course:

Click Image to Zoom

The Module's Add Activity Form:

Click Image to Zoom

The Activity Breadcrumb Trail:

Click Image to Zoom

SMALL CHANGES, BIG BANG!

Next Article in Series

04MOD: Moodle Module Setup - Adding our Activity

2010-05-12T06:55:00.001-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

Now that we have a module that does absolutely nothing, let's add it to a course. This will give us some confidence on the plug-in architecture, and give us some visual cues on where we need to go as we beef up the module.

So. . .

Let us proceed and add our non-activity module to a course!!!! Hurrah!

Now that the module is installed, we can navigate to a course:

Click Image to Zoom

Once on the course page, ensure editing is turned on:

Click Image to Zoom

Pick one of the course weeks or topics and select our activity (inyourface) from the Activity drop down list:

Click Image to Zoom

Fill out our (currently very ugly and rather sparse) activity definition form and click on the "Save and Display" button:

Click Image to Zoom

You will now see our activity... with a disheartening message: "Your Code Goes Here"

Click Image to Zoom

Actually, that's the GOOD NEWS!

We can now get to work on our module.
It is registered, Moodle recognizes it as a valid plug-in
and we can add it to courses!!!

Next Article in Series

03MOD: Moodle Module Setup - Test Initial Changes to Template

2010-05-12T06:10:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

So far...

We have modified the files in the module template, replacing any references to NEWMODULE with our module's name.

It is now time to make sure we didn't miss any of the changes:

We rename the directory that has been holding our files (NEWMODULE) to our module's name (inyourface).
We copy the entire contents of our module to our Moodle .\mod directory

Click Image To Zoom

MOODLE NOTIFICATIONS

Now comes time for the dreaded Moodle Notification. After copying our module to the .\mod directory, log into the Moodle instance and navigate to the Administration menu, and . . .

Click on "Notifications"

Click Image To Zoom

We can verify the installation by navigating to Modules -> Activitiies -> Manage activities in the Moodle Site Administration menu:

If all of our changes were successful, we will see the following:

Click Image To Zoom

We can confirm that the module was installed correctly by navigating to Modules -> Activities -> Manage activities in the Moodle Site Administration menu:

Click Image To Zoom

CONGRATS!

We now have a properly registered Moodle Module
that does absolutely nothing!

But we will change that soon :)

Next Article In Series

02MOD: Moodle Module Setup - Replacing the Module Name

2010-05-12T05:25:00.001-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

After the install.xml file has been updated, it is time to update all references to NEWMODULE in the template, and replace them with our own module's name. In this case, we will replace all references to NEWMODULE to inyourface.

CHANGES TO FILES IN THE MODULE'S ROOT DIRECTORY

In all these cases, we will be searching for "newmodule" and replacing it with "inyourface"

1. Edit index.php: For the Moodle 1.9 template, this file contains 23 references to the module name. A simple search & replace takes care of it.

2. Edit lib.php: Just like the index.php, a simple search & replace does the trick. There are 49 references to the module name in this file.

3. Edit mod_form.php: Same as above. Lather, rinse, repeat. There are 16 references to replace.

4, Edit view.php: There are 22 references to replace in this file.

CHANGES TO FILES IN THE .\lang\en_utf8 DIRECTORY

1. Rename file newmodule.php: This file should be renamed so it matches our module's name. In this case, I renamed it to inyourface.php

2. Edit the contents of the newly renamed file: Inside of the language file, all references to newmodule must be replaced with our module's name. There are 9 references to the module, but the variable $string['[MODULE]name'] should be replaced with whatever we would like Moodle to display to the end user. In our case, I have changed it to "Post to Facebook"

We are almost there. One more change . . .

CHANGES IN THE .\lang\en_utf8\help DIRECTORY

1. Rename the newmodule directory: Immediately below the \help directory, there is a single directory named newmodule. It needs to be renamed to our module's name. In our case, I renamed it to inyourface.

This directory will eventually hold all of the help files for our module. More on that later.

We are now ready to see whether our Module will be recognized by Moodle. Right now it doesn't do much of anything, but we'll beef it up once we are sure that we have made all of the right edits to the template

NEXT ARTICLE IN SERIES

01MOD: Moodle Module Setup - The install.xml file

2010-05-11T10:18:00.000-07:00

TO START THE TUTORIAL FROM THE BEGINNING, CLICK HERE

We have just finished upacking our Moodle Module Template!

If we inspect the contents of our new directory, it's really not very assuming:

FIRST ORDER OF BUSINESS - MAKE THE PLUG-IN PLUGGABLE!

STEP 1 - the install.xml file
A plug-in is only a plug-in if we have "plugged it in". In Moodle, we accomplish this by registering the Module in the Moodle database. Towards this end, we focus on a single file in the package - the install.xml file.

It is located in the .\NEWMODULE\db\ directory.

So, I load it up in my trusty Notepad++ (here's a gratuitous plug for this great GPL editor: Notepad++ Home Page) and notice that install.xml is nothing but an XMLDB file. The file should something like this when you load it into your editor:

Click Image To Zoom

THE MODULE'S XMLDB FILE CAN BE EDITED USING MOODLE'S XMLDB EDITOR

This is the preferred method, and is covered in the post listed below. The editor is available after the module has been copied to the Moodle .\mod directory, so instructions for modifying the file manually are also provided below.

To learn a little about the XMLDB editor, VISIT THE XMLDB EDITOR ARTICLE.

TO EDIT THE XMLDB FILE MANUALLY:

I run a search & replace for the word "newmodule" and replace it with my module's name: inyourface. For version 1.9, it should result in 12 replacements.

We can also change the comments in the file, but we will save that for later. Before we can test our module, we still have a little more work to do!!! We will cover these steps in the next post.

CONTENTS OF install.xml after changes:

<?xml version="1.0" encoding="UTF-8" >

<XMLDB PATH="mod/inyourface/db" VERSION="20070401" COMMENT="XMLDB file for Moodle mod/inyourface"

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:noNamespaceSchemaLocation="../../../lib/xmldb/xmldb.xsd"

>

<TABLES>

<TABLE NAME="inyourface" COMMENT="Default comment for inyourface, please edit me">

<FIELDS>

<FIELD NAME="id" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" SEQUENCE="true" ENUM="false" NEXT="course"/>

<FIELD NAME="course" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" COMMENT="Course inyourface activity belongs to" PREVIOUS="id" NEXT="name"/>

<FIELD NAME="name" TYPE="char" LENGTH="255" NOTNULL="true" SEQUENCE="false" ENUM="false" COMMENT="name field for moodle instances" PREVIOUS="course" NEXT="intro"/>

<FIELD NAME="intro" TYPE="text" LENGTH="medium" NOTNULL="false" SEQUENCE="false" ENUM="false" COMMENT="General introduction of the inyourface activity" PREVIOUS="name" NEXT="introformat"/>

<FIELD NAME="introformat" TYPE="int" LENGTH="4" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" COMMENT="Format of the intro field (MOODLE, HTML, MARKDOWN...)" PREVIOUS="intro" NEXT="timecreated"/>

<FIELD NAME="timecreated" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" PREVIOUS="introformat" NEXT="timemodified"/>

<FIELD NAME="timemodified" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" PREVIOUS="timecreated"/>

</FIELDS>

<KEYS>

<KEY NAME="primary" TYPE="primary" FIELDS="id" />

</KEYS>

<INDEXES>

<INDEX NAME="course" UNIQUE="false" FIELDS="course"/>

</INDEXES>

</TABLE>

</TABLES>

<STATEMENTS>

<STATEMENT NAME="insert log_display" TYPE="insert" TABLE="log_display" COMMENT="Initial insert of records on table log_display. Each record describes how data will be showed by log reports.">

<SENTENCES>

<SENTENCE TEXT="(module, action, mtable, field) VALUES ('inyourface', 'add', 'inyourface', 'name')" />

<SENTENCE TEXT="(module, action, mtable, field) VALUES ('inyourface', 'update', 'inyourface', 'name')" />

<SENTENCE TEXT="(module, action, mtable, field) VALUES ('inyourface', 'view', 'inyourface', 'name')" />

</SENTENCES>

</STATEMENT>

</STATEMENTS>

</XMLDB>

NEXT ARTICLE IN SERIES

00MOD: Developing Moodle Modules

2010-05-11T08:52:00.000-07:00

One of the challenges in Moodle development is finding a good starting point for creating a Moodle plug-in. I thought it would be cool to build a step-wise tutorial on the subject as I embark on a personal whim:

Building a Moodle Module that allows the Student to post their Moodle Forum posts to FaceBook, and elicits responses from their group of friends into a totally separate forum. Perhaps too ambitious for a first project, but it hits all of the major challenges.

I will start by coming up with a cool name for the plug-in. I am thinking of calling it InYourFace ? This particular exercise will focus on building an activity module - a module that provides an activity that can be added to any Moodle course.

WHERE DO WE START?

NOTE: This tutorial assumes that you already have a working installation of Moodle 1.9.x available, and that you have at least one course installed in your Moodle instance. It also assumes that you have some basic knowledge of PHP and MySQL.

Before we embark on writing our first Moodle module, let's download a template provided by the folks at Moodle.org. In our case, we will be writing our module for Moodle version 1.9.x:

Download Link for The Module Template for Moodle 1.9

We end up with a file called NEWMODULE.zip which we need to save to our local drive and unzip. In my case, I download to the Public folder, unzip the file and end up with .\Public\NEWMODULE.

NEXT ARTICLE IN SERIES