How to release

This is the overall the responsibility of the Release coordinator coordinates the various Release Roles.

Table of contents


  1. Unix shell environment, Linux or OSX sutable.
  2. Subversion 1.3 or more
  3. PHP 5.x CLI with MySQL, iconv, DOM and SimpleXML extensions
  4. PHP configuration must allow running external programs (like shell scripts)
  5. 7za or 7z needed for creating 7zip archives. (may be installed in OSX through homebrew by typing brew install p7zip)
  6. Plenty of disk space and memory ;) - at least 64M of memory for php (in php.ini for php-cli)
  7. The main packaging script is at doc/devtools/release.php but releasing a Tiki version is a lot more than just running the packaging script :-)



Ongoing work


All progress used to be relayed on live irc channel: irc://irc.freenode.net/#tikiwiki but lately (Tiki 8 and up) tiki devlist is more used. Communication should be used at different level; Specific team and all the community. It should be used to announce but also to implicate members and to get help (mainly for test purpose).

Update relevant page about progress, report and regression.

Coordinate with other teams

  • Review regularly the regressions and bugs with the wish list team
  • Check that a doc page for the version has been created

1. Preparatory work

Some steps here are not necessary if releasing only minor version but this is actually the most time-consuming part!

Using the content for the existing page from the previous version (copy/paste) create a set of page for the new version.

  • Tiki n (n being the version number)
  • Regressions in n.x (n being the version number)
  • Create a new item with the new version number in the category "Version" on dev.t.o

Create a clear roadmap and schedule milestones.


  1. Don't forget to adapt and improve.
  2. Add the new version page in the "About Development" menu
  3. Update https://tiki.org/All+Releases (you can add the Star chosen name later)

1.1. Fix major bugs and regressions

1.1.1. Acknowledgements

  • Ask bug submitters (including security vulnerability reporters) how they would like to be credited in the Tiki release announcement.

1.2. Check database

1.2.1. Check _tiki.sql suffixes

1.2.2. Structure

Does a fresh install with tiki.sql have the same structure as an upgraded Tiki from the previous version?

  1. Checkout a fresh Tiki 6.0, upgrade to Tiki 7.0
  2. Checkout a fresh Tiki 7.0
  3. Export SQL (ex.: mysqldump)
  4. Compare the two files and resolve any differences


1.2.3. Drop Table

In tiki.sql (for your version), make sure all table creation starts with
This avoids that when people re-install, they get an error "table already exists"

1.2.4. MyISAM

In tiki.sql (for your version), take sure all table creations are consistent. As of Tiki7, that means ending with ENGINE=MyISAM; (but it could change in the future). This is also required in the new schema updates.

1.2.5. InnoDB

The InnoDB installation depends on the table definition having ENGINE=MyISAM added to it (because a text conversion is done by the installer). Also check that the script tiki_convert_myisam_to_innodb.sql (for your version) includes all the new tables.
Like this: https://sourceforge.net/p/tikiwiki/code/43274/

1.3. Check SEFURLs

Make sure _htaccess and web_config are in sync.
For more info, go the Clean URLs or ask Arildb

See also: https://sourceforge.net/p/tikiwiki/code/HEAD/log/?path=/trunk/web_config (instructions at the top of the file)

