What should I learn to develop a moodle activity ?
how can i begin plugin development?
There are lots of different Plugin Types with documentation on how to develop them. It's usually recommended that you start with the Block plugin type as it has a detailed tutorial.
Hi Amin
Moodle having many blocks like activities block, html block, login block.........
you can start create your own block also, you can customize, and create form and create own table also..
Hi Amin,
For developers just getting started in Moodle development, testing and fixing 3rd party Moodle plugins which are not currently supported in Moodle 3.1, 3.2 and 3.3 is a great way to get started on your way to learning how Moodle works. These plugins often just need simple fixes, updates to API calls and stuff like that. I recommend that you touch base with the author before you start just to make sure he/she isn't in the middle of a major re-write (that happened to me once or twice).
Start by browsing through the list of 3rd party plugins and choose a plugin that is of interest to you. If you think it would be useful for you, chances are there are others who would think so too.
A few other things you could check as long as you are testing the plugins:
- Test and fix any errors. Just turn on Developer debugging mode, check the box to display error and then see if there are any error messages that show up. They will often, but not always appear at the top of the HTML source code. I am always amazed at how many developers don't do this resulting in things like un-initialized variables.
- Test and fix any HTML issues from HTML generated by the plugin. You can just view the HTML source code and paste it into the W3C Validation. Just be sure to test your Front Page before you get started to make sure it's not a problem with the theme you are using.
- Test and fix multilingual support issues. This is pretty easy to do, even if you don't personally speak other languages. Just install a language pack other than English and then switch between English and that other language. I recommend choosing one of the more common languages because a lot of plugins haven't been translated so it might be a good idea to check the files in moodledata/lang/xx/ to make sure that a translation is available before you assume it's not working. A plugin will obviously not end up in the right language even if there isn't a language pack available. Another way to do it is to just read through the source code and identify any hard coded strings of text. Move these into a language file that has the same name as the plugin.php and use the get_string() function to retrieve it. Take a look at other language files to see how they are made. If you want to translate a plugin into a non-English language, you will need to upload it into Moodle.org's AMOS translation tool.
- Test and fix the plugins to enable Moodle filter support. I like using the Moodle filter_multilangsecond's non-html {mlang} markup syntax for this as it is very easy to implement. Be sure to enable it for both headers and content - the default is just content. Usually the issue can be corrected by wrapping a format_string() or format_text() function around the string being sent to the browser. Just be sure that you only apply the these when necessary. I've run into situations where the developer saved the filtered string into the database making it useless if the user ended up changing language.
- If you have any experience with WCAG 2.0, you could also test the plugins to make sure that the content they produce meets these accessibility guidelines, preferably at Level AA. Make sure you test it from a students perspective. Not all plugins can be made accessible. For example, I've seen some plugins that require you to drag and drop objects. This kind of task would be very difficult to accomplish using a keyboard.
In my experience, these tend to make up 90% of the issues I come across when implementing a 3rd party plugin. The rest are functionality bugs and display issues on mobile devices. For example, I once uncovered an issue with the "Browse Users" page where the table is wrapped in a "no-overflow" class. Unfortunately, the edit/delete links are at the end of the rows which means that they were being cut off and not-accessible on smaller screens. I guess the author simply never tested his code on a narrow screen.
A lot of developers never even consider multiple language and accessibility issues however, these are some of the unique strengths that Moodle has over other LMS'. Tackle what you feel you can. If all you feel that you can do is the HTML validation or uncovering bugs in Developer DEBUG mode right now, then just do that. Don't be afraid to ask questions in the General Developer Forum. The only bad questions are those that are never asked in my opinion but do take a moment to perform a quick search to see if anyone else might have asked the same question in the past.
Don't forget to submit your changes back to the authors. Most authors prefer to get submissions through GitHub but, for small changes or if you are not familiar with Git, you could even just post an issue with a fix on GitHub or Moodle Tracker, both of which you should learn how to use. Check the plugin's page to see the authors "Bug Tracker" link. If you post in the wrong place, the author may never receive your change request. Try not to report bugs on the plugin's page as it clutters the page and becomes irrelevant as soon as the bug has been addressed.
In some cases, especially with older plugins that were last released for Moodle before 3.1, you may discover that the author is no longer be interested in maintaining the plugin. You can then request to become responsible for the future maintenance of the plugin even if it is just to bring it up to date this one time.
By the way, just because you found a bug doesn't necessarily mean you need to be the one to fix it. If the bug is in a plugin, follow the Bug Tracking link on the plugin's page to post your bug report in the right place (see link below on how to do that). If you believe the bug is in Moodle itself, you will need to post your report in Moodle Tracker.
I noticed is that Moodle Activity Modules (mod) tend to need more changes for each new version of Moodle than most other types of plugins. You will see this because the author tends to have different downloads for different versions of Moodle. If you want to get through more plugins with easier issues, start with some of the other types of plugins.
Moodle API documentation - It's available and will sometimes even be helpful however you may actually find it more useful to read the source code. If you are developing on Windows, take a look at an application called Agent Ransack or FileLocator Pro. You will be amazed at how helpful this tool is to find inline documentation and sample source code in Moodle. With an SSD, it takes about 10 seconds to search through all of the Moodle source code. Tip: Tell it to only search *.php files if you are looking for PHP code.
Moodle maintains a very strict Coding Style. Make sure you read the whole guide or you will find yourself frustrated when your fixes will be rejected for the smallest technicality (like a space at the end of a line). Here are some other Moodle development resources that I highly recommend you also read:
- Moodle Developer Documentation
- Moodle Coding Guide
- Moodle Documentation -- For Users
- Moodle Debugging
Here are a few more links to online tools you will find useful:
- Moodle General Developer Forum - A place to ask questions, get feedback and help other community members
- Moodle Sandbox -- runs the latest stable version of Moodle
- Moodle QA Testing Site - A place you can go and test your code
- Moodle Tracker - Report issues, request new features and share solutions to Moodle core and 3rd party contributions (like plugins and themes)
- GitHub -- The official place to post your patches for integration into Moodle core and often the repository of choice for custom plugin development
- Git for Developers -- instructions on using Git for Moodle Developers
- How to Report Bugs Effectively and How to Manipulate Moodle Developers
- Moodle General Developer Meetings - Lean what's coming up in the next release of Moodle before it is published.
- Moodle on Twitter - If moodle.org goes down, get updates from here.
Some useful development tools you will also want to install include:
- Moodle MDK (Moodle Development Kit) - A collection of tools meant to make developers' lives easier.
- Moodle Code-Checker - Checks your source code to ensure it meets Moodle Coding Style requirements.
- Moodle PHPdoc Check - Checks phpdocs in your source code for compliance with Moodle Coding Style
- Moosh - Moodle Shell. Be sure to watch the videos. If you want to create a plugin for example, this will dramatically increase your productivity.
- User Related Debugmodus - Though not as good as Moodle's built-in Debug Developer Mode, this tool enables debugging on a per user basis which can be useful on a production server.
- Moodle Debugger in Developer Mode (click Home > Site Administration > Development > Debugging - be sure to check the box next to "Display debug messages" if you want to see the errors on your screen. Otherwise they just end up in your log file.
- phpMyAdmin or Adminer - to view and edit Moodle's MySQL database tables.
- Moodle Plugin Skeleton Generator - Allows developers to quickly generate code skeleton for a new Moodle plugin.
Minimum Required Skillset for Moodle Development - In order to develop in Moodle, you will need the following skills at a minimum. If you don't have them, you'll need to brush up on them first:
- PHP 5/7
- MySQL
- HTML 5
- CSS3 (Bootstrap 4 will help)
- JavaScript, jQuery, AJAX, (YUI will help when dealing with older code).
Let us know whether you are developing on Windows, OS X or Linux if you want pointers on setting up your development environment.
Hope you find this useful. Looking forward to seeing your contributions!
Best regards,
Michael Milette
For those who are interested, I recently posted a follow-up to this called:
Getting Started with Moodle Development - Your first Moodle block
https://moodle.org/mod/forum/discuss.php?d=355789
It covers a bit on how to setup a basic Moodle development environment and suggests that a good place to start with Moodle development is by cloning a simple plugin.
Best regards,
Michael
I am really appreciate it Mr Milette
Hey Michael,
Not sure if you can help me, but I'm trying to use the Moodle Development Kit with Ubuntu 16.04.3 through VMWare and I keep running into an error when trying to create a new instance:
mdk create -i iv 33 -e pgsql -r dev users
Creating instance stable_33...
Cloning stable repository into cache...
This is going to take a while...
Cloning repository...
Checking out branch...
Error creating stable_33:
This is not a Git repository
Traceback (most recent call last):
File "/usr/local/lib/phython2.7/dist-packages/mdk/commands/create.py", line 173, in do
M = self.Wp.create(**kwargs)
File "/usr/local/lib/phython2.7/dist-packages/mdk/commands/workplace.py", line 176, in create
repo.delRemote('origin')
File "/usr/local/lib/phython2.7/dist-packages/mdk/commands/git.py", line 116, in delRemote
result=self.execute(cmd)
File "/usr/local/lib/phython2.7/dist-packages/mdk/commands/git.py", line 124, in execute
raise Exception (This is not a Git repository;)
Exception: This is not a Git repositoryI haven't changed anything in the config: is that the problem?
Let me know if you need any more info. Hope you, or someone else, can help!
Hi Rebecca,
I had the exact same problem on Ubuntu 16.04. From what I can tell, something failed to create the initial stable_master cache which is why it is naturally complaining that this is not a Git repository.
After ensuring that there were sufficient directory and file permissions everywhere, here is what I did to fix the problem:
# Upgrade pip to version 9.0.1:
sudo pip install --upgrade pip
# Upgade moodle-sdk:
sudo pip install --upgrade moodle-sdk
# Run mdk doctor (I did not fix the dependency issues it reported):
sudo mdk doctor --all
# Delete the empty stable_master directory. Note: Modify the path to reflect where you placed your files:
rm -rf /var/www/stable_master
# Run mdk create without any extra parameters.
mdk create
When it is finished, you may get a message asking you to create a symbolic link. Be sure to do this.
That's it. Once the cache is setup, you can use your command to create an instance of Moodle 3.3 except that "iv" should actually be "-v". I am assuming that this was just a typo in your message.
Hope you found this information useful.
Best regards,
Michael
Mr Milette, you are rather awesome.
Thank you Marcus!