-
Notifications
You must be signed in to change notification settings - Fork 487
Chamilo Developer's Starting Guide for v1.*
Want to become a Chamilo developer? Here are a few tips to help you on your path to success. This guide is designed specifically for the 1.11.* branch, which is expected to get to its end of life in 2020 (see the Supported versions page).
Chamilo started as a fork of Dokeos. Dokeos was forked from Claroline in 2004. Claroline was born in 2002 in Belgium. As such, Chamilo has, still today, some very old, very procedural code, together with some very recent framework-inspired code. It has also moved from a one-database-per-course structure to a single database with shared tables, so you might find remains of weird stuff in the code (like database prefixes), in particular if you work on migrations from older versions.
Most recent framework-oriented code can be found in the src/
folder, but the main/controller code is still in the main/
directory, which contains one directory per course tool, and the main/inc/lib/
directory, which contains most of the global libraries, and most notably the main/inc/
directory that contains the global.inc.php
and local.inc.php
files loaded by most pages.
You can find more information regarding the code structure in the developers guide: https://docs.chamilo.org/en/developer/the_chamilo_files_&_database_structure/the_chamilo_lms_files_structure_today.html
You can find a schema of the database on the Database structure page. What you need to know, in short:
-
c_*
tables are course-tools related tables -
track_*
tables are user-data collection tables - all other tables (or almost all) are of global use (not specifically related to a course)
Our Coding conventions are very important to us, and several automated processes will check that your Pull Requests respect those conventions before we review them.
All public issues are registered in the https://github.com/chamilo/chamilo-lms/issues page. If you are going to work on a specific issue that is not publicly registered, we invite you to register it first on this page to ensure that multiple people will work on the same feature separately at the same time.
Some private issues (usually bugs or new features some customer of an official provider asks them to work on) might be tracked on a separate system, but we encourage you to register an anonymized version in the issues list to get additional feedback.
You are also encouraged to develop your code in a personal branch of the project. To do that, start by forking the Chamilo project (branch 1.11.x) in your personal account on Github, then create a new branch. Once you are happy with your branch (you tested it locally), submit it as a Pull Request by connecting to your Github interface, on your branch's page, against the chamilo/1.11.x branch.
This Pull Request will then be automatically checked against a series of validation processes. If something fails, you can still send code changes (commits) to your own branch, and the Pull Request will automatically be updated.
Once your Pull Request validates, we will start the manual review. This can take several weeks. Don't hesitate to post a message in your issue from time to time (once a week?) asking for a review. We (the maintainers team) see those messages and will try to validate as fast as we are available (we also have very large numbers of tasks to work on outside of the Chamilo project on Github, so our time is limited). We might start a review process for which we will ask you to update code or answer a few questions.
Once the review process is over, your code will be included in Chamilo and be available in the next release if it matches the rules of the release cycle.
Our release cycle has a series of rules that might require specific decisions regarding the integration of Pull Requests. Check the details here: https://github.com/chamilo/chamilo-lms/wiki/Release-cycle
Developers communicate on a Slack channel. You can ask to be included to the channel by sending us a message through the chamilo.org contact form, or through a comment on a pull request.
-
Home
- Tools and sessions
- Quiz: Importing
- Releases
- Community support strategy
- Translation management
- How to report issues
- Development
- Integration