Corsix.org

For the last few months, I've been participating in the Google Highly Open Participation Contest, performing programming and documentation related tasks for the Drupal project. Now that the work is done, let's take a look at the tasks I've done: (links provided to the Google page and the Drupal page for each task)

1. Port Codefilter module to Drupal 6 (Google / Drupal) - A simple task of converting a module from D5 to D6, but a good introduction to the GHOP pipeline and the Drupal way of doing things
2. Improve the codefilter module's regular expression (Google / Drupal) - The codefilter module (which highlights PHP source code posted in content) doesn't like it when something like "?>" is present within the code to be highlighted, as it treats it as the end of code marker even if it occurs within a string or comment. I decided that to fix the problem, the nice simple regex that the module used had to be replaced with a more complex system. The module now behaves properly when "?>" is present in strings and comments, but the patch has not been applied to CVS, as it is too much of a rewrite for an edge case to commit without alot more testing.
3. Enable Metrics and Version Control API modules to show lines of code changed (Google / Drupal) - A challenging task which involved setting up a CVS server to extend the version control CVS backend to publish statistics like the number of lines changed per file per commit. The version control modules (which will hopefully replace the cvslog module someday) got alot of love from GHOP, with other students writing backends for SVN, GIT and other version control systems.
4. Write an "Execute arbitrary PHP-Code" action and condition for worklfow-ng module (Google / Drupal) - This was a nice introduction to the workflow-ng module (and its maintainer, who reviews work exceeding quickly). The module allows admins to setup actions to happen upon certain events meeting given conditions. The task involved writing an action and a condition which execute PHP code provided by the site admin.
5. Create and Document a browser add-on to find strings in your web page (Google / Drupal) - This task was a nice break from the PHP coding of previous tasks. I wound up writing a javascript greasemonkey script to detect when the current page contains the word "node", and alerting the user to this. The average end-user doesn't userstand what a "node" is, so documentation writers and module developers should not let the word "node" slip into their creations, they should use something like "content" instead
6. Integrate Userpoints with Views (Google / Drupal) - "Views" is one of the big modules in the Drupal world; a smart query builder that allows modules to expose information in their database tables, allows admins to create pages and blocks which contain information from various sources, and allows users to view these and change sorting/filtering options. The task involved exposing information about the Userpoints (a module which allows users to rack up points) tables. I think someone needs to come up with an adapter that takes a module's hook_schema and gives it to Views, so that this kind of task can be done automatically.
7. Create admin interface for workflow-ng's state machine API (Google / Drupal) - Back to the workflow-ng module again (because fago's reviews are very fast, as previously mentioned) but not to write actions and conditions. One of the modules that comes with workflow-ng is a state machine API, however it was no more than an API. The task added a set of pages that allow admins to create state machines through a web interface, without having to write a module and use the PHP API.
8. Automatically configure TinyMCE with a module (Google / Drupal) - Another improvement for site admins, the task was to add a one button solution for configuring the TinyMCE WYSIWYG editor module. The way it stands at the moment, the TinyMCE module itself is rather difficult to initially configure, so one button to set it all up in a satisfactory manner is useful for site admins. The task resulted in the creation of a module in the Drupal contributions repository: http://drupal.org/project/tinymce_autoconf
9. A filter to make all other filters obsolete (Google / Drupal) - This task was probably the largest one I did. Creating an entirely new module for Drupal 6, from the gound up, to allow site admins to create and tweak content filters through a web interface, rather than require that they download and configure a new module for each new filter that they want. Hopefully it will become the CCK of filtering. The module can be found in the Drupal contributions repository, was the subject of a dojo lesson, and will be the subject of a Drupalcon session. Who knows, some incarnation of it might even make Drupal 7 core ;)
10. Document Drupal 6 menu placeholders (Google / Drupal) - My token documentation task (you have to do at least one non-coding task). The menu system is the way in which module developers tell Drupal core which URLs the module should process, and also which navigation menu entries the module requires. One of the many changes between Drupal 5 and Drupal 6 was the menu system, with one of the larger changes being the URL placeholder/wildcard system.
11. Write a workflow-ng logging module (Google / Drupal) - Yet another workflow-ng task (if you sit in IRC, and review tasks quickly, then I want to do your tasks), this time adding a new action. The action writes a log message entry to a per-user or per-content log, however as these logs did not exist, the module had to create the necessary database tables in order to support these per-entity logs.
12. Views integration for the workflow-ng logging module (Google / Drupal) - Following on from the previous task, this added Views support to the logging module, to allow site admins and users to actually see the contents of these new logs (and provide filtering, sorting, etc.), as while a logging module is useful, it does help to be able to see the contents of the logs.
13. Write hook_uninstall for several Drupal modules (Google / Drupal) - Modules often fail to clean up after themselves, leaving database tables and variables lying around after the site admin has turned off the module. hook_uninstall allows site admins to 'uninstall' modules rather than just turn them off, which cleans up all these tables and variables, leaving the admin with a nice tidy database. Of the six modules involved in the task, only three actually failed to clean up after themselves, so only 3 hook_uninstallls were written even though there were 6 modules.
14. Convert Faq_Ask to D6 and Document Steps (Google / Drupal) - Originally planned as my final task, this should have been a nice end to GHOP, as I had already done a module port and some documentation writing. However, plans changed and it came my penultimate task, and also turned out to be not as easy as I had expected. I'm disappointed with this task, as I felt like I rushed it too much in order to get it done before the GHOP deadline, resulting in rather sub-par code quality.
15. Write Simpletests for CCK (Google / Drupal) - The simpletest module has been largely (indirectly) funded by Google through the Summer of Code and GHOP programmes. It allows module developers to run automated tests of their code, to ensure that it functions as expected, and that changes have not had adverse effects. The CCK (content construction kit) is another big module in the Drupal world, which previously had no simpletests at all. The task introduced me to the Simpletest module and the CCK module, and added tests for CCK's CRUD (create, read, update, delete) API.

Woah, 15 tasks. That puts me at the top of the Drupal GHOP students on raw number of tasks done (with boombatower next at 12, and then three students at the 9-10 mark), and gets me $500 + t-shirt from Google.