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.

Now is the time to introduce the project we will be developing as we work through this book. The project brief is to develop a learning platform to promote research into societal and economic resilience. The Moodle instance we will be working on forms part of a much larger product landscape; so, it is vital that the Moodle we will be helping to develop integrates seamlessly into this landscape. Not only that, but there are features required of the e-learning platform itself that a vanilla Moodle doesn't support. For that, we will need to develop features to support learner management (one requirement is that authentication is via WordPress), course management (for example, access to materials based on your location), and novel teaching interactions (specifically, a three-dimensional model viewer). However, rather than presenting the details of the entire project at this early stage, we will be introducing features as they are required.

As a developer, don't be concerned purely with creating code. All the world's best designers, architects, builders, and planners have an appreciation and understanding of where they are coming from and where they are going; the art is knowing where to start and the science is in the planning and execution. In the rest of this section, we discuss the importance of planning.

Creating a new Moodle installation doesn't just involve configuring servers and installing software. That's just a very small part of the process. The most important part of the process is planning. Before you can plan, you have to understand the environment (that is, the people and the organization) that you are planning for. It is best to design your new server architecture in baby steps:

1. Audit the current environment, that is, your whole organization: How is your network configured? How will the new Moodle be accessed? How will the new Moodle interface with legacy systems? Will Moodle work at all?
2. Produce an options analysis: Designing a new architecture is a problem, not a puzzle (puzzles only have certain solutions whereas problems can have many solutions, some more effective than others). Each potential solution will have benefits and risks; these need to be understood.
3. Recommend a solution: The preceding two steps will make it clear why you have reached your particular recommendation.

Only when you reach an informed decision on which architecture you will implement, should you go ahead and implement it.

Obviously, how rigorous you need to be during the planning stage will depend on the organization you are planning for, still preparation is everything.

In this book, we will follow an Agile software development methodology. There is plenty of information available on the internet on Agile and the principles themselves are fairly straightforward to follow. The only aspect of Agile that you really need to be aware of is that client requirements will be described in terms of user stories, which are very different to the typical use cases you may be familiar with. At the requirements stage, we can treat Moodle plugins like little black boxes.

Essentially, the difference between use cases and user stories is this:

• A use case explains what a black box is meant to do
• A user story explains what a black box is meant to achieve

You will be encountering far more user stories as you read this book as our focus is on what can be achieved with new Moodle plugins rather than what they do and, of course, with what goes on inside the little black box--the software development.

Maintaining source code is impossible without some measure of version control. There are many version control systems available, but one of the most popular--and the one used by the Moodle community--is Git. Git is a Distributed Version Control System (DVCS), and it makes sense that the Moodle source code should be managed using some form of distributed system as Moodle's development community is scattered worldwide. The Moodle community uses GitHub--https://github.com. Delving into the details of how you use Git and GitHub are beyond the scope of this book. You are encouraged to read https://docs.moodle.org/dev/Git_for_developers before you start developing plugins properly. For more information on GitHub, check out GitHub Essentials, also from Packt (https://www.packtpub.com/application-development/github-essentials).

Essential to the creation of any new feature in Moodle is an understanding of Moodle's internal application programming interfaces. The oo in Moodle stands for object-oriented and at the outset, it is worth unpacking what this means to us as plugin developers.

Object orientation is all about treating features of a system as little interconnecting black boxes. We have no idea what goes on inside a black box, but each black box can be described in three ways:

• Each box behaves in a particular way and by making a box act out predefined, built-in behaviors, you can make it do different things
• At any moment, a box is in a particular state
• Every box has its own identity

Also, in fact, our little black boxes are objects and each object has a state, exhibits certain behaviors, and every object is uniquely identifiable as each has its own identity.

Objects themselves are of a particular type, called a class. Your pet cat shares some of the features of a mountain lion because they are both feline, and felines are types of mammals, so all mammals share similar characteristics, and so on. It is the same way with objects in Moodle:

If there is a specific programming task you need to perform in Moodle, you need to look for the correct API with which to carry out that task. Visit https://docs.moodle.org/dev/Core_APIs for a list of all of Moodle's internal APIs. For example, do you need to display a string on the screen? If so, use the String API. Why? It is because the String API automatically handles issues such as formatting and internationalization.

Each one of these APIs is accessed via an object. For example, use the global $DB object to access Moodle's database. This is an instance of the Data Manipulation Language (DML) API. Again and as with using the String API to display text on the screen, don't try to access the database other than through the interface Moodle provides. Why? It is because issues such as SQL injection hacks and verifying data integrity are already handled in the $DB object interface, so you don't have to worry about it.

However, what if there is a behavior that a particular interface doesn't support? This is solved by the notion of inheritance--see https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming). If, for example, the String API is missing a behavior our project requires, or we need to modify a behavior in order for it to fit our needs, we can declare a new class and base it on the String API. The new class is called a child class and the class upon which we have based the child is called the parent class. Certainly, in the case of the String API, we can reconfigure Moodle to use our new API. We will be learning how to modify an API (using the String API specifically) later in this chapter.

This section is merely a brief overview of the object-oriented philosophy, intended to be just enough of an explanation before you start Moodle plugin development. For more details on the object-oriented philosophy in general, check out the Wikipedia page on object-oriented Programming at https://en.wikipedia.org/wiki/Object-oriented_programming.

For a complete list of Moodle's core internal APIs, take a look at https://docs.moodle.org/dev/Core_APIs. The first set of APIs are listed as General APIs. They are the interfaces upon which most plugins are built, for example, the Data Manipulation API for reading and writing to the Moodle database or the Form API that displays web forms and handles their form data. In the next section, we will create a simple plugin that overrides (in the object-oriented sense) and calls on the String API to change the way language strings are displayed in Moodle's user interface.

The "Other General APIs", listed next, are the ones that are still fundamental and likely to be used in any type of plugin but, that said, are much less likely to be called upon, for example, the Calendar API or the Competency API.

Then, there are the APIs that are specific to certain plugin types, such as the Activity Completion and Plagiarism APIs, which will only be employed by a Moodle activity module.

As described earlier, we will be working together to develop plugins for a new global Moodle-based learning management system in this book. For the rest of this chapter, we will be working through the development of a simple plugin, one that modifies the way language strings are displayed on the user interface. Note that the intention isn't to demonstrate the finer details of how to write a Moodle plugin; that is the purpose of the rest of the book. The rest of this chapter is written to outline the kind of thought processes that one would engage in when being tasked with developing a new feature in Moodle. So, let's begin with finding out what the task that we have been set is.

In true agile fashion, the following user story has been assigned to us:

The client requires two languages to be displayed on the screen at the same time: English and Mandarin Chinese. Moodle supports language switching (refer to https://docs.moodle.org/31/en/Language_settings for details) but doesn't show two languages at the same time. Also, on the face of it, this seems a fairly straightforward problem. However, let's always ensure that we take a methodical approach to any request and avoid the temptation to simply start developing. By being disciplined, we can ensure that the plugin we develop is not only the most effective fit for this immediate requirement, but also that:

• It is future proof
• It is reusable
• It is ready, potentially, to be offered back to the development community (IPR issues not withstanding)

Let's spend the rest of this section learning about the development process. There are many well-defined development processes, and these will be explored in the rest of the book. The art, however, is knowing where to start, and we should always start by attempting to thoroughly understand the problem in every way.

It is, perhaps, a statement of the obvious, but before you start developing, ensure that you fully understand the problem you have been asked to solve. The standard journalist's questions are a good framework to aid your understanding. Consider the following:

• Who: Will the two languages be displayed to all users or only to certain users? In our case, all users.
• What: Are we talking about US English or UK English? Does the client want "Mandarin", which means mainland Chinese displayed using the simplified character set? Our client has specified UK English and simplified Chinese Mandarin.
• Why: Is this because our users are bilingual, or is this being included as a teaching aid? The client is wanting two languages on the screen simultaneously as they are expecting the platform to be used in group teaching.
• Where: Moodle language switching toggles the language on the platform only; it doesn't toggle languages in any teaching materials. This client wants both the platform and the courses to be bilingual.
• When: Are two languages to be displayed everywhere or only in particular contexts? Dual languages are to be displayed throughout the platform.

Also, having gained an understanding of the problem, it's time to consider the how.

Moodle already supports a range of languages through installable language packs, and for version 3.1, these are listed at https://download.moodle.org/langpack/3.1/. The language pack we need is zn_ch.zip, which is simplified Chinese Mandarin. Follow the instructions at https://docs.moodle.org/31/en/Language_packs to install this pack into your local development Moodle:

Having installed the relevant language pack, we can now experiment with creating a test Moodle user whose native language is simplified Chinese:

Having satisfied ourselves that we can switch to the Chinese language, we now need to assess options for displaying two languages on the screen at the same time. For that--and in the spirit of social constructivist learning in general--we need to go out into the world... Let's start with the main Moodle website at https://www.moodle.org.

Take a look at https://moodle.org/plugins and search for language:

Unfortunately, nothing is available to support dual language display in the plugins directory.

Martin Dougiamas created Moodle as a platform not only to support social constructivist teaching, but he also wanted to have development of the platform supported along social constructivist lines. So, the main Moodle website hosts a variety of forums where users and developers can openly discuss issues and address support-related and frequently asked questions. Visit https://moodle.org/course/ for a full list of forums (you will need to create a user account if you want to post any messages). The language forum itself is at https://moodle.org/mod/forum/view.php?id=43.

If you don't find anything relevant in the user forums, we can take a look at the Moodle Tracker next.

Detailed discussions on Moodle developments tend to take place in the Moodle Tracker at https://tracker.moodle.org/secure/Dashboard.jspa. A general search on string management has revealed a discussion on the ability to provide an alternate string manager; Tracker ticket ID MDL-49361 https://tracker.moodle.org/browse/MDL-49361:

For a detailed explanation of the String API, visit https://docs.moodle.org/dev/String_API. The String API documentation reveals that the most effective method of having Moodle display two language strings on the screen at the same time is to author our own string manager, within which we have implemented a custom get_string() function. Luckily, the reporter of ticket MDL-49361 has already created an example, Moodle plugin moodle-local_stringman, and made it available through GitHub (refer to the preceding section, Source control discipline):

You will see that the README notes for the moodle-local_stringman plugin stress that the code provided should be used for illustration purposes only. So, we will need to download a copy of the source and create our own GitHub repository to work on:

That done, it's time to work on our solution.

We will create a new local plugin. Essentially, local plugins are the place to put enhancements to core Moodle that don't fit into any other obvious place (that is, an enhancement that isn't a new course activity or a new user authentication method). We will learn much more about local plugins in Chapter 2, Moodle Plugins - What Can I plug In? I have called this new plugin duallang. This is publicly available on GitHub at https://github.com/iandavidwild/moodle-local_duallang.

