MoodleDocs - User contributions [en]

Development:Interface guidelines

2008-05-26T17:39:41Z

Rubenback26:

This document is not authoritative, it is a collection of ideas and under construction.

==Keeping it simple==

Use the minimum interface required to get the job done

==Standard pages==

===Activity modules===

*''index.php'' - lists all instances for that module in a course
*''view.php'' - displays a particular instance
*''config.html'' - configure an instance of the module

===Blocks===

*''config.html'' - configure an instance of the block

==One script per major function/page==

...

==Page layout==

# Print headings with print_heading, use the CSS hooks for IDs and Classes
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes

===Tabs===

.userinfobox {
border-top:0 none;
padding-top:0;
margin-top:0;
}

#mod-forum-user .forumpost,
#course-user .section .content {
border-top:0 none;
}

#course-user .section {
background-color:#fff;
padding:1em;
}

#course-user .section h2 {
margin-top:0;
}

#user-view .tabs td,
#user-edit .tabs td,
#mod-forum-user .tabs td {
padding-bottom:0;
}

#user-edit .generalbox {
width:100%
}

.mod-glossary .glossarydisplay tr,
.mod-glossary .glossarydisplay td {
border:0 none !important;
padding-bottom:0;
}

.mod-glossary td.entryboxheader {
height:0 !important;
background-color:#fff;
}

.mod-glossary .entrybox {
padding:0;
}

.tabs {
width:auto;
margin-left:auto;
margin-right:auto;
margin-bottom:0;
padding-bottom:0;
border-bottom:0 none;
}

#user-view .tabs {
width:80%;
}

.tabs tr,
.tabs .left,
.tabs .right {
background:url(pix/tab/tabsbg_x2.gif) bottom left repeat-x
}

.tabs .side {
border-bottom:0 none
}

.tabs td {
padding:0
}

.tabs .left {
width:0
}

.tabs .right {
width:75%
}

.tabrow {
width:100%;
margin:0;
border-collapse:collapse
}

.tabrow td {
padding:0 0 0 14px;
height:34px;
border-width:0
}

.tabs .r1 {
margin-bottom:1px
}
.tabrow td.selected {
border-width: 0px
}

.tabs .r0 .active {
background:url(pix/tab/left.gif) bottom left no-repeat
}

.tabs .r1 .active {
background:url(pix/tab/left2.gif) bottom left no-repeat
}

.tabs .r0 .inactive {
background:url(pix/tab/left_inactive.gif) bottom left no-repeat
}

.tabs .r1 .inactive {
background:url(pix/tab/left_inactive2.gif) bottom left no-repeat
}

.tabs .r0 .activetwo {
background:url(pix/tab/left_active2.gif) bottom left no-repeat
}

.tabs .r1 .activetwo {
background:url(pix/tab/left_active2.gif) bottom left no-repeat
}

.tabs,
.tabs tr,
.tabs .td,
.tabrow,
.tabrow tbody,
.tabrow tr,
.tabrow td {
background-color:transparent
}

.tabrow th {
display:none
}

.tabrow td .tablink {
padding:0 14px 0 0;
/*display:block;*/
white-space:nowrap;
line-height:32px;
text-align:center;
text-decoration:none;
height:34px;
width:auto
}

.tabs .r0 .active .tablink {
background:url(pix/tab/right.gif) bottom right no-repeat
}

.tabs .r1 .active .tablink {
background:url(pix/tab/right2.gif) bottom right no-repeat
}

.tabs .r0 .inactive .tablink {
background:url(pix/tab/right_inactive.gif) bottom right no-repeat
}

.tabs .r1 .inactive .tablink {
background:url(pix/tab/right_inactive2.gif) bottom right no-repeat
}

.tabs .r0 .activetwo .tablink {
background:url(pix/tab/right_active2.gif) bottom right no-repeat
}

.tabs .r1 .activetwo .tablink {
background:url(pix/tab/right_active2.gif) bottom right no-repeat
}

.tabrow td .tablink a {
width:auto;
line-height:32px
}

.tabs .r0 .active:hover {
background:url(pix/tab/left_hover.gif) bottom left no-repeat
}

.tabs .r0 .active:hover .tablink {
background:url(pix/tab/right_hover.gif) bottom right no-repeat;
line-height:32px
}

.tabs .r0 .inactive:hover {
background:url(pix/tab/left_inactive.gif) bottom left no-repeat
}

.tabs .r0 .inactive:hover .tablink {
background:url(pix/tab/right_inactive.gif) bottom right no-repeat;
line-height:32px
}

.tabs .r1 .active:hover {
background:url(pix/tab/left_hover2.gif) bottom left no-repeat
}

.tabs .r1 .active:hover .tablink {
background:url(pix/tab/right_hover2.gif) bottom right no-repeat;
line-height:32px
}

.tabrow .last span {
padding:0 1px 0 0;
display:block;
background:url(pix/tab/right_end.gif) bottom right no-repeat
}

.tabs .r0 .selected {
background:url(pix/tab/left_active.gif) bottom left no-repeat
}

.tabs .r1 .selected {
background:url(pix/tab/left_active2.gif) bottom left no-repeat
}

.tabs .r0 .selected .tablink {
background:url(pix/tab/right_active.gif) bottom right no-repeat;
line-height:32px
}

.tabs .r1 .selected .tablink {
background:url(pix/tab/right_active2.gif) bottom right no-repeat;
line-height:32px
}

/*.tabrow td.selected:hover {
background:url(pix/tab/left_active.gif) bottom left no-repeat;
}

.tabrow td.selected .tablink:hover {
background:url(pix/tab/right_active.gif) bottom right no-repeat;
}*/

.user-content h2 {
margin:0;
padding:0 1em
}

.user-content {
background-color:#FFFFFF;
border:1px solid #D1D7DC;
border-top-width:0;
padding:0.5em
}

===Tabs===

.tabs {
font-size:0.8em
}
.tablink a:link,
.tablink a:visited {
color:#000066;
}

