GSOC TikiFest in London

In the first week of July I was in London for the GSOC (Google Summer of Code) TikiFest. TikiFests are a tradition in the Tikiwiki community. It is when two or more Tiki contributors get together to code, discuss about free software etc.

This time the main reason for the TikiFest was to gather together all the students from GSOC who are working in the Tikiwiki projects. This is the first year Tikiwiki is participating in GSOC and there are four students involved, including myself.


Two students from Spain, Aldo and Ben, are working together to create the new workspaces feature (the ability to have collections of items/objects that allow different set of users to have different kinds of access in a single Tikiwiki installation). For more information on their project see the wiki page At the TikiFest they presented their work done until that moment and we discussed some tricky aspects of the implementation. The development of the workspaces is of great interest for the Tikiwiki community and there are more people working on it at present besides the two GSOC students. On the first week of August there will be another TikiFest in Barcelona just to discuss and develop some parts of the workspaces.

Another student from India, Nagendra, was there to present his project which will allow online video edition in Tikiwiki using the Kaltura API. Maybe in the future we will be able to edit video the wiki way using this.


And finally I presented my project to create a migration script from Mediawiki to Tikiwiki. As my mentor on this project, Nelson Ko, was at the TikiFest I had a great opportunity to make some crucial decisions for the project. Mainly to leave phpBB for another project and focus only on the migration from Mediawiki to Tikiwiki.

Beside the presentation of the projects, we also discussed some interesting aspects of the free software world. Aldo and Amette showed some of the great features Git has over SVN and we discussed how the Tikiwiki community could benifit from moving to Git (for example merging branches is much easier with Git). It was agreed that as an expemeriment the workspaces development would be done using Git.


Jonny talked about the recent development of the Tikiwiki profiles and Jean-Marc showed some inconsistencies between the administration page of different Tikiwiki features and we discussed possible interface standards for those pages.

Olaf-Michael brought the discussion about Tiki as an open translation tool. He told us about, a place to centralize and make the translation of different open source wiki softwares as easy as possible. They are interested in putting Tikiwiki in the pool of softwares they translate and Olaf is in contact with them to make this happen. Although the way Tikiwiki handles with translations at present (a PHP array for each language with key/value pairs) is accepted by TranslateWiki I mentioned at the TikiFest that it would be a good idea for the Tikiwiki community to switch to a standard open source tool for translation like gettext.


At present it is hard for a non-technical person to start helping with Tikiwiki translation. As I host several sites using Tikiwiki for different Brazilian social movements I am very interested in making it easier to translate. I think that using a standard tool for that purpose is a great first step. We can take advantage of all the tools built around gettext that already exist. I plan to look at this question in the next weeks, so if anyone else is also interested please do let me know. Apparently it is not that hard to convert to gettext. PHP has gettext built-in support and there is already a script to convert from Tikiwiki language.php files to gettext. Before moving, as mentioned by Jean-Marc, it is a good idea to talk with people from other projects that already use gettext to learn from their experience.

On the last day of the meeting, Aldo, Ben and I (unfortunately Nagendra had to leave the day before) talked about the difficulties we had with Tikiwiki when we started our projects. We agreed that the lack of technical documentation and tests were the two most difficult aspects.

Without technical documentation we had to read the code to understand what a function does and without tests it is much harder to know if the change you are making will break something elsewhere in the code. With this in mind we are using in our projects phpDocumentor and PHPUnit. By using phpDocumentor we can have some day, as proposed by Aldo in the devel list, Very similar to or Which can help to atract more contributors. PHPUnit is already used in a few parts of Tikiwiki. Louis-Phillipe created on trunk the directory lib/core. All the code there have tests. Alain Desilets and Marta Stojanovic are using PHPUnit with Selenium to write acceptance tests for Tikiwiki.


This is what I remember from the discussions we had during the five days of GSOC TikiFest. If I forgot to mention something please leave a comment.

How to run phpt tests with PHPUnit

In this post I will explain how to run phpt tests with PHPUnit.

For my GSOC project I will use (and contribute to) the PEAR package Text_Wiki (more about my contributions on this package on another post). This package use phpt tests for unit testing. I’m not familiar with phpt tests as I’m with PHPUnit and phpt tests didn’t give me a good impression (its difficult to understand feedback and its syntax mixing PHP code and plain text statements lead to improper syntax highlighting in Emacs :-D).

So I proposed the main developer of Text_Wiki to switch to PHPUnit. He had no objections if I were able to provide a solution that made possible to run the old phpt tests with the new PHPUnit tests at the same time.

I found that there is a PHPUnit extension that does exactly what I was looking for. As I wasn’t able to find a tutorial explaining how to use it, I decided to write this post to share the way I used that extension.

I’m using version 3.3.17 of PHPUnit and it came with two phpt related extensions located in the directory PHPUnit/Extensions (if you use Ubuntu as I do the full path will probably be /usr/share/php/PHPUnit/Extensions): PhptTestCase.php and PhptTestSuite.php

The first one implements the class PHPUnit_Extensions_PhptTestCase. The constructor of this class receive as a parameter the path to a single phpt file. I did not use this one.

The other file implements the class PHPUnit_Extensions_PhptTestSuite. You can instantiate this class in your test script passing as the first parameter the root directory where your phpt files are located. The constructor of the class will recursively look for all files with the extension .phpt.

On the link below you can view the code I used to integrate the old Text_Wiki phpt tests with the new PHPUnit classes I’m writing: