MoodleDocs - User contributions [en]

Setting up PhpStorm

2017-09-01T23:45:08Z

CarsonTam: /* Code formatting */

[http://www.jetbrains.com/phpstorm/ PhpStorm] is a commercial IDE, it is arguably the best IDE for PHP developers with features such as code completion, code inspection, phpunit support, Behat support, database editor, debugger, etc.

==Installation==

===OS X===

Do not install Java manually, download a PhpStorm package with bundled java instead.

==General settings==

* Disable missing @throws tag warning in "Preferences / Project Settings / Inspections / PHP / PHPDoc"
* Strip trailing whitespace from "Modified Lines" in "Preferences / IDE Settings / Editor"
* Show line numbers in "Preferences / IDE Settings / Editor / Appearance"

==Bug tracker integration==

* Add tracker linking in "Preferences / Version control / Issue Navigation"
* Set Issue ID to "MDL-\d+" and Issue link to "https://tracker.moodle.org/browse/$0"

==Code formatting==

* Setup coding style to use all rules from [[Coding style]] in "Preferences / Project Settings / Code Style / PHP" (or simply import from https://github.com/enovation/moodle-utils/blob/master/phpstorm-config/Moodle.xml) - this will allow you to use automatic code formatting and it does nice code formatting on copy/paste.
* Set line separator to Unix in "Preferences / Project Settings / Code Style / General".
* Set right margin to 132 or 180 in "Preferences / Project Settings / Code Style / General".

==Moodle code checker==
Follow the instructions in the [https://github.com/moodlehq/moodle-local_codechecker/blob/master/README.md#ide-integration README]

==PHPUnit integration==
# Install [[PHPUnit]] via Composer
# Tell PHPStorm where is composer - go to "Preferences / PHP / Composer", fill in "Path to PHP executable", "Path to composer.phar", "Path to composer.json" and make sure the option "Add packages as libraries" is enabled.
# Go to "Run / Edit configurations"
# Add PHPUnit configuration by clicking on "+"
# Click "Use alternative configuration file" and select your phpunit.xml file
# Go to "Run / Run ..." and select your new PHPUnit configuration to run

==Database editor==
# Click on the "Database" tab to see the database window
# Click "+" in the top left and add "Database source" for your database
# Note: click on the link to download the necessary drivers directly from IDE

Git for developers

2014-06-05T21:11:07Z

CarsonTam:

This document is for helping you get started on Moodle development with Git. For further details of Git, see [[:Category:Git]].

== General workflow ==

'''A reasonable knowledge of the Git basics is a good idea before you start to use it for development. If you are new to Git, you are encouraged to go to 'See also' for some more general reading.'''

[[image:git-pushpull-model.png|right|thumb|400px|Moodle development workflow with Git]]
In short, the Moodle development with Git looks like this:

* You as the contributor commit changes into your personal repository at your computer
* You push the changes into your public repository and publish links to your changes in the Moodle Tracker
* You may ask for a peer review of your code from another developer (preferred but optional)
* When you are confident of your code you should submit it for integration (Integration request, also sometimes known as a pull request)
* Moodle integrators pull the changes from your public repository and if they like them, they put them into Moodle integration repository
* The integrated change is tested and finally pushed into Moodle production repository
* You update your local repository with all changes from the production repository and the next cycle may start again

This workflow runs in roughly weekly cycles. The integration happens on Monday and the testing on Tuesday. On Wednesday, the production repository moodle.git is usually updated with changes from the last development week.

Most Moodle developers have their public repositories hosted at [http://github.com/ Github]. Alternatively you may want to try [http://gitorious.org Gitorious] or the legendary [http://repo.or.cz repo.or.cz]. In the examples in this guide we assume you'll set up your public repository at Github.

If you'd like to be added to the developers group in the tracker (which allows you to assign issues to yourself), please send an email to michaeld@moodle.com with your tracker username and a link to an issue where you have contributed a patch.

== Installing Git on your computer ==

Install Git on your computer. Most Linux distributions have Git available as a package to install. If you are on Mac, [http://code.google.com/p/git-osx-installer/ git-osx-installer] installs it in a few clicks.

Immediately after the installation, set your name and contact e-mail. The name and e-mail will become part of your commits and they can't be changed later once your commits are accepted into the Moodle code. Therefore we ask contributors to use their real names written in capital letters, eg "John Smith" and not "john smith" or even "john5677".

git config --global user.name "Your Name"
git config --global user.email yourmail@domain.tld

Unless you are the repository maintainer, it is wise to set your Git to not push changes in file permissions:

git config --global core.filemode false

== Setting-up the public repository ==

1. Go to [http://github.com/ Github] and create an account.

2. Go to the [http://github.com/moodle/moodle official Moodle Github repository] and click on the Fork button. You now have your own Github Moodle repository.

3. Now you need to set up your SSH public key, so you can push to your Github Moodle repository from your local Moodle repository. On Mac you can go on this [http://help.github.com/mac-key-setup/ Github help page]. If you are on another system, go to your Github administration page, to the section SSH Public Keys, and you should see a link to a help page. Done? Good! That was the most difficult part!

== Setting-up the local repository at your computer ==

Create a local clone repository of your Github repository. In a terminal:

git clone git://github.com/YOUR_GITHUB_USERNAME/moodle.git LOCALDIR

(or: git clone git@github.com:YOUR_GITHUB_USERNAME/moodle.git LOCALDIR)

This command does several jobs for you. It creates a new folder, initializes an empty Git repository in it, sets your Github repository as the remote repository called 'origin' and makes a local checkout of the branch 'master' from it. The important point to remember now is that your Github repository is aliased as 'origin' for your local clone.

Note that the format of the URL here is important. In the first example, the URL starts "git://github.com" and this will give read-only access to the repository at github.com. If you use this URL, the "git push origin" command that appears later in this document will not work. Therefore, if you want to be able to update the "origin" repository, you should use the URL that starts "git@github.com", i.e. the second of the two "git clone" commands given above. This will give you read and write access to the repository on github.com.

== Keeping your public repository up-to-date ==

[[image:git-sync-github.png|right|thumb|400px|Fetching changes from upstream and pushing them to github]]
Your fork at Github is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git and push them to your public repository. To avoid problems with this it is strongly recommended that you never modify the standard Moodle branches. ''Remember: never commit directly into master and MOODLE_xx_STABLE branches.'' In other words, always create topic branches to work on. In Gitspeak, the master branch and MOODLE_xx_STABLE branches should be always fast-forwardable.

To keep your public repository up-to-date, we will register remote repository git://git.moodle.org/moodle.git under 'upstream' alias. Then we create a script to be run regularly that fetches changes from the upstream repository and pushes them to your public repository. Note that this procedure will not affect your local working directory.

To register the upstream remote:

cd moodle
git remote add upstream git://git.moodle.org/moodle.git

The following commands can be used to keep the standard Moodle branches at your Github repository synced with the upstream repository. You may wish to store them in a script so that you can run it every week after the upstream repository is updated.

#!/bin/sh
git fetch upstream
for BRANCH in MOODLE_{19..27}_STABLE master; do
git push origin refs/remotes/upstream/$BRANCH:$BRANCH
done

=== How it works ===

The git-fetch command does not modify your current working dir (your checkout). It just downloads all recent changes from a remote repository and stores them into so called remote-tracking branches. The git-push command takes these remote-tracking branches from upstream and pushes them to Github under the same name. Understanding this fully requires a bit knowledge of Git internals - see gitrevisions(7) man page.

Note there is no need to switch the local branch during this. You can even execute this via cron at your machine. Just note that the upstream repository updates typically just once a week.

=== New branches ===

Occasionally, moodle.org will create a new branch that does not exist in your public (e.g. Github.com) repository. If you try to push this new branch, you will see an error such as the following:

error: unable to push to unqualified destination: MOODLE_99_STABLE
The destination refspec neither matches an existing ref on the remote
nor begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@github.com:YOUR_GITHUB_USERNAME/moodle.git'

In the above example, "MOODLE_99_STABLE", is the name of the new branch that does not exist in your public repository. To fix the error, you need to create the new branch on your public repository, using the following commands, replacing "MOODLE_99_STABLE" with the name of the new branch you wish to create:

git checkout MOODLE_99_STABLE
git push origin MOODLE_99_STABLE:MOODLE_99_STABLE

The above code will create a new copy of the "MOODLE_99_STABLE" branch in your local repository. If you do not need to keep a local copy of the new branch - and probably you do not need it, you then can remove it from your local repository as follows:

git checkout master
git branch -D MOODLE_99_STABLE

== Preparing a patch ==

As said earlier at this page, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off the standard branch you think it should be merged to. So if you are working on a patch for 1.9 or 2.0, fork the branch off MOODLE_19_STABLE or MOODLE_20_STABLE, respectively. Patches for the next [[Moodle versions|major version]] should be based on the master branch.

git checkout -b MDL-xxxxx-nasty-bug origin/master

Note that if you forget to specify the starting point, the branch is based on the currently checked-out branch. It may not be what you want. It is recommended to always specify the starting point.

To check the current branch, run

git branch

The current branch is highlighted.

Now go and fix the issue with your favorite IDE. Check the status of the files, view the change to be committed and finally commit the change:

vim filename.php
git status
git diff
git commit -a

Note that this is safe as the commit is recorded just locally, nothing is sent to any server yet (as it would in CVS). To see history of the commits, use

git log

Once your local branch contains the change (note that it may consists of several patches) and you are happy with it, publish the branch at your public repository:

git push MDL-xxxxx-nasty-bug

Because we did not specify explicit remote repository, the 'origin' is used. Because we did not specify the branch to push, the Git will use the current branch and push it to the remote repository under the same name (by default, this is a subject of your configuration. See push.default config variable).

Now as your branch is published, you can ask Moodle core developers to review it and eventually integrate it into the standard Moodle repository.

=== Checking if a branch has already been merged ===

After some time contributing to Moodle you would have a lot of branches both in your local repository and in your public repository. To prune their list and delete those that were accepted by upstream, use the following

git fetch upstream (1)
git branch --merged upstream/master (2)
git branch --merged upstream/MOODLE_20_STABLE (3)

The command (1) fetches the changes from your upstream repository at git.moodle.org (remember that git-fetch does not modify your working dir so it is safe to run it whenever). Command (2) and (3) print all branches that are merged into the upstream master branch and MOODLE_20_STABLE branch, respectively. To delete these local branches, use

git branch -d MDL-xxxxx-accepted-branch

The similar approach can be used to check the branches published at your origin repository at github.com

git fetch origin (1)
git fetch upstream
git branch -r --merged upstream/master (2)
git branch -r --merged upstream/MOODLE_20_STABLE (3)

The command (1) makes sure that you have all your branches from github.com recorded as the remote tracking branch locally. Commands (2) and (3) work the same as in the previous example but they list remote tracking branches only ([http://www.kernel.org/pub/software/scm/git/docs/git-branch.html see -r param]). To delete a branch at github.com, use

git push origin :MDL-xxxx-branch-to-delete

This syntax may look weird to you. However it is pretty logical. The general syntax of the git-push command is

git push <repository> <source ref>:<target ref>

so deleting a remote branch can be understood as pushing an "empty (null) reference" to it.

== Peer-reviewing someone else's code ==

To review a branch that someone else pushed into their public repository, you do not need to register a new remote (unless you work with such repository frequently, of course). Let us imagine your friend Alice pushed a work-in-progress branch called 'wip-feature' into her Github repository and asked you to review it. You need to know the read-only address of the repository and the name of the branch.

git fetch git://github.com/alice/moodle.git wip-feature

This will download all required data and will keep the pointer to the tip of the wip-feature branch in a local symbolic reference FETCH_HEAD. To see what's there on that branch, use

git log -p FETCH_HEAD

To see how a particular file looks at Alice's branch

git show FETCH_HEAD:admin/blocks.php

To create a new local branch called 'alice-wip-feature' containing the work by Alice, use

git checkout -b alice-wip-feature FETCH_HEAD

To merge Alice's work into your current branch:

git merge FETCH_HEAD

To see what would be merged into the current branch without actually modifying anything:

git diff ...FETCH_HEAD

Once you are all set and reviewing code, this [[Peer_reviewing_checklist|checklist]] should prove to be useful.

== Rebasing a branch ==

Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists:

A---B---C topic
/
D---E---F---G master

From this point, the result of the command:

git rebase master topic

would be:

A'--B'--C' topic
/
D---E---F---G master

and would end with 'topic' being your current branch.

You may be asked to rebase your branch submitted for the integration if the submitted branch was based on an outdated commit. The typical case is if you create a new branch as a fork off the upstream master branch on Tuesday. Then on Wednesday, the upstream master branch grows as all changes from the last integration cycle are merged to it. To make diff easy on Github for next weekly pull request review, you want to rebase your branch against the updated master.

git rebase master MDL-xxxxx-topic-branch

Note that rebasing effectively rewrites the history of the branch. '''Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.''' For this reason, many Git tutorials discourage from rebasing any branch that has been published. However in Moodle, all branches submitted for integration are potential subject of rebase (even though we try to not to do it often) and you should not base your own branches on them.

=== Conflicts during rebase ===

During the rebase procedure, conflicts may appear. git-status commands reports the conflicted files. Explore them carefully and fix them in your editor (like you would do with CVS). Then add the files with 'git add' command and continue.

vim conflicted.php
git add conflicted.php
git rebase --continue

== Applying changes from one branch to another ==

Most bugs are fixed at a stable branch (like MOODLE_20_STABLE) and the fix must be prepared for other branches, too (like MOODLE_21_STABLE and the main development branch - master). In Moodle, we do not merge stable branches into the master one. So usually the contributor prepares at least two branches - with the fix for the stable branch(es) and with the fix for the master branch.

If you have a patch prepared on a local branch (let us say MDL-xxxx-topic_20_STABLE), it is possible to re-apply it to another branch.

=== Cherry-picking a single commit ===

Let us have two local Git repositories ~/public_html/moodle21 containing local installation of Moodle 2.1 and ~/public_html/moodledev with the local installation of most recent development version of Moodle. They both use your public repository at github.com as the origin. You have a branch in moodle21 called MDL-xxxx-topic_21_STABLE that was forked off MOODLE_21_STABLE. It contains one commit. Now you want to re-apply this commit to a branch MDL-xxxx-topic in moodledev.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master (1)
git fetch ../moodle21 MDL-xxxx-topic_21_STABLE (2)
git cherry-pick FETCH_HEAD (3)

The command (1) creates new local branch forked off the CONTHERE The command (1) fetches all data needed to re-apply the topic branch and stores the pointer to the tip of that branch to FETCH_HEAD symbolic reference. The command (2) picks the tip of the branch (the top-most commit on it) and tries to apply it on the current branch.
There is also a variant of the cherry-pick command that supports multiple commits, shortly (see its man page for details): <code bash>$ git cherry-pick A^..B</code> if you want to include from A - see '''^''' - to B, A should be older than B. We will use another approach for cherry-picking multiple commits.

=== Applying a set of patches ===

If the branch MDL-xxxx-topic_21_STABLE from the previous example consists of several commits, it may be easier to use git-format-patch and git-am combo to re-apply the whole set of patches (aka patchset). Firstly you will export all commits from the topic branch to files.

cd ~/public_html/moodle21
mkdir .patches
git format-patch -o .patches MOODLE_21_STABLE..MDL-xxxx-topic_21_STABLE (1)

The command (1) takes all commits from the topic branch that are not in MOODLE_21_STABLE and exports them one by one to the output directory .patches. Look at the generated files. They contain the patch itself (in diff format) and additional information about the commit. You could eg send these files by email to a friend of yours for peer-review. We will use them in another repository.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master
git am -3 ../moodle21/.patches/* (1)

The command (1) applies all the files from the .patches directory. When a patch does not apply cleanly, the command tries fall back on 3-way merge (see the -3 parameter). If conflicts occur during the procedure, you can either deal with them and then use `git am --continue` or abort the whole procedure with `git am --abort`.

== See also ==

; Moodle forum discussions
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]
* [http://moodle.org/mod/forum/discuss.php?d=183409 Git help!! I don't understand rebase enough...]
* [http://moodle.org/mod/forum/discuss.php?d=217617 add MOODLE_24_STABLE to github.com repository]

; External resources
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]
* [http://vimeo.com/14629850 Getting git by Scott Chacon] - an recording of an excellent 1-hour presentation that introducing git, including a simple introduction to what is going on under the hood.

[[Category:Git]]

[[ja:開発者用Git]]

Moodle Wishlist

2011-02-10T01:02:08Z

CarsonTam: /* Code Review */

Warning! This page is highly speculative.

It is basically a dumping ground for random ideas from anyone who wants to write something here. It is not in any way an official Moodle roadmap or policy. Some of the good ideas here may be adopted, but most of the ideas are pretty crazy, and will never work. Basically, it is a place to brainstorm. Please add your own crazy ideas! They don't need to be consistent yet, just make sure your ideas are here to be boiled down later on.

Think Big!

===One type of plugin===

All plugins/modules could be subclassed from one plugin class, making installation easier and simplifying the API a lot.

===Look at new framework===

Possibly base Moodle 3.0 on new existing frameworks? Ruby on Rails? Drupal?

==== Drupal ====
There's an interesting discussion in the Language Teaching Course:
[http://moodle.org/mod/forum/discuss.php?d=83963 How can Moodle be more of a social networking site?] with some links to the [http://groups.drupal.org/drupal-education Drupal in Education User Group]. --[[User:Frank Ralf|Frank Ralf]] 14:27, 18 January 2009 (CST)

(I started a section about [[User_talk:Frank_Ralf#What_Moodle_could_learn_from_Drupal|What Moodle could learn from Drupal]] on my User talk page. --[[User:Frank Ralf|Frank Ralf]] 06:35, 21 January 2009 (CST))

There are some activities in the Drupal community regarding better interoperability and integration of Moodle and Drupal, see [http://moodle.org/mod/forum/discuss.php?d=121859 Drupal Quiz module - data exchange with other LMSes] and [http://moodle.org/mod/forum/discuss.php?d=119857 Moodle integration with Drupal]. --[[User:Frank Ralf|Frank Ralf]] 08:10, 10 June 2009 (UTC)

==== Zend Framework ====
How about [http://framework.zend.com/ZendFramework ZendFramework]? It's open source, of course, runs on PHP, already has a pretty cool API with a well stocked service library, and the coders are working closely with Google, Adobe and Microsoft, among others, to produce some really high quality code. One feature I particularly like is that the main bulk of the PHP code is outside the public HTML directory. Since version 1.7 It also offers pretty good support for Flash Remoting (AMF0 and AMF3) making it especially easy to create integrated RIA frameworks. [http://framework.zend.com/about/components Check here] to see what you get "out of the box". It looks like they've already done most of the hard work for you.

=== Moodlets===

Individual-independent-activities backup/restore + metadata - Eloy

=== Support for alternate interfaces, mobile interfaces ===

Optimized for tablet computing: iPad, others
Completely flash-based interface? Designed for offline clients?

=== Integrated category/taxonomy system ===

Putting together the "course categories", "tags" into a generic taxonomy system.

=== Save the 1970-2038 limitation ===

Those UNIX timestamps are [http://moodle.org/mod/forum/discuss.php?d=101984 pretty limited].

=== Translation framework ===
Drupal uses [http://www.gnu.org/software/gettext/gettext.html GNU gettext].po files for providing translations which is a very robust and well understood format.

=== Use PHP 5.3 Native Power ===
Like : PDO, SPL, Namespace, Intl, Phar...
(Zend Framework 2 use it)

=== Make a replica Moodle ===
1 Moodle library, 100 Moodle platforms, just adding plugins and themes.

=== Built for Teacher-to-teacher Content Sharing ===

Drag-and-drop courses and course items from Moodle Hubs

=== Learn from LAMS and Dokeos ===

Integrated authoring system
Drag-and-drop sequential scenario-building

=== Invent something crazily new ===
3-line ideas are welcome here:
* participation reward systems
* Add trashcan and /or undo function
* Make editing of modules WYSIWYG, no more icons that change layout
* Collaborative spreadsheet editing functionality - like Google Docs.

=== More Agile Development ===
There are many elements in agile development that could apply to Moodle and benefit the development process tremendously. With proper application of these elements, the Moodle's core code can be more solid and robust. Any programmer can make changes to the source with confidence and not be afraid of breaking any other features.

==== Test Driven Development ====
Require unit tests and acceptance tests be written for every change made to the core code. No code should be committed to the core without any test written. A code reviewer should run the tests and expect them to be failed before applying the code changes, and expect they all passed after applying the fix or code changes. S/he should also run the full test suite to make sure the changes did not break any existing features and functionalities.

==== Code Review ====
Implement a code review process like the [http://codereview.chromium.org Google Chromium project]. Developers can only commit to the trunk with one or more reviewers' approval.

''I wonder if the person who added these ideas has any idea how Moodle development actually works. I would guess not. The process is already very agile. All contributions are code-reviewed. There are not enough unit tests yet, but writing unit tests for legacy code is the hardest sort of tests to write (see the book xUnit test patterns) so frankly, it is not worth the effort, except in new code. I can get away with saying that because I have written 2500+ test cases for the latest bit of development I did.''--[[User:Tim Hunt|Tim Hunt]] 15:23, 6 February 2011 (UTC)

''Hi Tim, please don't take me wrong. I think the development team at Moodle is already very agile. It is actually one of the few agile projects that I have seen in the open source communities. The effort that you and many diligent individuals have made to coordinate and integrate contributions from all over the world is outstanding. I just made these comments based on the software development environment I came from, where no code change is allowed to commit without any test written and reviewer signs off. Our VCS is actually configured to reject any commit that do not have these two elements present. You are correct that I do not fully know the Moodle development process yet, but the fact that I see codes (particular contributed codes) being checked in without any tests, I just thought it would help bolster Moodle's core code by enforcing this rule in future commits. And implementing something like [http://codereview.chromium.org Google Chromium code review] interface allows more eyes on the check-in codes, and hopefully alleviates some of the loads from you and the rest of the core team, who have been doing a wonderful work on peer-reviewing all these time. Again, please don't take this as a criticism but a brian-storming idea if you will. Peace.'' --Carson

Moodle Wishlist

2011-02-07T23:17:56Z

CarsonTam: /* Code Review */

Warning! This page is highly speculative.

It is basically a dumping ground for random ideas from anyone who wants to write something here. It is not in any way an official Moodle roadmap or policy. Some of the good ideas here may be adopted, but most of the ideas are pretty crazy, and will never work. Basically, it is a place to brainstorm. Please add your own crazy ideas! They don't need to be consistent yet, just make sure your ideas are here to be boiled down later on.

Think Big!

===One type of plugin===

All plugins/modules could be subclassed from one plugin class, making installation easier and simplifying the API a lot.

===Look at new framework===

Possibly base Moodle 3.0 on new existing frameworks? Ruby on Rails? Drupal?

==== Drupal ====
There's an interesting discussion in the Language Teaching Course:
[http://moodle.org/mod/forum/discuss.php?d=83963 How can Moodle be more of a social networking site?] with some links to the [http://groups.drupal.org/drupal-education Drupal in Education User Group]. --[[User:Frank Ralf|Frank Ralf]] 14:27, 18 January 2009 (CST)

(I started a section about [[User_talk:Frank_Ralf#What_Moodle_could_learn_from_Drupal|What Moodle could learn from Drupal]] on my User talk page. --[[User:Frank Ralf|Frank Ralf]] 06:35, 21 January 2009 (CST))

There are some activities in the Drupal community regarding better interoperability and integration of Moodle and Drupal, see [http://moodle.org/mod/forum/discuss.php?d=121859 Drupal Quiz module - data exchange with other LMSes] and [http://moodle.org/mod/forum/discuss.php?d=119857 Moodle integration with Drupal]. --[[User:Frank Ralf|Frank Ralf]] 08:10, 10 June 2009 (UTC)

==== Zend Framework ====
How about [http://framework.zend.com/ZendFramework ZendFramework]? It's open source, of course, runs on PHP, already has a pretty cool API with a well stocked service library, and the coders are working closely with Google, Adobe and Microsoft, among others, to produce some really high quality code. One feature I particularly like is that the main bulk of the PHP code is outside the public HTML directory. Since version 1.7 It also offers pretty good support for Flash Remoting (AMF0 and AMF3) making it especially easy to create integrated RIA frameworks. [http://framework.zend.com/about/components Check here] to see what you get "out of the box". It looks like they've already done most of the hard work for you.

=== Moodlets===

Individual-independent-activities backup/restore + metadata - Eloy

=== Support for alternate interfaces, mobile interfaces ===

Optimized for tablet computing: iPad, others
Completely flash-based interface? Designed for offline clients?

=== Integrated category/taxonomy system ===

Putting together the "course categories", "tags" into a generic taxonomy system.

=== Save the 1970-2038 limitation ===

Those UNIX timestamps are [http://moodle.org/mod/forum/discuss.php?d=101984 pretty limited].

=== Translation framework ===
Drupal uses [http://www.gnu.org/software/gettext/gettext.html GNU gettext].po files for providing translations which is a very robust and well understood format.

=== Use PHP 5.3 Native Power ===
Like : PDO, SPL, Namespace, Intl, Phar...
(Zend Framework 2 use it)

=== Make a replica Moodle ===
1 Moodle library, 100 Moodle platforms, just adding plugins and themes.

=== Built for Teacher-to-teacher Content Sharing ===

Drag-and-drop courses and course items from Moodle Hubs

=== Learn from LAMS and Dokeos ===

Integrated authoring system
Drag-and-drop sequential scenario-building

=== Invent something crazily new ===
3-line ideas are welcome here:
* participation reward systems
* Add trashcan and /or undo function
* Make editing of modules WYSIWYG, no more icons that change layout
* Collaborative spreadsheet editing functionality - like Google Docs.

=== More Agile Development ===
There are many elements in agile development that could apply to Moodle and benefit the development process tremendously. With proper application of these elements, the Moodle's core code can be more solid and robust. Any programmer can make changes to the source with confidence and not be afraid of breaking any other features.

==== Test Driven Development ====
Require unit tests and acceptance tests be written for every change made to the core code. No code should be committed to the core without any test written. A code reviewer should run the tests and expect them to be failed before applying the code changes, and expect they all passed after applying the fix or code changes. S/he should also run the full test suite to make sure the changes did not break any existing features and functionalities.

==== Code Review ====
Implement a code review process like the [http://codereview.chromium.org Google Chromium project]. Developers can only commit to the trunk with one or more reviewers' approval.

''I wonder if the person who added these ideas has any idea how Moodle development actually works. I would guess not. The process is already very agile. All contributions are code-reviewed. There are not enough unit tests yet, but writing unit tests for legacy code is the hardest sort of tests to write (see the book xUnit test patterns) so frankly, it is not worth the effort, except in new code. I can get away with saying that because I have written 2500+ test cases for the latest bit of development I did.''--[[User:Tim Hunt|Tim Hunt]] 15:23, 6 February 2011 (UTC)

''Hi Tim, please don't take me wrong. I think the development team at Moodle is already very agile. It is actually one of the few agile projects that I have seen in the open source communities. The effort that you and many diligent individuals have made to coordinate and integrate contributions from all over the world is outstanding. I just made these comments based on the software development environment I came from, where no code change is allowed to commit without any test written and reviewer signs off. Our VCS is actually configured to reject any commit that do not have these two elements present. You are correct that I do not full know the Moodle development process yet, but the fact that I see codes (particular contributed codes) being checked in without any tests, I just thought it would help bolster Moodle's core code by enforcing this rule in future commits. And implementing something like [http://codereview.chromium.org Google Chromium code review] interface allows more eyes on the check-in codes, and hopefully alleviates some of the loads from you and the rest of the core team, who have been doing a wonderfully work on peer-reviewing all these time. Again, please don't take this as a criticism but a brian-storming idea if you will. Peace.'' --Carson

Moodle Wishlist

2011-02-05T00:28:38Z

CarsonTam:

This page is a brainstorm about a complete rewrite/refactor for Moodle 3.0.

Please add your ideas! They don't need to be consistent yet, just make sure your ideas are here to be boiled down later on.

Think Big!

===One type of plugin===

All plugins/modules could be subclassed from one plugin class, making installation easier and simplifying the API a lot.

===Look at new framework===

Possibly base Moodle 3.0 on new existing frameworks? Ruby on Rails? Drupal?

==== Drupal ====
There's an interesting discussion in the Language Teaching Course:
[http://moodle.org/mod/forum/discuss.php?d=83963 How can Moodle be more of a social networking site?] with some links to the [http://groups.drupal.org/drupal-education Drupal in Education User Group]. --[[User:Frank Ralf|Frank Ralf]] 14:27, 18 January 2009 (CST)

(I started a section about [[User_talk:Frank_Ralf#What_Moodle_could_learn_from_Drupal|What Moodle could learn from Drupal]] on my User talk page. --[[User:Frank Ralf|Frank Ralf]] 06:35, 21 January 2009 (CST))

There are some activities in the Drupal community regarding better interoperability and integration of Moodle and Drupal, see [http://moodle.org/mod/forum/discuss.php?d=121859 Drupal Quiz module - data exchange with other LMSes] and [http://moodle.org/mod/forum/discuss.php?d=119857 Moodle integration with Drupal]. --[[User:Frank Ralf|Frank Ralf]] 08:10, 10 June 2009 (UTC)

==== Zend Framework ====
How about [http://framework.zend.com/ZendFramework ZendFramework]? It's open source, of course, runs on PHP, already has a pretty cool API with a well stocked service library, and the coders are working closely with Google, Adobe and Microsoft, among others, to produce some really high quality code. One feature I particularly like is that the main bulk of the PHP code is outside the public HTML directory. Since version 1.7 It also offers pretty good support for Flash Remoting (AMF0 and AMF3) making it especially easy to create integrated RIA frameworks. [http://framework.zend.com/about/components Check here] to see what you get "out of the box". It looks like they've already done most of the hard work for you.

=== Moodlets===

Individual-independent-activities backup/restore + metadata - Eloy

=== Support for alternate interfaces, mobile interfaces ===

Optimized for tablet computing: iPad, others
Completely flash-based interface? Designed for offline clients?

=== Integrated category/taxonomy system ===

Putting together the "course categories", "tags" into a generic taxonomy system.

=== Save the 1970-2038 limitation ===

Those UNIX timestamps are [http://moodle.org/mod/forum/discuss.php?d=101984 pretty limited].

=== Translation framework ===
Drupal uses [http://www.gnu.org/software/gettext/gettext.html GNU gettext].po files for providing translations which is a very robust and well understood format.

=== Use PHP 5.3 Native Power ===
Like : PDO, SPL, Namespace, Intl, Phar...
(Zend Framework 2 use it)

=== Make a replica Moodle ===
1 Moodle library, 100 Moodle platforms, just adding plugins and themes.

=== Built for Teacher-to-teacher Content Sharing ===

Drag-and-drop courses and course items from Moodle Hubs

=== Learn from LAMS and Dokeos ===

Integrated authoring system
Drag-and-drop sequential scenario-building

=== Invent something crazily new ===
3-line ideas are welcome here:
* participation reward systems
* Add trashcan and /or undo function
* Make editing of modules WYSIWYG, no more icons that change layout

=== More Agile Development ===
There are many elements in agile development that could apply to Moodle and benefit the development process tremendously. With proper application of these elements, the Moodle's core code can be more solid and robust. Any programmer can make changes to the source with confidence and not be afraid of breaking any other features.

==== Test Driven Development ====
Require unit tests and acceptance tests be written for every change made to the core code. No code should be committed to the core without any test written. A code reviewer should run the tests and expect them to be failed before applying the code changes, and expect they all passed after applying the fix or code changes. S/he should also run the full test suite to make sure the changes did not break any existing features and functionalities.

==== Code Review ====
Implement a code review process like the [http://codereview.chromium.org Google Chromium project]. Developers can only commit to the trunk with one or more reviewers' approval.