For security, privacy, future-proofness, and site-deaths, the Tiki code should as seldom as possible link to outside of the control of the site admin or the Tiki community. A link to *.tiki.org/* with PluginRedirect is ideal.

quick script to check all http links in templates
grep -R http: templates | grep -v svn

Ideally, it would be done for the whole code base.

1.4.1. Make sure URLs are still active.

It's better to link to tiki.org/Something from which we can put a short page and a link, or even a Redirect

1.4.2. No direct calling of JavaScript

1.5. Check JSLint

inside Eclipse/Apatana: http://www.jslint.com/

1.6. Check PHP syntax is correct for each branch

Notably, 12.x has a minimum requirement of PHP 5.3 but after that 5.5 is used and some 5.5 required uses get backported to 12.x by mistake, especially the short array syntax (using [] instead of array() for instance).
Searching for these regular expressions on all *.php files, (but with the help of phpStorm's "context" in multi-file search set to "accept comments and string literals") seems to find them.

  • [, \(]\[ (should find arrays declared using the short syntax - finds a few false positives in code with strangely positioned linefeeds)
  • (?:empty|isset)\([^\)\[]*-\>[^\)\[]*\( (should find instances of "return value in write context" where a function is called inside an empty or isset test). Two found in vendor files, might need looking into for 12.5 release

1.7. .less files to .css conversion (optional)

  • If you know how to check this easily: Some contributors could have made changes to css or less files and forgot to change the other. A sync should be made, and any missing commits added to the branch. Compiling Less files with php console.php less:compile in the PhpStorm terminal produces results consistent among current developers.
    • This tool (or a version of it) might be able to decompile CSS into LESS which we could then compare somehow, but it wouldn't be trivial

1.8. Check the README file for manual commits

  • The "function update_readme_file" of doc/devtools/release.php will output to the top-level README:
    • Check if anyone has committed anything manually to README that needs to be brought back into this script

1.9. Remove any out of sync English strings

  • lang/en/language.php and lang/en/language.js may contain some tweaks to the English versions that were made after the string freeze. This is useful to improve the English text without breaking any translations. But this workaround should not be used forever and at each major release, this should be cleaned up. Strings should be removed from lang/en/language.php and incorporated in the relevant tpl and php files. Some judgment calls must be made to decide if the translation is invalidated or not. If you fix a typo in English, the translations are still good. However, if the meaning of the English string changes, the translations should be invalidated and translators need to review. This being said, if the meaning changes, it probably should not have been put in lang/en/language.php and lang/en/language.js in the first place.
grep -v '^//' lang/en/language.php

For all the strings that are to be updated, once you replace in Tiki files (source and templates), you look up the language files which have a translation for the old string, and you make that translation the translation of the new string. Since they mean the same thing. Then you can delete the line in lang/en/language.php

1.10. Delete secdb files from previous versions

Ex.: When releasing 5.2, you may see db/tiki-secdb_5.1_mysql.sql lying around

1.11. Check that all PHP files have a feature check

Each PHP file in Tiki should start with a feature check. So if the feature is de-activated, the file is dead. If a particular file is discovered to be insecure, users can deactivate the feature until they upgrade to the release which contains a fix. To avoid forgetting to add this feature check on new files, a feature check script has been created. Some files, by design, can't have a feature check and these files should be audited manually.

Run doc/devtools/securitycheck.php and check each "potentially unsafe" file.

Script must be improved

1.12. Check external software library dependencies

This applies to all External Libraries

  • coming from Composer
  • manually updated via SVN in vendor_extra
  • some known to need a Cleanup
  • (and perhaps there are still some elsewhere in the code).

Background reading: Why your software project will slowly die without continuous updating

How to detect out of date libs?

As of 2014-02-22, there is no automated comprehensive way. The best way is to check the composer.json and vendor_extra for that version and check that project's website. Looking at the satis.json, you will see where the files are coming from and know the home page of the project.

Down the road, there are ways we could improve this process:

1.12.1. Integrity

  • We are getting some files from Packagist, and they are not maintained by the official project. A check is required to make sure the files are the same. If the package is coming directly from the publisher, no need for an additional check.

1.12.2. Security

  • Are there any dependencies that have security releases? If so, the update is mandatory.

1.12.3. General up-to-date-ness

  • Generally, a Tiki release should contain the latest stable version of the library. However, if there is a major update to a lib (which has a higher chance of breaking in the upgrade), it can be decided to hold back. If this is the case, indicate it below and specify the reason (and any relevant link to a discussion). If you feel it's too risky for the stable branch, then, choose instead to do in trunk, and there could be a backport later.

List of external libraries that we have decided to hold back on the upgrade.
Zend Framework 1 We are staying at ZF1 because it's a big job to upgrade, some components are not yet (or no longer?) available in ZF2, and thus, we will wait for now. NOTE that fix in r54095 is a workaround for a zf1 pbm fixed in zf2. It can be removed after replacement with zf2.

LTS policy

To be discussed: what is our policy for LTS versions? When do we stop updating the libs? (except for security releases)

1.13. Prevent directory browsing

  • Add index.php (see others for examples) to all directories in which it has been forgotten
  • Note while it is extremely important to prevent browsing in folders where there might be Tiki created content, like files, it is unclear if it provides any more benefit for folders that are open source code anyway, esp as I think we need route.php for tiki to work nowadays anyway. Hence we should consider revisiting this release task.
find . -not -path \*\.svn\* -not -path \*vendor\* -type d -exec ls {}/index.php \; | grep "No such file"

1.14. Prefs

1.14.1. Generate preference report

As per Preferences report to make sure this still runs and see if there any obvious issues. And attach the file to the version page (ex.: doc.tiki.org/Tiki12)

2. Create a branch, if you are releasing a major version

This is done only once per major version (4.x, 5.x, 6.x, etc.) about 4-6 weeks before the planned official release of x.0. For minor versions, the work is done in current branch.

From a trunk checkout
php doc/devtools/svnbranch.php branches/7.x

More details on how to create a branch: SVNTips#Handling_branches

2.1. Post-branching operations

  • In lib/setup/wiki.php, update $profilesLink to the new branch

2.1.2. Make new profiles

2.1.3. dev.tiki.org

2.1.4. show.tiki.org

  • First add the new branch to the dropdown in templates/trackerinput/showtikiorg.tpl
  • Remember to backport to the version that the actual dev is running
  • in the show server checkout the new branch into usr/local/src/tiki
  • in the show server add the branch to /usr/local/sbin/tim-common BRANCHES="trunk 12.x 13.x"
  • Refresh the instances by calling right away the cron: /usr/local/sbin/tim-cron
  • Once dev.tiki.org updates, it should then work.

2.1.5. demo.tiki.org

  • Create a site for new version

2.1.6. Pre-dogfood servers

  • Each Pre-Dogfood Server should be moved from trunk to the next branch and each site should go through at least 30 minutes of manual testing of the most common operations.
    Ex.: on http://nextdev.tiki.org, someone should try to report a bug, or on http://nextdoc.tiki.org try and add a new page to a structure (even though it all will be overwritten the next day).
    • the instances need to svn switch and refreshed immediately, e.g.
      +svn switch https://svn.code.sf.net/p/tikiwiki/code/branches/13.x .
      +sh setup.sh -n fix
      +php console.php database:update
    • /usr/local/bin/refresh-nxt.sh needs to be updated so the next cron switches to the right branch
    • A couple of days before the release the cronjob to do a full upgrade including DB-sync from live sites must be disabled so that designers and gardeners can test/learn/prepare for the upgrade of the live community sites.
    • After release the /usr/local/bin/refresh-nxt.sh needs to be changed to trunk again and the full upgrade cron job reenabled.

2.1.7. Dogfood release policy

See dogfood for general background info on this policy. The general principle is that most of *.tiki.org sites should be running supported versions before they are released while others will keep running with previous version (LTS).


  • Reduce the number of issues and collective time spent on these. Issues can be bugs, data corruption, upgrade bugs (that you don't see in a fresh install), etc. in released versions.
  • There is also a promotional goal for this policy as it reassures users that releases have sufficient testing, and it differentiates us from extension-based systems, where the official sites are upgraded to the latest versions a long time after dot zero.
  • Improve the quality / reliability of .0 releases so we can eventually be in a position to shorten the release cycle. Historically, .0 releases have been shaky and too many people where waiting for .1 and that delays everything.
  • Keeping some website running old LTS version is useful in case we need to produce and test security patch or any other correction necessary.

The various *.tiki.org sites collectively have a lot of users & data and cover quite a few features. Power users of these sites are usually quite familiar and can spot a bug or regression (something that stopped working) and report it efficiently.

Some sites are kept at the latest stable version (ex.: doc.tiki.org), while others are kept on the Long Term Support (LTS) versions (ex.: profiles.tiki.org). The list is maintained at Domains.

All sites are generally updated daily with minor revisions in each branch. So if a site is running 9.x LTS, it has the latest pre-released 9.x code. Exception: some legacy sites are kept for historical purposes in old unsupported versions, normally in read-only mode.

When a new major version is coming out, each of the sites identified as latest stable are progressively updated to the new version.

Start with the less critical one (ex.: themes.tiki.org)

  1. Do a thorough check on the Pre-Dogfood Server version (each site should go through at least 30 minutes of manual testing of the most common operations. Ex.: on dev.tiki.org, someone should try to report a bug.)
    • The pre-dogfood servers generally run trunk, but during the pre-upgrade period, they should be switched to the branch
  2. Fix all the bugs and check they are indeed fixed there
  3. Proceed to upgrade (svn switch)
    • Keep previous version available as a snapshot so users can compare and efficiently report any upgrade issues (ex.: legacydev11.tiki.org)
  4. Give a few days to get feedback for newly uncovered issues
  5. And start over the cycle for each sites.

This whole process typically takes 3-5 weeks because of discovery of new issues and the understandable delay to resolve them. Because of this incompressible time factor, it is important to start the dogfood process as soon as possible in the release process (as soon as all bugs are resolved on the pre-dogfood server)

Finding & fixing an issue while in pre-dogfood avoids wasted time and corrupted data on the real sites. Trying to save time by rushing a release just creates more work down the line.

3. Release Steps

3.1. Checkout Tiki

How to Use the Release Server You need to get a subversion checkout to a new directory (of this branch).

Make sure you don't have any spaces in the path to this new checkout (as of Tiki 5.x).

3.2. Setup.sh

When releasing version greater than 9.x there is the Composer to handle external libraries dependencies (as opposed to SVN externals).
It is not clear if there is no need to run 'sh setup.sh' to get the vendor libraries via Composer. Jonny reported that it was not needed for 11.x but it is needed for 12.x. It is needed also if you are doing a pre-release "dry run" which skips some steps, (e.g. using command php doc/devtools/release.php --no-commit --no-check-svn 12.2 preRC1). So it is better to run it anyway than later quit the release script and need to re-run it.


sh ./setup.sh

And choose 'c' option (fpr composer) instead of 'f', which is not needed for release.

3.3. Update lib/setup/twversion.class.php before the release

Look for section with "Release Managers should update this array before release." of twversion.class.php (of your relevant branch)

  • increment the version number and the star name in the constructor
  • temporarily, remove the svn from the branch number. E.g.
    function TWVersion()
    		// Set the development branch.  Valid are:
    		//   stable   : Represents stable releases.
    		//   unstable : Represents candidate and test/development releases.
    		//   trunk     : Represents next generation development version.
    		$this->branch 	= 'stable';
    		// Set everything else, including defaults.
    		$this->version 	= '12.1svn';	// needs to have no spaces for releases
    		$this->star	= 'Altair';

    Since we where to release 12.1, we need to remove the "svn" from "12.1svn", so this part will stay as:
    // Set everything else, including defaults.
    		$this->version 	= '12.1';	// needs to have no spaces for releases
  • update list of valid releases in tikiVersions()
    • Make sure you add all Tiki versions (not just the one you are doing now). Ex.: when 5.0 is released, 4.2 will probably exist, as this was added to branches/4.x but not merged by script.
    • change the version branch to "unstable", "stable", or "trunk" as explained in that file
  • Update the starname in the list in the function tikiStars
  • Commit your changes with this commit message (change \$VERSION by the version of the release):
    [REL] Preparing \$VERSION release

3.3.1. # Remove the previous secdb file

  • The release script does this sicne Tiki 18

3.4. Run script

The main packaging script is at doc/devtools/release.php

Go to the newly created directory

Display Basic Help
php doc/devtools/release.php --help

You may need to run the release command providing your mysql credentials for the script to successfully create the secdb file for you. So if you are releasing from your own computer instead of the from the release server, you may need to use this command instead which provides de mysql credentials:

/usr/bin/php -d mysql.default_host=HOST -d mysql.default_user=USER -d mysql.default_password=PASS doc/devtools/release.php 12.1 beta

(replace 12.1 beta with the corresponding release version)

3.5. Create and test pre-release packages

  • This is done by executing the release script with the release version as argument, using the format major.minor preXYZ (XYZ can be RC1, RC2, alpha, beta1, beta2, etc.)
  • Use the --help option of the release script for advanced help on options (like using a web proxy)

php doc/devtools/release.php 7.0 preRC4

The release script has an interactive mode, enabled by default, that will ask you if you really want to do each step. It also asks for a confirmation before committing any changes. You can have a look at them with another shell by using this command:

Check for changes made by the release script before validating commits
svn --ignore-externals status
svn --ignore-externals diff

3.5.1. Check the generated README file

  • Check links/content in the generated README file

3.6. Launch the release script again

After testing, launch the release script again, now without "pre":

php doc/devtools/release.php 7.0 RC4

3.6.1. Troubleshooting Mysql credentials

In step 11 (or 8 ?) of the release script ("8) Generate SecDB file 'db/tiki-secdb_12.1_mysql.sql'?"), you might see this type of error:

SecDB step failed because some filenames need escaping but no MySQL connection has been found.
Try this command line instead (replace HOST, USER and PASS by a valid MySQL host, user and password) :

	/usr/bin/php -d mysql.default_host=HOST -d mysql.default_user=USER -d mysql.default_password=PASS doc/devtools/release.php 12.1 beta

If so, provide your own HOST, USER and PASS for your mysql from the machine where you are running the release script, and you should be fine, then.

3.7. Test the produced "tarballs" and share the testing

Test on your server. Ideally, you have 1-2 other people trying on different servers. In case of a major version (x.0), you need at least 3 installations from 3 different people

3.8. Upload tarballs to Sourceforge

When the "tarballs" are tested, follow the steps to upload on SourceForge:

To upload the 'tarballs', copy-paste and execute the following line (and change '$SF_LOGIN' by your SF.net login and $VERSION with the version, which may look like "7.0.rc1" ):

cd ~/tikipack/$VERSION
scp *bz2 *gz *zip *7z $SF_LOGIN@frs.sourceforge.net:/home/pfs/project/t/ti/tikiwiki/$RELEASEFOLDER$
Real example
#since 15.0 :

scp *bz2 *gz *zip *7z username,tikiwiki@frs.sourceforge.net:/home/pfs/project/t/ti/tikiwiki/Tiki_XX.x_Starname/XX.Y

Alternatively, you can do it with sftp

User jsmith seeks to put tiki-12.1.* .7z .zip .tgz .bz2 to the 12.1 directory of his project, tikiwiki:

$ sftp jsmith@frs.sourceforge.net
Connecting to frs.sourceforge.net...
jsmith,fooproject@frs.sourceforge.net's password: 
sftp> cd /home/frs/project/tikiwiki/Tiki_12.x_Altair/
sftp> mkdir 12.1
sftp> cd 12.1
sftp> mput tiki*.*
Uploading tiki-12.1.7z to /home/pfs/project/tikiwiki/Tiki_12.x_Altair/12.1/tiki-12.1.7z
tiki-12.1.7z                                                                                                           100%   27MB   2.3MB/s   00:12    
Uploading tiki-12.1.tar.bz2 to /home/pfs/project/tikiwiki/Tiki_12.x_Altair/12.1/tiki-12.1.tar.bz2
tiki-12.1.tar.bz2                                                                                                      100%   38MB   2.9MB/s   00:13    
Uploading tiki-12.1.tar.gz to /home/pfs/project/tikiwiki/Tiki_12.x_Altair/12.1/tiki-12.1.tar.gz
tiki-12.1.tar.gz                                                                                                       100%   43MB   2.7MB/s   00:16    
Uploading tiki-12.1.zip to /home/pfs/project/tikiwiki/Tiki_12.x_Altair/12.1/tiki-12.1.zip
tiki-12.1.zip                                                                                                          100%   52MB   2.9MB/s   00:18    

You need to have "release technician" status on SourceForge. Ask an Admin if you don't have it.

3.9. Update lib/setup/twversion.class.php after the release

  • change $this->version = '8.3'; to '8.4svn';

Needs to have no spaces and use the format X.YabcZ see tikiVersions fn below for examples

You can add a commit message like this one:

[REL]Closing release 12.1beta

3.10. Admin panel update notifier

After each release, we need to update some files IN TRUNK so Tiki installs are prompted to upgrade:

This exists in Tiki since 1.9.9 but has not always worked well throughout the versions.

Ref: Update notifier

Question: why are we also maintaining twversion.class.php? Marc Laporte

3.11. Update dev.tiki.org

A few pages here may need updating depending on the type of release:

3.12. Default Download at Sf.net

Set one of the new tarballs as the default file to download for Tiki project.

Setting the default download can be accomplished through the File Manager.

  1. Go to the Files page while logged in to access the File Manager
  2. From the File Manager navigate to the directory that contains the file
  3. Select the "i" icon for the file you wish to set as the default download
  4. On the bottom right check the boxes for the operating systems which you wish the file to be the default download for.
  5. Select save

Some people say, that an image is worth a thousand words...

3.13. Update auto-installers

see https://tiki.org/1-click+installers and https://tiki.org/Distros if any.

3.14. Acknowledgements

  • Make sure bug submitters (including security vulnerability reporters) are properly credited in the Tiki release announcements.

3.14.1. Previous release leftover.

It is critical the release manager double check that previous version (Major) have been through ALL the release step so nothing is forgotten. If some have been left it is time to complete and reduce the dissonance between what we have done and what should have been done following this page process list.

3.14.2. Version Page

It is important to communicate and log changes and improvement including updating the version page status (Checklist page, ie: https://dev.tiki.org/Tiki12#Checklist ).

3.14.3. Check external software library dependencies

It is always the good time to check and update any external components we have in Tiki.
Please refer to Check external software library dependencies section

3.15. Announce the good news on devel mailing-list

  • Ask the Communications Team to launch the announce-spreading process as described on Communications Team Release
    • info.tiki.org/Download + news item +
      Layer 1
      • the version numbers come from a dynamic variable: to edit, just click on the version numbers (as user with admin rights) and you'll be shown a text field where you can edit those version numbers.

3.16. If new branch, update showtikiorg.tpl

If a new branch is created, then you need to manually update a few lines in the branch which is running for dev.t.o at the file:


Search for "12.x", for instance, in that file, and add the corresponding hardcoded cases for the new branch.


Version: <select name="svntag">
<option selected="selected">trunk</option>
	<span class="buttonupdate{$field.fieldId}_{$item.itemId}" {if $field.version != 'trunk' && $field.version != '13.x' && $field.version != '12.x'}style="display: none;"{/if}>{button href="#showtikiorg{$field.fieldId}_{$item.itemId}{if isset($context.list_mode)}_view{/if}" _onclick="showtikiorg_process{$field.fieldId}_{$item.itemId}('update');"  _text="{tr}SVN update{/tr}"}</span>
			if (data.version == '12.x' || data.version == '13.x' || data.version == 'trunk') {

Tiki 9 branch process

Robert Plummer, Jean-Marc and jonny B had a BBB session running on live.t.o to talk through the branching process on 29th March 2012 - the recording is available here in case it's any use to anyone in the future.

Also See



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.

Accessibility (WAI & 508)
Accounting 7.x
Ajax 2.x
Articles & Submissions
Batch 6.x
BigBlueButton audio/video/chat/screensharing (5.x)
Browser Compatibility
Communication Center
Contacts Address book
Contact us
Content template
Contribution 2.x
Credits 6.x
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs 8.x
Draw 7.x
Dynamic Content
Dynamic Variable
External Authentication
Featured links
Feeds (RSS)
File Gallery
Friendship Network (Community)
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Lost edit protection
Meta Tag
Missing features
Visual Mapping 3.x
Mobile Tiki and Voice Tiki
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Payment 5.x
Performance Speed / Load / Compression / Cache
Revision Approval
Search engine optimization (SEO)
Semantic links 3.x
Shopping Cart 5.x
Site Identity
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Staging and Approval
Syntax Highlighter (Codemirror)
Tags 2.x
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
TikiTests 2.x
Token Access
Toolbar (Quicktags)
User Administration
User Files
User Menu
Webmail and Groupmail
WebServices 3.x
Wiki 3D
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives 4.x

Useful Tools