There are three reasons Moodle has become so important and much talked about in the world of online learning (refer to The Campus Computing Project at http://www.campuscomputing.net / new.html): one technical, one philosophical, and the third educational.

From a technical standpoint, Moodle--an acronym for Modular Object-Oriented Dynamic Learning Environment (Moodle)--is highly customizable. As a Moodle developer, always remember that the "M" in Moodle stands for modular. If you are faced with a client feature request that demands a feature Moodle doesn't support, don't panic. The answer is simple--we create a new custom plugin to implement it. Check out the Moodle plugins directory (https://moodle.org/plugins/) for a comprehensive library of supported third-party plugins that Moodle developers have created and given back to the community. This leads to the philosophical reason why Moodle dominates.

Moodle is, from a philosophical perspective, grounded firmly in a community-based, open source ethos (check out https://en.wikipedia.org/wiki/Open-source_model). However, what does this mean for us as developers? Fundamentally, it means that we have complete access to the source code, and within reason, unfettered access to the people who develop it. Access to the application itself is free--you don't need to pay to download it, and you don't need to pay to run it. However, be aware of what free means. Hosting and administration, for example, take time and resources are very unlikely to be free.

You will very often hear beer talked about in the context of free software (and I have purposefully stressed the word free): free software means free as in freedom, not free as in beer. Possibly, a better way of stating the case is to say that the Moodle developers in general--and Martin Dougiamas, the creator of Moodle, in particular--have given us freedom to do what we must. What we have not been granted is license to do what we want. Note that, again and like the beer example, this isn't quite the same as gratis (free of price) and libre (free of restriction--refer to https://en.wikipedia.org/wiki/Gratis_versus_libre). As Moodle developers, we are bound by the duties specified in the free Software Foundation's GPLv3 license (check out http://www.gnu.org/licenses/gpl-3.0.txt), and it is worth having an appreciation of these duties before you start developing.

Finally, as an educational tool, Moodle was developed to support social constructionism (refer to https://docs.moodle.org/31/en/Pedagogy); if you are not familiar with this concept, it is essentially suggesting that building an understanding of a concept or idea can be best achieved by interacting with a broad community. The impact on us as Moodle plugin developers is that there is a highly active group of users and developers. Before you begin developing any Moodle plugins, come and join us at https://moodle.org/mod/forum/?id=5.

As briefly described earlier, if we are faced with a need to enhance or alter the functionality of Moodle in some way, then the prescribed approach is to create a plugin. Refer to https://docs.moodle.org/dev/Moodle_architecture#Moodle_as_a_modular_system for a further description of Moodle's modular architecture. The https://docs.moodle.org/dev/Moodle_architecture page is also a good reference for learning about the basic plugin types and where these plugin types are to be found in the application folder structure.

In the following sections, we will set ourselves up ready to start developing our own plugins. First, we need to learn how to run a Moodle on our development computers.

Moodle is a web application; so, you will need a web server in order to run it. In this section, we will be configuring a local development server that can run on your local machine.

Moodle is a web application running typically (but not exclusively) in a web browser. A Moodle user interacts with a user interface on a client computer. The client requests resources from the application server (generally known as middleware) that provides the requested resources. It can do so by calling on another server, known as the data server. The data server provides the application server with the data it requires:

Check out https://en.wikipedia.org/wiki/LAMP_(software_bundle) for more information on the stack.

Generally, this architecture is referred to either as a WAMP stack or LAMP stack, the W or L referring to Windows or Linux, depending on the operating system you are running. A is for the web server Apache, M for the database server MySQL, and P for PHP, the scripting language Moodle is authored in. It should be noted that other web servers and databases are available and Moodle will run quite happily on them; refer to the online Moodle documentation.

Setting up an Internet ready Moodle server is beyond the scope of this book--see Moodle 3.0 Administration, also from Packt, for details. Instead, we will install a local web server running on Windows, using WampServer.

The WampServer development stack can be downloaded from http://www.wampserver.com/en/. Ensure that you download either the 32-bit or 64-bit version to suit your computer. Also, ensure that you run the install with Administrator privileges as both Apache and MySQL run as Windows services and the installer will require elevated privileges to install these. Once installed and running, the WampServer icon will be visible in the taskbar--green means everything is operating as it should and your local web server is up and running:

Do you use Skype on your development machine? If so, you will likely experience a configuration conflict between the Apache instance in WampServer and Skype as Apache attempts to use ports 80 (for HTTP) and 443 (for HTTPS) to display web pages. By default, Skype is configured to use both these ports as alternatives for data transfer, so you will need to reconfigure Skype accordingly:

1. Open Skype and click on the Tools menu option and slide down to Options....
2. Select Advanced and then click on Connection.
3. Uncheck the Use port 80 and 443 as alternatives for incoming connections option and press Save.
4. Restart Skype.

As discussed earlier, the Moodle application consists of a great number of text scripts that can, in practice as well as theory, be edited with any simple text editor. However, you will be far better off using an integrated development environment for your development. An IDE will contain tools for code completion and code insight; for example, if you have forgotten the name of a class method, or if you need quick access to a function declaration, or the instances where a variable is used.

Perhaps more importantly, IDEs contain integrated debugging tools that allow you to step through the code as it runs (more on this later). The examples in this book use a special PHP version of the Eclipse IDE called Eclipse PDT, which can be downloaded from http://www.eclipse.org/pdt/.

Once installed, there are a number of recommended configuration preferences to change, and these are outlined in the Moodle developer documentation at https://docs.moodle.org/dev/Setting_up_Eclipse#Setting_the_preferences_for_Moodle_development.

Once the development environment is configured, we need to consider how we will debug any code we write. For that, we need to set up and configure remote debugging, which we discuss next.

We will use the Chrome browser for development using the integrated JavaScript, CSS, and HTML debugging tools. To debug PHP scripts, we will need to install and configure a PHP remote debugger. The debugger we will use is called Xdebug--https://xdebug.org/index.php. Xdebug needs to be installed and configured in three places:

• The web server (Apache running our local development server)
• The development environment (Eclipse)
• The browser (Chrome)

The first step is to configure Xdebug in Apache. In order to determine which version of Xdebug is required, you will need to obtain a copy of the full output from phpinfo()--refer to http://php.net/manual/en/function.phpinfo.php--and paste that into https://xdebug.org/wizard.php, as follows:

Press the Analyse my phpinfo() output button at the bottom of the page for instructions on how to download and configure Xdebug.

Next, we need to configure Xdebug in the IDE. Instructions are available in the Eclipse documentation at https://wiki.eclipse.org/Debugging_using_XDebug.

Finally, we need to install an Xdebug plugin into the browser. For Chrome, we will be using Xdebug helper. Check out https://github.com/mac-cain13/xdebug-helper-for-chrome for details, but the helper itself is easily installed through the Chrome Web Store (you can find relevant links on the GitHub page).

Where should we install our development Moodle? It is always easier to debug an application that is running on the same (local) machine as your integrated development environment, although the PHP debugging tools described in this book also support remote debugging. If it's a separate development server (and not your local machine) you are working with, be sure to check out the guidance on how to configure remote debugging online as this can be tricky to set up. Each remote setup is different, so there is no definitive guide. The Eclipse forums are a great place to look for help, for example, http://www.eclipse.org/forums/index.php/mv/msg/365474/890896/#msg_890896.

The latest version of Moodle can be downloaded from https://download.moodle.org/. Download the latest version and unpack in the www directory created by WampServer. Before running the installation, you will need to follow the setting up instructions at https://docs.moodle.org/31/en/Windows_installation_using_XAMPP. Note that these instructions are for XAMPP, an alternative web server based on LAMP (https://www.apachefriends.org/download.html), but the principles of configuring Moodle running on WampServer are exactly the same. Before you install Moodle, ensure that the required PHP modules are installed and enabled (refer to https://docs.moodle.org/31/en/PHP for details) as failure to do so can result in you experiencing almost impossible to debug blank pages during the installation process.