Download the plugin from GitHib. Now, let's take a look at the structure of the duallang plugin together. There are three files worth mentioning:

• version.php: This contains not only the version information of the plugin itself but also the minimum version of Moodle required to run it. It also, optionally, contains a list of dependencies. The following is a copy of the relevant code from our new plugin:

      $plugin->component = 'local_duallang'; 
      $plugin->release = 'alpha1'; 
      $plugin->version = 2016112300; 
      $plugin->requires = 2015030900; 
      $plugin->maturity = MATURITY_ALPHA; 
      $plugin->dependencies = array(); 

• lang/en/local_duallang.php: This contains the plugin's language strings. There is only one language string required for this basic plugin and that is the name of the plugin itself:

      $string['pluginname'] = 'Dual language string manager'; 

• classes/duallang_string_manager.php: This script contains the overridden implementation of the core_string_manager class, specifically, the get_string() function, which has been modified to construct a language string from both the UK English and the simplified Chinese Mandarin language packs:

      class duallang_string_manager extends 
      \core_string_manager_standard { 

          /** 
          * Implementation of the get_string() method to display both 
          simplified 
          * Chinese and UK English simultaneously. 
          * 
          * @param string $identifier the identifier of the string to 
          search for 
          * @param string $component the component the string is 
          provided by 
          * @paramstring|object|array $a optional data placeholder 
          * @param string $langmoodle translation language, null means 
          use 
          * current 
          * @return string 
          */ 
          public function get_string($identifier, $component = '', $a = 
          null, 
          $lang = null) { 

              $string = parent::get_string($identifier, $component, $a, 
              'en'); 

              $zh_cn = parent::get_string($identifier, $component, $a, 
              'zh_cn'); 

              if(strlen($zh_cn) > 0) { 
                  $string .= ' | ' . $zh_cn; 
              } 

              return $string; 
          } 
      } 

Note that in order to specifically load UK English and simplified Chinese, we simply call the method in the parent class (refer to the An objected-oriented philosophy section for some elaboration on the parent/child class relationship).

At the top of each PHP script, you will find a general comment header, important copyright, and optional version control information. You will also see the following line of code:

defined('MOODLE_INTERNAL') || die(); 

This prevents someone from outside of Moodle from accessing the PHP script. To install the plugin, we can either copy the files to Moodle's local folder or use Moodle's built-in plugin installer (for details, visit https://docs.moodle.org/31/en/Installing_plugins#Installing_via_uploaded_ZIP_file):

Once installed, we will also need to add a line to Moodle's config.php file (located in Moodle's root directory):

Return to Moodle's home page and you will now see the UK English and simplified Chinese Mandarin language strings displayed side by side:

In this chapter, we began our Moodle plugin development journey. We started with an investigation of the history of Moodle and the philosophy that underpins it. Having gained an understanding of Moodle, we then learned how to set ourselves up for plugin development. We set up a local development web server based on WampServer and then configured the Eclipse IDE and the Chrome Xdebug plugin for remote debugging.

We spent the second half of this chapter developing a simple dual-language plugin. We followed the plugin development process from user story to deployment in order to understand just a few of the thought processes and decisions that need to be made before plugin development begins.

In the next chapter, we will be delving deeper into the types of plugins that are available and learn how to change the layout of a Moodle course through the development of a custom course format plugin.