[Show/Hide Right Column]

Tips and tricks for Tikiwiki contributors
Print

DevTips

These tips are here to help new contributors getting a feel for the environment. Some people are inclined to follow these as "Rules" or "Guidelines"; they are suggestions rather than strict requirements. Consider each point below as information about what is in Tiki. As a contributing coder, you should respect that environment. You may wish to read everything below in detail.

If you only read one line :

  • 3Rules : 1/ Respect Environment 2/ Commit Early, Commit Often 3/ Make it Optional

Commits

File names conventions and generalities

  • All file names are lowercase
  • For a PHP file name, the pattern is: tiki-xxx_yyy.php:
    If possible, tiki-mainobject_action.php
    Some exceptions are noticeable in files that are included in others (it seems that they don't follow the tiki-xxx_yyy.php convention)
  • A lib file name follows the pattern lib/object/objectlib.php
  • Give features descriptive names (and use the same keyword in templates, css, libs for easy finding), as there is no feature duplication (we don't have several forums systems in Tiki, we have one and we all collaborate on it)
  • Avoid names like feature_new, feature_newer, feature_newest...

Files content integrity

  • Never change indentation on code you don't change. It could provoke diff and merge inconsistencies.
  • Prefer to use only tabs for indentation for a new file.
  • Be careful with your text editor. Make sure that it uses LF Unix line endings and not CRLF Windows line endings. Only exception perhaps are Smarty templates in templates/mail/ used for sending mails which should use CRLF because some Windows servers seem to have problem with sending mails then (see this thread). If in doubt, use the end of line character from the file that you changed.
  • Use only UTF-8 encoding for language files. Hence, use a UTF-8-enabled text editor for those files.

Strings integrity

SVN operations

  • Only commit to one branch, stable branch or Trunk, depending the current Where to commit

Commit messages

  • Take in mind that your commit message should be clear and describe all operations that this commit is for.
  • Feel free to give the tracker ticket that this commit is closing (if its the case)
  • Your commit comment has to start with one of the following tags to distinguish changes:
    • [MOD] is a modification; this implies a change in how things work
    • [NEW] apply if something new was added in tikiwiki
    • [ENH] is an enhancement; not really new but makes things work better (e.g. look and feel, performance, ...)
    • [FIX] can be used for bug fixes of any sort
    • [SEC] for security fix operations
    • [REL] changes for release process only
    • [KIL] removal of unused or obsolete files
    • [DB] for changes in the database
    • [REF]] refactoring; changes the structure of the code (to make it cleaner or clearer), without changing its actual behaviour.

Database conventions

  • All table names begin with tiki_ except users_ for historical reasons
  • Table name has to be less than 26 characters, all lowercase, using chars and underscores
  • Primary keys in tables usually use the following convention : objectId with a capital 'I'. It's a rare case where a capital is used in any name
  • When you modify the schema (create / modify tables), you need to care for both future installs and existing installs (upgrades). For future installs, you need to modify db/tiki.sql and use convertscripts not anymore starting in Tiki5. See Database Schema Upgrade for more information
  • Respect abstraction scheme and naming conventions for queries as detailed on DbAbstractionDev
  • Do not use reserved words for column name (for instance do not use: user, status, order, show for column name)
  • Key/index are also limited to 1000 bytes (so 250 chars? - to be checked)

PHP coding habits

  • Coding standards: please use Zend Framework Coding standards for your code.
    • Exceptions WE USE TABS
      • Indentation using tabs rather than spaces
  • Use brackets in your control structures: If {} else {} (even if there is only one instruction)
  • All the strings are written to be easily translated using the tra() function. E.g. tra('some string')
  • Do not end a php file with ?>

Files should start with...

1st line of Smarty templates (.tpl)
{* $Id$ *}
Start of PHP files (.php)
<?php
// (c) Copyright 2002-2009 by authors of the Tiki Wiki/CMS/Groupware Project
// 
// All Rights Reserved. See copyright.txt for details and a complete list of authors.
// Licensed under the GNU LESSER GENERAL PUBLIC LICENSE. See license.txt for details.
// $Id$

$Id$

To expand the $Id$
svn propset svn:keywords Id filename.php
To commit
svn commit filename.php

Smarty coding suggestions

  • Comments in Smarty code can be useful. The Smarty comment delimiter is {* *}.
  • All strings are enclosed by {tr}{/tr} blocks for translation.

Design principles

  • HTML code is XHTML 1.0 Transitional compatible. Use the http://validator.w3.org to check the validity of your design.

The error message there is no attribute "role" can be ignored right now, as this is an early adoption of wai-aria.

  • CSS stylesheets are widely used to separate design from content, as opposed to the traditional way of including all style rules and content in a single file.

Best practices

Icons

  • See icons if you want to use icons in the templates

Think of ReleaseProcess

  • Mention your meaningful changes on ))ReleaseProcessxxx(( page on tw.o. It will be used to build the changelog file.
  • Indicating changes in both places is not a problem, but if only one is done, it has to be online on tw.o

About license

  • Code needs to have LGPL, PHP or BSD-like licences if bundled in tikiwiki (not GPL). Please see LibLicense

External GPL code, like Wollabot, is an exception.

Setting up a debugger/development environment

The following links may be useful reference: Xdebug etc


Discussion/Participation

[-]

How about using a style-fixing program on commit, to help enforce some of these rules? — mdavey


see also, on tw.o, in progress of migration here :

Code Maps and Howtos

Because Tiki is a large system, it can sometimes be hard to find your way around the code, or how to accomplish a specific task like "adding a new icon". The Code Maps and Howtos page contains links to:

  • Code "maps" that can help you orient yourself and navigate a particular part of the code (ex: the mulltilingual functionalities of Tiki).
  • Code "howtos" that can help you figure out how to carry out a specific programming task, for example, "adding a new icon" to the UI.

All coders are encourage to write such maps to help others. If you are a newbie to a particular part of the code or particular kind of task and find that they are not covered, you might want to create a map or howto to keep track of your findings and document what you find so others will benefit from it in the future.


Contributors to this page: Etienne Lachance1 points  , sylvie2503 points  , pkdille642 points  , mstovenour11 points  , Mose2304 points  , Marc Laporte2679 points  , luciash d' being1825 points  , lindon900 points  , Nelson1680 points  , Kissaki313 points  , jcyrisse81 points  , Philippe Cloutier746 points  , cdrwhite14 points  and alain_desilets1850 points  .
Page last modified on Friday 27 August, 2010 20:23:27 UTC by Etienne Lachance1 points .

Search Wishes (subject only) [toggle]

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.


Show php error messages
 
PHP (5.2.10-2ubuntu6.4) NOTICE (E_NOTICE):
File: comments.php
Line: 272
Type: Undefined variable: tiki_p_forum_vote