1. Conventions

1.1. General

  • Directories are named using the lowerCamelCase capitalization convention;

  • Because OJS 2.x supports multiple languages, no assumptions should be made about word orderings. Any language-specific strings should be defined in the appropriate locale files, making use of variable replacement as necessary.

1.2. User Interface

  • Layout should be separated from content using Cascading Style Sheets (CSS);

  • Smarty templates should be valid XHTML 1.0 Transitional (see http://validator.w3.org/).

1.3. PHP Code

  • Wherever possible, global variables and functions outside of classes should be avoided;

  • Symbolic constants, mapped to integers using the PHP define function, are preferred to numeric or string constants;

  • Filenames should match class names; for example, the SectionEditorAction class is in the file SectionEditorAction.inc.php;

  • Class names and variables should be capitalized as follows: Class names use CamelCase, and instances use lowerCamelCase. For example, instances of a class MyClass could be called $myClass;

  • Whenever possible and logical, the variable name should match the class name: For example, $myClass is preferred to an arbitrary name like $x;

  • Class names and source code filenames should be descriptive and unique;

  • Output should be restricted as much as possible to Smarty templates. A valid situation in which PHP code should output a response is when HTTP headers are necessary;

  • To increase performance and decrease server load, import(...) calls should be kept as localized as possible;

1.4. Database

  • SQL tables are named in the plural (e.g. users, journals) and table names are lower case;

  • SQL database feature requirements should be kept minimal to promote broad compatibility. For example, since databases handle date arithmetic incompatibly, it is performed in the PHP code rather than at the database level.

  • All SQL schema information should be maintained in dbscripts/xml/ojs_schema.xml (except plugin schema, described later).

1.5. Security

  • The validity of user requests is checked both at the User Interface level and in the associated Page class. For example, if a user is not allowed to click on a particular button, it will be disabled in HTML by the Smarty template. If the user attempts to circumvent this and submits the button click anyway, the Page class receiving the form or request will ensure that it is ignored.

  • Wherever possible, use the Smarty template engine's string escape features to ensure that HTML exploits and bugs are avoided and special characters are displayed properly. Only the Journal Manager and Site Administrator should be able to input unchecked HTML, and only in certain fields (such as the multiline fields in Journal Settings). For example, when displaying a username, always use the following: {$user->getUsername()|escape}

  • Limited HTML support can be provided using the Smarty strip_unsafe_html modifier, e.g. {$myVariable|strip_unsafe_html}