Development Policies

Submitting Patches to Upstream

Place the patch in the tracker's 'Code Review' section, with an explanation. Please also place an explanation of the patch in the developer forum so we know its in the tracker.

Carriage Returns / Line Feeds

All text files for the project should have Unix-style line endings (i.e. no carriage returns). Developers who use a Windows desktop should also use a suitable text editor that respects this (last checked, EditPad Lite was one free example).

General Development Best Practices

Copyright and Licensing

Each file in the source tree should begin with a copywright declaration, and information about what license the file is released under.

PHP

Many of the practices at http://www.odi.ch/prog/design/php/guide.php appear to be good rules when working with the OpenEMR source.

HTML

Each page in OpenEMR should be valid HTML. the validator at http://validator.w3.org/ is useful for ensuring compliance. XHTML 1.1 compliant documents are preferred.

CSS

it is preferred that CSS stylesheets contain all style related contents of our html forms. css stylesheets should also validate.

OpenEMR Specific Development Best Practices

MySQL connections

All of your MySQL calls need to go through openemr/library/sql.inc or you will break the encoding (utf8). See that file for details and the large amount of example throughout code. NEVER, NEVER, NEVER use the native mysql_* calls.

PHP Sessions and Browser Windows

You must include a JavaScript call to top.restoreSession() wherever you invoke a PHP script that requires current session data (which is most of them). How to do this is discussed in more detail in the architecture discussion wiki page.

Internationalization

• The main php function used for translation is xl(), basically all of labels and messages have to go through this function. To learn about this function definition, parameters, and general use, please read this wiki page, and ensure you understand it.

• These things are what I consider the tenets of the xl() function:

For coding new xl functions:

1. No trailing or leading whitespace.

Below is WRONG

xl('Demographics ');

Below is CORRECT

xl('Demographics') . ' ';

2. No variables.

Below is WRONG

xl('please type $name here');

Below is CORRECT

xl('please type') . ' ' . $name . ' ' . xl('here');

For previously coded xl functions:

1. To be safe, just leave them be (the above rules do not apply).

• Don't forget about javascript strings. As long as the javascript is in a .php or .inc file it will be translated.

For example:

alert("Please type letters only");

Should be:

alert("<?php xl('Please type letters only','e'); ?>");

• Do not use the text or values of your buttons or controls in your coding algorithm. For example, if you have a 'submit' button and use the 'submit' string(the 'value' of the button) in your algorithm, then it will not work if it's translated to another word.

For good examples, look through the code. If any questions don't hesitate to ask them on the sourceforge developer forums.

Input Collection

A relatively new set of functions (openemr/library/formdata.inc.php) have been created for generalized input validation/cleaning (deal with magic quotes) and preparing for database insertion (escaping data). The goal of this it to put in place a central mechanism to avoid sql-injection attacks and to get OpenEMR ready for PHP6.

This is an active project. Check out this link for progress and examples of it's use. If any questions don't hesitate to ask them on the sourceforge developer forums.

Access Control Objects

If you add a new Access Control Object to the OpenEMR codebase, then also add it to the following three sites:

1. Header notes of the library/acl.inc file
2. acl_setup.php file
3. acl_upgrade.php file