.tablink a:hover {
text-decoration: none;
}

.selected .tablink a:link,
.selected .tablink a:visited {
color:#000000;
}

==Dealing with tables==

Use the print_table function whenever possible.

==Standard navigation tools==

# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==URLs==

# URLs should be as short as possible.
# No underscores in parameter names or files names
# Never use two words when one would do.

==Buttons vs links==

This is a hard one to define ...

The Google Web Accelerator issue definitely provides some pointers here:

# Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons
# At the very least, such actions which are implemented as links should forward to a confirmation page which *does* use buttons

==CSS naming==

* See [[Standards|theme standards]]

==Linking to help==

* Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)

==Related topics==

Robin Good's Latest News. "Interaction Design Meets Online Real Estate" 1 Mar. 2005 http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm

The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools.

[[Category:Developer]]

[[pt:Guia para interface]]
[[es:Manual de estilo de la interfaz]]
[[ja:インターフェースガイドライン]]

Tracker

2008-05-22T11:24:12Z

Rubenback26:

[[Image:Tracker.jpg]] '''is Moodle's''' [[Image:Issue Tracker MoodleOrg link.JPG]]

Issue tracking is an important part of a continuous quality control process. It involves the reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called '''[http://tracker.moodle.org Moodle Tracker]'''. We welcome your requests for new features, improvements, or even constructive criticism of existing features.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. Please help us by using [http://tracker.moodle.org Moodle Tracker]!

==Basics==
===Logging in to Tracker===
*If you're a new Tracker user, create a user account [http://tracker.moodle.org here]. It is strongly suggested your Tracker username is the same name you use at Moodle.org.
*If you've forgotten your password, go [http://tracker.moodle.org here] and select '<u>forgot password</u>' which is just under the 'log in' button. Follow the prompts.

=== Summary: How to report a bug, improvement, or new feature request ===
NB See the section 'Tracker fields' below for a full description of every field.
*Login to [http://tracker.moodle.org Tracker]
*Select "Create New Issue" from the menu under the Moodle Tracker logo
*From the dropdown menu select the "Issue type": Bug, New Feature, Task or Improvement
*You will see a series of dropdown and free text fields. Complete as many as you can. Some fields are required while others are optional.
*Press the 'Create' button at the bottom of the page to create the bug.

=== How to write a good Tracker entry===
A good report will include:
*Summary (describe the issue in 1 or 2 sentences)
*Description (a concise yet complete summary of the problem or improvement)
*Steps to Reproduce: A detailed, easy-to-follow sequence of steps a developer can follow to reproduce the problem. If possible, provide a URL so a developer can see the problem with one click.
*Actual Results: What the application did after performing the above steps.
*Expected Results: What the application should have done, were the bug not present. Provide as much detail as possible. Your expectation might mean that help instructions need to be improved or interface changed.

If possible, include additional information that may be helpful to the developer:
*Moodle version (there is a dropdown menu on the top of the form, if that does not have what you want, add it in the description)
* If you have an error message, or information in your PHP or web server logs, copy and paste it into the bug report. If you can, turn on "debug" in your Admin configuration page and reproduce the problem to get the best possible error message.
* Screen shots are very helpful for some bugs, but please write a textual description of the problem too.
* Provide details about your setup including operating system, database, etc. If you run out of room in the environment section, add more detail in the description. The full set of information that might be relevant is:
**Server operating system type and version number
**Web server type and version number
**PHP version number (and whether you are using an accelerator)
**Database type and version number
**Client-side operating system type and version number
**Web browser type and version number

* You don't need to provide details all the time. For example, for a layout rendering problem, you need to give only the client-side OS and browser info, and if it is a server-side problem you only need to describe the setup there. Use your judgment. Here are some examples:
**I see this bug with the latest Moodle HEAD running on PHP5.1.2/Apache 2.2.3 on Linux. My database is Postgres 8.1.
**This rendering problem happens using Internet Explorer 6.0 on Windows XP.

In summary stick with facts and present enough facts so someone else can duplicate the problem.

Here are some examples of good bug reports: MDL-6030, MDL-5688, MDL-12505

*A good external reference to help write a tracker entry can be found at [http://developer.mozilla.org/en/docs/Bug_writing_guidelines mozilla bug writing guidelines].

"What’s the hardest thing about a bug report?" Most of the time fixing the problem is the easy part, the hard part is reproducing the bug. The developer needs to see how it is broke to be able to fix it. If they can't reproduce the error you can be sure they won't be able to fix it!

Good bug reports contain as much detail as possible and are specific. Don't generalise or leap to conclusions.

For example, a bug report that only says "The RSS feed doesn’t support UTF-8" is not helpful. The developer knows that UTF-8 and RSS feeds are compatible. The developer has no idea of what the person sees and why they reported this bug. In this case more time and effort needs to be expended to determine the problem.

Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows unrecognisable characters rather than expected characters.

==Tracker process==
===Logging new issues or improvements===
Anyone with a Tracker account can log issues. See instructions above for writing good quality bug reports. It is important that you search Tracker to determine if your problem or suggestion for improvement has already been reported. If it has you are encouraged to add more information (use the "comment" function), vote for the issue, or watch it (more on this later).

You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching.

You can monitor, or '''watch''' issues reported by others. To do this, open the issue, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your issue, open the issue, select the option "Watching" from the left hand navigation panel. These people will receive email notification when the issue is updated.

Tracker provides a facility to '''Link''' issues. Any user logged onto Tracker may link issues. Multiple link types are defined in the system; you will be required to select one when linking bugs. See [insert section name] for detailed list of link types.

'''Vote''' for bugs you want to see addressed in Moodle. Any user can vote. To vote for a specific bug, browse to the bug, then select "Vote for it" from the left-hand navigation panel. Developers may consider the number of votes a bug has when weighing the merits of two or more bugs.

The Tracker '''Dashboard''' is flexible and customisable depending on your area of interest. For instructions on configuring the Tracker dashboard click [http://www.atlassian.com/software/jira/docs/v3.6.3/dashboard.html here].

The Tracker '''Issue Navigator''' is used to find and filter bugs. For instructions on configuring the Issue Navigator click [http://www.atlassian.com/software/jira/docs/v3.6.4/navigatorcolumns.html here].

Tracker's '''Quick Search''' function is explained [http://www.atlassian.com/software/jira/docs/v3.6.4/quicksearch.html here]

===Resolving issues=== (this section should be reviewed)
Issues are resolved in Tracker to show that they've been actioned. Only Moodle core developers and testers are permitted to change the status of bugs in Tracker to "resolved" or "closed".

This is the general process a developer will follow when actioning a Tracker issue:

# Issues are automatically assigned at the time they're created based on component type; they may be reassigned by developers or Component Leads.
# Developers fix, modify or add code and check into CVS. The Tracker issue number is included which automatically links the CVS change to Tracker.
# Patches are attached to Tracker issues so that they may be verified and possibly included in CVS.
# Appropriate comments should be added in Tracker describing the fix. The bug's status is changed to '''Resolved'''.
# The developer should indicate which version of Moodle the change will be included in using the '''Fix Version/s'''. You should use this to indicate which branch(es) you checked the fix into (example below).
# The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the resolved issue, in which case the bug status can be changed to Closed.

===Testing issues===
All users are encouraged to be active participants when it comes to testing Moodle. Anyone with a Tracker user account can log, view, comment on, vote, and watch bugs. If you find bugs or problems, have ideas for improvements, or want additional functionality added to Moodle, please log a bug in Tracker.

We've formalised a group of testers in Tracker who are responsible for verifying the accuracy of changes made by developers. These testers have responsibilities and authority in Tracker beyond that of standard users. Testers normally have a good understanding of Moodle, and are active in the Moodle community. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. If you are interested in becoming a member of the Moodle Testing team, make yourself known by logging a request through Tracker. We'd love to have you join the team! Log your request at the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10020 Moodle.org Sites] Tracker project.

<u>Testing a bug in Tracker</u>

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.
*Testers test bugs with Status=Resolved. Global filters have been created based on upcoming releases (eg 1.7 Resolved) to make identification simple.
*Use the '''QA Assignee''' field to identify yourself as the tester of a particular bug.

*It's a good idea to add your name to the watch list for all bugs you test. (see "Tracker watch list", below.)
*If the bug passes testing, close the bug using the "Close Issue" button. You must add appropriate '''comments''' describing your testing methods, any issues that were found, etc.
*If the bug fails testing or if you feel the fix is incomplete, '''reopen''' the bug using the "Reopen Issue" button. Ensure the bug is assigned to the correct developer. Work with the developer to find a mutually agreeable resolution to the bug.
*A release will be deemed ready when all bugs fixed for a particular version have been closed.
*All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
*Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

==Detailed description of Tracker fields and groups ==
===Tracker fields===
NB A short explanation appears under each field in Tracker.

'''Project''' - Required field. Tracker is a collection of multiple projects. At present there are 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. Specify 'moodle' for issues/bugs related to moodle software; specify 'moodle.org sites' for issues/bugs related to tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, or moodle.org; specify 'Non-core contributed modules' for issues/bugs related to contributed modules.

'''Issue Type''' - Required field. Bugs are classified as 1 of the following:
:''Bug'' - A problem which impairs or prevents Moodle from functioning correctly.
:''Improvement'' - An enhancement to an existing Moodle feature.
:''New Feature'' - A new Moodle feature which has yet to be developed.
:''Task'' - A task that needs to be completed. Tasks usually refer to work that must be done outside the product.
:''Sub-Task'' - Issues are sometimes broken into multiple sub-tasks.

'''Summary''' - Required field. A brief, concise description of the problem.

'''Security Level''' - Optional field. Specify if this bug or change has security implications for Moodle. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

'''Priority''' - Bugs are prioritised using one of the following:
:''Blocker'' - Blocks development and/or testing work, production could not run.
:''Critical'' - Crashes, loss of data, severe memory leak.
:''Major'' - Major loss of function.
:''Minor'' - Minor loss of function, or other problem where easy workaround is available.
:''Trivial'' - Cosmetic problem like misspelled words or misaligned text.

'''Component/s''' - Required field. Select the area in Moodle which is affected by this bug. Select 'Unknown' if you are unsure.

'''Affects Version/s''' - Required field. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

'''Assigned To''' - This is the person who will fix (code) the issue. Tracker automatically assigns issues to Component Leads. Developers or QA Testers can reassign issues.

'''Reporter''' - The person who logs the bug. This field is automatically filled by Tracker.

'''Environment''' - Specify the operating system, software platform and/or hardware specifications if applicable to this bug.

'''Description''' - A full and complete yet concise description of the problem or improvement.

'''Database''' - Optional field. If applicable to the bug, identify the database type.

'''URL''' - Optional field. If possible, provide a URL address that demonstrates an example of this bug.

'''QA Assignee''' - Used to designate the person who will test this issue.

'''Fixed Version/s''' - This is the Moodle version the bug was or will be fixed in. Basically you should think '''Which release notes should this appear in?''' This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the ''first'' version of Moodle where the change will be seen.
:Example: after Moodle 1.9 has been released, if you fix a bug on the MOODLE_19_STABLE and HEAD branches, mark it as fixed in 1.9.1. If you also backported to MOODLE_18_STABLE, then add the version of the next 1.8.x release too.

:If you resolve the bug as anything but "Fixed" (Cannot Reproduce, Won't Fix, etc.) leave Fix Version/s blank.
:If you resolve the bug as Duplicate, then create a link to the duplicate issue.
:These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL).

'''Attachment''' - Optional. Attach a file that will help developers and testers better understand the bug. Maximum attachement size is 512Kb.

'''Comment''' - The comment field is a detailed register of all changes that relate to this bug.

'''Resolution''' - This field is only displayed when resolving or closing a bug. Specify a code that best describes how this bug was resolved.
:''Fixed'' - Bug has been fixed; a code change will be checked into CVS. Use this resolution code only when actual changes were made to Moodle code.
:''Won't Fix'' - The problem described is an issue which will never be fixed.
:''Not a bug'' - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.
:''Duplicate'' - The problem is a duplicate of an existing issue.
:''Incomplete'' - More information is needed to understand this bug.
:''Can't Reproduce'' - All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.
:''Deferred'' - The resolution to this bug will be deferred to a later release.

=== Tracker groups and permissions ===
'''Standard Users''' [groupname=jira-user] - This is the default group. New user accounts are placed in this group at the time of creation, and users must be a member of this group in order to log into Tracker. Members of this group can browse bugs, create new bugs, comment on bugs, create attachments, create sub-tasks, create filters, watch bugs, and vote for bugs. Members of this group can also resolve bugs, which is primarily a way of closing bugs that are no longer relevant (eg duplicates, or logged in error). Standard Users can configure their Tracker workspace by using the "Configure your Issue Navigator" button. This feature allows users to view watch and voting lists and to manage preferences, profile, and password.

'''Developers''' [groupname=jira-developer] - Developers can do everything Standard Users can do. In addition they can clone bugs, close bugs, edit bugs, link bugs, and assign bugs. Members of this group can also use the Bulk Edit function which allows bulk updated to multiple bugs.

'''Testers''' [groupname=moodle-testers] - Testers can do everything a Developer can do.

'''Moodle Security groups''' [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

"Nobody" is a Tracker user created to alert users to the fact that an issue hasn't been assigned to a developer. These issues are regularly reviewed by the team at Moodle HQ.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

=== Link types ===
The following link types are available:
::duplicates - duplicates are inevitable in a project the size of Moodle. They occur when a logger is unaware of an existing bug that describes the same problem. Use ''duplicates'' to link to the first or most comprehensively described instance of the problem. All duplicates should be linked together.
::blockers - use this to identify bugs that block others from being fixed.
::cloners - in some instances a duplicate bug is intentionally created in order to track the fix in another branch of the code - this almost never is used in the Moodle project.
::dependency - often a fix is dependent on another bug being resolved first, on in a specific order.
::relates - used to identify a bug that is somehow related to another bug.
'''Don't be afraid to link bugs. ''' Links are bi-directional meaning that there's a concept of 'inward' and 'outward' - it affects how linked bugs are displayed. This is why you'll see "blocks/is blocked by" or "duplicates/is duplicated by" in the drop down list of the ''Link Issue'' dialog. Don't become too concerned about using the "correct" link type - all link types work similarly.

==See also==

*[[Development:Weekly Code Review]]
*[http://www.atlassian.com/software/jira/ Jira] Tracker is a slightly customised version of Atlassian's product
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=43952 How to manipulate Moodle developers] forum discussion
*Wikipedia [http://en.wikipedia.org/wiki/Software_bug Definition of a bug]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]
[[Category:Developer tools]]

[[pt:Tracker]]
[[es:Sistema de bugs]]
[[fr:Traqueur de bogues]]

Development:Coding

2008-05-17T17:59:37Z

Rubenback26:

Any collaborative project needs consistency and stability to stay strong.

These '''coding guidelines''' are to provide a goal for all Moodle code to strive to. It's true that some of the older existing code falls short in a few areas, but it will all be fixed eventually. All new code definitely must adhere to these standards as closely as possible.

==General rules==

# All code files should use the .php extension.
# All template files should use the .html extension.
# All text files should use Unix-style text format (most text editors have this as an option).
# All php tags must be 'full' tags like <?php ?> ... not 'short' tags like <? ?>.
# All existing copyright notices must be retained. You can add your own if necessary.
# Each file should include (require_once) the main config.php file.
# Any other include/require should use an absolute path beginning with $CFG->dirroot or $CFG->libdir, not relative includes, which [http://uk.php.net/manual/en/function.include.php sometimes behave strangely under PHP].
# Each file should check that the user is authenticated correctly, using require_login() and has_capability() or require_capability().
# All access to databases should use the functions in ''lib/dmllib.php'' whenever possible - this allows compatibility across a wide range of databases. You should find that almost anything is possible using these functions. If you must write SQL code then make sure it is: cross-platform; restricted to specific functions within your code (usually a lib.php file); and clearly marked.
# Don't create or use global variables except for the standard $CFG, $SESSION, $THEME, $SITE, $COURSE and $USER.
# All variables should be initialised or at least tested for existence using isset() or empty() before they are used.
# All strings should be translatable - create new texts in the "lang/en_utf8" files with concise English lowercase names and retrieve them from your code using get_string() or print_string(). Never delete strings to ensure backwards compatibility of the language packs is maintained.
# Don't use p() and s() functions to print language strings. Those functions are not designed to print html with tags. Use echo() instead.
# All errors should be printed using print_error() to maximise translation and help for users (it automatically links to the docs wiki).
# All help files should be translatable - create new texts in the "lang/en_utf8/help" directory and call them using helpbutton(). If you need to update a help file:
#* with a minor change, where an old translation of the file would still make sense, then it's OK to make the change but you should notify translation AT moodle DOT org.
#* for a major change you should create a new file by adding an incrementing number (eg filename2.html) so that translators can easily see it's a new version of the file. Obviously the new code and the help index files should also be modified to point to the newest versions.
# Incoming data from the browser (sent via GET or POST) automatically has magic_quotes applied (regardless of the PHP settings) so that you can safely insert it straight into the database. All other raw data (from files, or from databases) must be escaped with addslashes() before inserting it into the database. Because this is so often done incorrectly, there is more explanation on this issue of adding and stripping slashes on a [[Developer:Slashes|separate page]].
# VERY IMPORTANT: All texts within Moodle, especially those that have come from users, should be printed using the format_text() function. This ensures that text is filtered and cleaned correctly. More information can be found on the page about [[Development:Output_functions|output functions]].
# User actions should be logged using the [[Development:Logs|add_to_log()]] function. These logs are used for [[Settings#Show_activity_reports|activity reports]] and [[Logs]].
# When generating a HTML link, always make it relative to the full site root, i.e. link to ''$CFG->wwwroot/mod/blonk/view.php?id=99'' rather than just ''view.php?id=99''. This means that your code will work if called by a script in another folder, among other things.
# Modules should store their config variables using ''set_config('varname', $value, 'mod/modulename')'' where the last parameter is the path to the module directory.

==Coding style==

I know it can be a little annoying to change your style if you're used to something else, but balance that annoyance against the annoyance of all the people trying later on to make sense of Moodle code with mixed styles. There are obviously many good points for and against any style that people use, but the current style just is, so please stick to it.

1. Indenting should be consistently 4 spaces. Don't use tabs AT ALL.

2. Variable names should always be easy-to-read, meaningful lowercase English words. If you really need more than one word then run them together, but keep them short as possible. Use plural names for arrays of objects.

GOOD: $quiz
GOOD: $errorstring
GOOD: $assignments (for an array of objects)
GOOD: $i (but only in little loops)

BAD: $Quiz
BAD: $aReallyLongVariableNameWithoutAGoodReason
BAD: $error_string

3. Constants should always be in upper case, and always start with the name of the module. They should have words separated by underscores.

define("FORUM_MODE_FLATOLDEST", 1);
4. Function names should be simple English lowercase words, and start with the name of the module to avoid conflicts between modules. Words should be separated by underscores. Parameters should always have sensible defaults if possible. Note there is no space between the function name and the following (brackets).

function forum_set_display_mode($mode=0) {
global $USER, $CFG;

if ($mode) {
$USER->mode = $mode;
} else if (empty($USER->mode)) {
$USER->mode = $CFG->forum_displaymode;
}
}

The same applies to naming classes and their methods. Use lowercase words separated by underscores.

class some_custom_class {
function class_method() {
...
}
}

Note there are some exceptions in the code using camelcase: class SomeCustomClass {function classMethod(){...}}, but these are usually there because of compatibility with thirds party libraries (e.g. formslib).

5. Blocks must always be enclosed in curly braces (even if there is only one line). Moodle uses this style:

if ($quiz->attempts) {
if ($numattempts > $quiz->attempts) {
error($strtoomanyattempts, "view.php?id=$cm->id");
}
}

6. Strings should be defined using single quotes where possible, so that [http://php.net/types.string less memory is used].

$var = 'some text without any variables';
$var = 'with special characters like a new line '."\n";
$var = 'a very, very long string with a '.$single.' variable in it';
$var = "some $text with $many variables $within it";

7. Comments should be added as much as is practical, to explain the code flow and the purpose of functions and variables.

* Every function (and class) should use the popular [http://www.phpdoc.org/ phpDoc format]. This allows code documentation to be generated automatically.
* Inline comments should use the // style, laid out neatly so that it fits among the code and lines up with it.

/**
* The description should be first, with asterisks laid out exactly
* like this example. If you want to refer to a another function,
* do it like this: {@link clean_param()}. Then, add descriptions
* for each parameter as follows.
*
* @param int $postid The PHP type is followed by the variable name
* @param array $scale The PHP type is followed by the variable name
* @param array $ratings The PHP type is followed by the variable name
* @return mixed
*/
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {
if (!$ratings) {
$ratings = array(); // Initialize the empty array
if ($rates = get_records("forum_ratings", "post", $postid)) {
// Process each rating in turn
foreach ($rates as $rate) {
....etc

8. Space should be used liberally - don't be afraid to spread things out a little to gain some clarity. Generally, there should be one space between brackets and normal statements, but no space between brackets and variables or functions:

foreach ($objects as $key => $thing) {
process($thing);
}

if ($x == $y) {
$a = $b;
} else if ($x == $z) {
$a = $c;
} else {
$a = $d;
}

9. When making a COPY of an object, always use the php5 clone() function (otherwise you may end up with just a reference to the first object). Moodle will make sure this works consistently on php4 too.

BAD: $b = $a;
GOOD: $b = clone($a);

If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead.

==Database structures==

To help you create tables that meet these guidelines, we recommend you use the built in [[Development:XMLDB_defining_an_XML_structure#The_XMLDB_editor|database definition (XMLDB) editor]].

# Every table must have an auto-incrementing id field (INT10) as primary index. (see [[IdColumnReasons]])
# The main table containing instances of each module must have the same name as the module (eg widget) and contain the following minimum fields:
#* id - as described above
#* course - the id of the course that each instance belongs to
#* name - the full name of each instance of the module
# Other tables associated with a module that contain information about 'things' should be named widget_things (note the plural).
# Table and column names should avoid using [[Database reserved words|reserved words in any database]]. Please check them before creation.
# Column names should be always lowercase, simple and short, following the same rules as for variable names.
# Where possible, columns that contain a reference to the id field of another table (eg widget) should be called widgetid. (Note that this convention is newish and not followed in some older tables)
# Boolean fields should be implemented as small integer fields (eg INT4) containing 0 or 1, to allow for later expansion of values if necessary.
# Most tables should have a timemodified field (INT10) which is updated with a current timestamp obtained with the PHP time() function.
# Always define a default value for each field (and make it sensible)
# Each table name should start with the database prefix ($CFG->prefix). In a lot of cases, this is taken care of for you automatically. Also, under Postgres, the name of every index must start with the prefix too.
# In order to guarantee [[Development:XMLDB problems#Table and column aliases - the AS keyword|cross-db compatibility]] follow these simple rules about the use of the '''AS''' keyword (only if you need table/colum aliases, of course):
#* '''Don't use''' the '''AS''' keyword for '''table aliases'''.
#* '''Do use''' the '''AS''' keyword for '''column aliases'''.
# '''Never''' create UNIQUE KEYs (constraints) at all. Instead use UNIQUE INDEXes. In the future, if we decide to add referential integrity to Moodle and we need UNIQUE KEYs they will be used, but not now. Please note that the XMLDB editor allows you to specify both XMLDB-only UNIQUE and FOREIGN constraints (and that's good, in order to have the XML well defined) but only underlying INDEXes will be generated.
# Those XMLDB-only UNIQUE KEYs (read previous point) only must be defined if such field/fields '''are going to be the target''' for some (XMLDB-only too) FOREIGN KEY. Else, create them as simple UNIQUE INDEXes.
# Tables associated '''with one block''' must follow this convention with their names: '''$CFG->prefix + "block_" + name_of_the_block + anything_else'''. For example, assuming that $CFG->prefix is 'mdl_', all the tables for the block "rss_client" must start by 'mdl_block_rss_client' (being possible to add more words at the end, i.e. 'mdl_block_rss_client_anothertable'...). This rule will be 100% enforced with Moodle 2.0, giving time to developers until then. See [http://tracker.moodle.org/browse/MDL-6786 Task 6786] for more info about this.
# '''Never''' make database changes in the STABLE branches. If we did, then users upgrading from one stable version to the next would have duplicate changes occurring, which may cause serious errors.
# When refering to integer variable in SQL queries, do not surround the value in quotes. For example, get_records_select('question', "category=$catid") is right. get_records_select('question', "category='$catid'") is wrong. It hides bugs where $catid is undefined. ([http://moodle.org/mod/forum/discuss.php?d=80629 This thread explains].)

==Security issues (and handling form and URL data)==

# Do not rely on 'register_globals'. Every variable must be properly initialised in every code file. It must be obvious where the variable came from.
# Initialise all arrays and objects, even if empty. $a = array() or $obj = new stdClass();.
# Do not use the optional_variable() function (this function is now deprecated). Use the optional_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Do not use the require_variable() function (this function is now deprecated). Use the required_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Use data_submitted(), with care. Data must still be cleaned before use.
# Do not use $_GET, $_POST or $_REQUEST. Use the appropriate required_param() or optional_param() appropriate to your need.
# Do not check for an action using something like if (isset($_GET['something'])). Use, e.g., $something = optional_param( 'something',-1,PARAM_INT ) and then perform proper test for it being in its expected range of values e.g., if ($something>=0) {....
# Wherever possible group all your required_param(), optional_param() and other variables initialisation at the beginning of each file to make them easy to find.
# Use 'sesskey' mechanism to protect form handling routines from attack. Basic example of use: when form is generated, include <input type="hidden" name="sesskey" value="<?php echo sesskey(); ?>" />. When you process the form check with if (!confirm_sesskey()) { print_error('confirmsesskeybad');}.
# All filenames must be 'cleaned' using the clean_filename() function, if this has not been done already by appropriate use of required_param() or optional_param()
# Any data read from the database must have [[Developer:Slashes|addslashes()]] applied to it before it can be written back. A whole object of data can be hit at once with addslashes_object().
# Wherever possible, data to be stored in the database must come from POST data (from a form with method="POST") as opposed to GET data (ie, data from the URL line).
# Do not use data from $_SERVER if you can avoid it. This has portability issues.
# If it hasn't been done somewhere else, make sure all data written to the database has been through the clean_param() function using the appropriate PARAM_XXXX for the datatype.
# If you write custom SQL code, make very sure it is correct. In particular watch out for missing quotes around values. Possible SQL 'injection' exploit.
# Check all data (particularly that written to the database) in every file it is used. Do not expect or rely on it being done somewhere else.
# Blocks of code to be included should contain a definite PHP structure (e.g, a class declaration, function definition(s) etc.) - straight blocks of code promote uninitialised variable usage.
# If you need to use shell_exec() (or any other shell invoking function), make sure you clean parameters first with escapeshellcmd()/escapeshellarg (otherwise, we open up for shell injection attacks).

[[Category:Developer|Coding]]

[[es:Manual de Estilo de Código]]
[[ja:コーディング]]
[[zh:代码指南]]
[[pl:Kodowanie]]
[[pt:manual_de_codigo]]

Development:CVS for developers

2008-05-15T19:25:54Z

Rubenback26:

'''CVS''' is the Concurrent Versioning System, a commonly-used way of managing source code for large software projects. CVS keeps all versions of all files so that nothing is ever lost, and usage by different people is tracked. It also provides ways to merge code if two or more people are working on the same file. All code and all versions are stored on a central server (in the case of Moodle, at cvs.moodle.org). The [http://cvsbook.red-bean.com/cvsbook.html CVS book] holds more information about CVS than you need.

If you just want to download Moodle using CVS to run a site, then you probably don't need this page - please see [[CVS for Administrators]] instead.

==Joining the project as a developer==

So, you've been offered CVS write access to help us develop and maintain Moodle! Welcome aboard!

To be able to write changes into [http://cvs.moodle.org/ Moodle's CVS archive], you first need to have an account on the server. Only trusted developers get these accounts. To request access, go to the "Apply for CVS Access" tab on the CVS page on Moodle.org (http://moodle.org/cvs). Tell us what modules you'd like to access (e.g. a language module), and why. You'll receive notification in a day or so.

With that done, you should have all the permissions you need, so you just need to set up your machine and download the current source code so you can start working on it.

For the examples on this page, let's assume your username is '''myusername''' and your password is '''mypassword'''.

==CVS modules==

Within CVS, the word "modules" refers to separate collections of code. In Moodle we have the following modules within our repository:

* '''moodle''' - the main Moodle source code
* '''lang''' - all the language packs
* '''[[Development:contrib|contrib]]''' - user contributions and other assorted code in development
* '''mysql''' - a customised phpMyAdmin to plug into Moodle for database admin
* '''windows-cron''' - a small package that makes cron possible on Windows systems
* '''docs''' - various extra user-contributed documentation

Most people are working on the existing features in the moodle module, but many are also contributing new ideas in the contrib modules. Once code reaches a certain level of maturity in the contrib area, it can be migrated over into the main moodle tree.

==Basic CVS commands==

===CVS on Unix===

Moodle CVS uses ssh as a transport layer for security, so you will have to set a CVS_RSH environment variable in your Unix shell. It's best to put these commands in your .bashrc or .cshrc so you don't have to type it all the time:
setenv CVS_RSH ssh (for csh, tcsh etc)
export CVS_RSH=ssh (for sh, bash etc)

Next, you can check out the latest development version of Moodle using this (all one line). NOTE: Don't try to do run this first CVS command over an existing moodle installation: start fresh with a new directory!:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle

The command is similar for other CVS modules:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib

If you want to checkout a single plugin (attendance block as an example here) from contrib into the current directory, you can use:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance

Note that you will be prompted for mypassword for each command unless you set up authorized keys. Read [[Development:SSH_key|SSH Keys]] for more details on how to set those up.

Now, you should have a new 'moodle' directory. You can rename it and move it around if you like. Go into it:
cd moodle

All the latest Moodle files should be in there. You can now change files in your copy. To compare your files and directories against the main CVS copy on the server use cvs diff, e.g.:
cvs diff -c config-dist.php
cvs diff -c lang

To fetch the latest updates from the server use:
cvs update -dP

To copy your new files back to the server you would do something like:
cd lang/ca
cvs commit

You will be prompted to add some comments (depends on your default text editor). Please write a meaningful, descriptive comment and '''always include the name of any tracker issues that talk about the issue you are fixing''' (eg '''MDL-XXXX''').

After that your changes will be sent to the CVS server and stored in the repository. Done!

To save more time you can put default arguments into a file called .cvsrc in your home directory. For example, mine contains:
diff -c
update -dP

Try 'cvs help' for more details ...

===CVS on Mac OSX===

You can follow the same instructions as for Unix (above) in a terminal window. However, the cvs command is not installed by default in an OSX. You first need to install the XCode Tools. You should find this on your original installation disk. Failing that it can be downloaded (a fairly hefty download) from the Apple developer web site ([http://developer.apple.com]).

===CVS on Windows===

First, you need to download a completely fresh copy of Moodle using your developer account.

1. Get TortoiseCVS from tortoisecvs.org and install it, then reboot. (Tortoise is not currently supported on vista but [http://www.syntevo.com/smartcvs/index.html SmartCVS] works well).

2. Find or create a new folder somewhere where you want Moodle to be downloaded to.

3. Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.

4. Copy this text into the CVSROOT field (using your own username!):

:ext:myusername@cvs.moodle.org:/cvsroot/moodle

5. Under the "Module" field, type "moodle" to get the latest development version of Moodle, "contrib" to get the contributions directory, or "mysql" to get the MySQL Admin module.

6. Press the button: "OK" and everything should be downloaded.

A dialog box should show all the files being downloaded, and after a while you should have a complete copy of Moodle. After this first checkout, you can fetch the latest updated files from the CVS server:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Update".
# Sit back and watch the logs scroll by. Take note of conflicts that may occur if your local code has changes that conflict with the incoming versions - you will need to edit these files and resolve the conflicts manually.

After modifying files (you will notice their icons change from green to red!), you can commit them back to the CVS server like this:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Commit...".
# In the dialog box, type a clear description of the changes you are committing. '''Always include the name of any tracker issues related to what you are fixing''' (eg '''MDL-XXXX''').
# Click "OK". Your changes will be sent to the server.
# If you create a folder, BE CAREFUL about using the "CVS Add" option as it will add the folder to CVS without requiring a commit. Once added, the folder cannot be removed from CVS even though it will be pruned so long as it is empty.

Please note that as of April 15 2008, TortoiseCVS 1.10.6 might not work really well with Windows Vista. You could report bugs to TortoiseCVS site (hosted by SourceForge) or google "TortoiseCVS vista" for more details.

==CVS commit messages==

Every commit you make to CVS should have a commit message containing
* a tracker issue id like MDL-12345 (if necessary, create an issue before committing, the only exception is for very minor typos.)
* A brief description of the problem you are fixing. (If you are feeling lazy, you may be able to get away with copying and pasting the issue summary from the tracker.)
* If it is not immediately obvious, a brief summary of why this change fixes the problem. If a longer description is necessary, you may also want to add more information to the tracker issue, or Moodle Docs, but the code changes + commit message should provide enough clues to how the fix works on their own.

==Working with branches==

This diagram shows how the main moodle module branches into different versions over time.

[[Image:Cvstree.png|CVS tree]]

To see all the current tags and branches that are available, use this command on any old file (such as index.php in the top moodle directory):
cvs status -v index.php

Some tagging guidelines:
* Tag and branch names should always be all upper-case.
* Tags and branches should ALWAYS be applied to the entire module (all of Moodle). Don't tag individual files or directories.
* We don't allow renaming of tags because people may be relying on them, so get them right the first time!

===Trunk development===

The Trunk of CVS is the main development version of Moodle. In CVS it is also known as the HEAD, or default branch.

Moodle developers try to keep this stable as possible, but as it usually contains new code it probably has bugs and small instabilities.

Every now and then we decide the product has enough features to make a release. At this time, the trunk is tagged with a MOODLE_XX_BETA tag (in case we ever want to roll back to that point) and a new branch is formed for the release, called MOODLE_XX_STABLE.

A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs.

===Stable branches for each release===

As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it.

You can switch your local copy of Moodle to the STABLE version using the following command in Unix from the root directory:
cvs update -dP -r MOODLE_XX_STABLE

After that, all the commands described above will apply to that stable version. To return to the trunk version just issue:
cvs update -dPA

On Windows clients you should have a menu from which you can choose the branch.

Once the new STABLE branch really stabilises, a release can be declared. Packages are created for distribution and the branch will be tagged (by Martin Dougiamas) with a tag named: MOODLE_XXX

===Merging fixes===

All bug fixes in any STABLE branch should be merged back into the trunk so that they become available in future versions of Moodle. A floating tag called MOODLE_XX_MERGED needs to be maintained to keep track of the last merge. The procedure for such a merge is as follows (I'm using CVS on the Unix command line but the steps are the same for any CVS client):

[[Image:Merging.png|thumb|right|300px|This diagram summarises the process]]
1. I highly recommend keeping one checked out copy of each stable branch and the trunk/head version locally to make it easier to jump between them. Set them all up as virtual web sites on your development machine. I use directories like /moodle/18, /moodle/19 /moodle/dev etc.

2. Update to the latest stable version (I'll use XX in the example but it could be 18, 19 etc) for the relevant files, and do a cvs diff just to double-check exactly what you are checking in. Note you only need to update the files/directories you are working in, but sometimes it help to update everything anyway just to do a final check on the functionality using the web.

cd /moodle/XX/user
cvs update -dPA
cvs diff -c file1.php file2.php

3. If all looks OK, check in the fix to the stable branch. Make sure that the commit message contains the bug tracker ID (eg MDL-1111) and a decent description of your thoughts on the fix. If you don't specify a message in the command line, you'll be put into an editor to type one.

cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php

4. Go to the very latest trunk version and make sure it's up-to-date.

cd /moodle/dev/user
cvs update -dPA

5. Merge everything into your local copy of the trunk from your stable branch since the last merge. You can use the same sequence of (4) and (5) to merge the changes into other stable branches too (to backport the fix to the previous stable versions).

cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php

6. Carefully watch the update logs for conflicts, and fix every file that you see with a conflict. Afterwards, it may help to just run a diff to make sure the result is what you expected:

cvs diff -c file1.php file2.php

7. Check your merged local copy back into CVS trunk version

cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php

8. Go back to your branch version

cd /moodle/XX/user

9. Update the floating merge tag for the affected files (so that it matches MOODLE_XX_STABLE) so that this process can be repeated next time

cvs tag -RF MOODLE_XX_MERGED file1.php file2.php

Finally, the values for $version in all the Moodle version.php files within the stable branch should not be updated at all if possible (except the last digit if absolutely necessary). The reason is that someone updating from a very stable version to the next very stable version could miss database upgrades that happened on the trunk.

===Merging fixes with TortoiseCVS===
Situation: we did a fix on MOODLE_19_STABLE. We modified one file for this fix. This fix needs to be done on Moodle 1.8 and trunk(HEAD). All following CVS instructions will be applied on the file that we changed.

1. Update to the latest stable versions (HEAD included)

Right click on the moodle folder
CVS update
OK

2. On your MOODLE19 branch: commit your fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description"
OK

3. On your HEAD repository: merge the changes

Right Click on the file
CVS>
Merge...
Start: MOODLE_19_MERGED
End : MOODLE_19_STABLE
OK

4. If the resulting file have some conflicts, TortoiseCVS displays a red square on the file icon. Edit the file with your text editor and resolve the conflicts.

5. Run a diff to make sure the result is what you expected

Right Click on the file
CVS Diff
OK

6. Commit the fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description, merged from 19"
OK

We've commit MOODLE_19_STABLE and trunk. It's now time to backport the change on MOODLE_18_STABLE.
On your MOODLE18 branch: reproduce step 3 to 6.

7. On your MOODLE19 branch: update the floating merge tag for the affected file

Right Click on the file
CVS>
Tag...
Tag: MOODLE_19_MERGED
Select 'Move existing tag'
OK

On your MOODLE18 branch: reproduce step 7 (with Tag: MOODLE_18_MERGED).

===Feature branches for large changes===

Occasionally, there may be a very large feature that needs to be checked in so several people can work on it, but it is too unstable to be included in the main development trunk.

In these cases a short-term branch can be created to work on the feature, and then merged back into the main trunk as soon as possible. An example called MOODLE_19_WIDGET branch can be seen in the above diagram.

If you need to do this for your new WIDGET feature, follow these steps:

1. Discuss with other developers to make sure it's necessary!

2. Make a new tag on the trunk (for all of moodle) called MOODLE_XX_WIDGET_PRE

cvs tag -R MOODLE_XX_WIDGET_PRE

3. Create your branch called MOODLE_XX_WIDGET

cvs tag -Rb MOODLE_XX_WIDGET

4. Work in that branch until the feature is reasonably stable. Commit as necessary.

cvs commit

5. When ready, merge the whole branch into the trunk, fix conflicts, commit it to the trunk and then abandon the branch.

cvs update -dPA
cvs update -kk -j MOODLE_XX_WIDGET
cvs commit

Good luck, be careful and have fun!

==Who on earth is ...==

Some of the people committing to the Moodle codebase have non-boring account names on the CVS server. If you are ever looking at a CVS commit, and wondering "who on earth is this purpleblob person?" This information is now available at: [http://moodle.org/mod/cvsadmin/view.php?cid=1 Moodle developers with write access].

==Tips and Hints==
* [[Tracking Moodle CVS with git]]
* [http://moodle.org/mod/forum/discuss.php?d=34472 Merging Custom Moodle Code With Stable Releases]
* [[Unmerged files]]: To see if you've forgotten to merge any file.
* [http://ximbiot.com/cvs/manual/ CVS Manual]
* [[Development:contrib|Introduction to the '''contrib''' area of CVS]]

==See also==

* [http://tracker.moodle.org/browse/MDLSITE-193 "All developers should switch to using the cvs.moodle.org alias"]
* [[CVS for Administrators]]

[[Category:Developer|CVS for developers]]
[[Category:Developer tools]]

[[es:CVS para desarrolladores]]
[[fr:CVS pour développeurs]]
[[pt:CVS_para_programadores]]